261 lines
22 KiB
HTML
261 lines
22 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 1: 1995–1996</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume1.html" title="Volume 1: 1995–1996" /><link rel="prev" href="Issue1-28.html" title="Issue 1-28, June 19, 1996" /><link rel="next" href="Issue1-30.html" title="Issue 1-30, July 3, 1996" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue1-28.html" title="Issue 1-28, June 19, 1996"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume1.html" title="Volume 1: 1995–1996"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue1-30.html" title="Issue 1-30, July 3, 1996"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 1: 1995–1996</div></div><div id="headerB">Prev: <a href="Issue1-28.html">Issue 1-28, June 19, 1996</a> Up: <a href="volume1.html">Volume 1: 1995–1996</a> Next: <a href="Issue1-30.html">Issue 1-30, July 3, 1996</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue1-29"></a>Issue 1-29, June 26, 1996</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering1-29"></a>Be Engineering Insights: PEF - The Patently Extraneous Format</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Erich</span> <span class="surname">Ringewald</span></span></div></div></div><p>
|
||
One of the questions we get a lot here at Be is, "Why PEF?" And to be
|
||
perfectly honest, it's a good question. After all, there's a time for
|
||
innovation and a time for slavish compliance to existing standards, and
|
||
it's important to know the difference. It's true for Be, and I think it's
|
||
even true for Apple.
|
||
</p><p>
|
||
PEF is Apple's proprietary executable file format for the PowerPC
|
||
Macintoshes. Think about that: A proprietary executable file format. It's
|
||
even hard for me to type. Just plain weird. Don't make sense. An
|
||
executable file format is just no place to be different. But this is
|
||
Apple we're talking about.
|
||
</p><p>
|
||
So what's so great about PEF? Well, that's not clear to me either. To be
|
||
fair, it is a nice, modern executable file format with support for demand
|
||
paging of code, shared libraries and dynamic loading and linking. Just
|
||
like ELF and XCOFF. It differs from these in really only one regard:
|
||
There's a nice feature that allows for the compression of non-zero
|
||
pre-initialized data. In ELF and XCOFF, if you have zero initialized data
|
||
(known as .BSS to us old timers), its location and length is marked and
|
||
you don't carry a bunch of zeros around in your executable. Sometimes,
|
||
however, you have repetitive (read "compressible") pre-initialized data.
|
||
For example, if the following appeared as global data in your
|
||
application, the linker could take advantage of PEF's handy compression
|
||
feature and reduce the size of your executable:
|
||
</p><pre class="programlisting">
|
||
<span class="type">int</span> <code class="varname">very_important_table</code>[300000] = { 12345 };
|
||
</pre><p>
|
||
Now, saving around 1,200,000 bytes for this fascinating construct is
|
||
pretty cool, but is it worth total incompatibility with all the other
|
||
programming tools in the world? And is it patentable?
|
||
</p><p>
|
||
I bring this up because Apple believes there's something very special
|
||
about this stuff. Whether it's patentable, patented, or just an important
|
||
trade secret is unclear, even after conversations with Apple's lawyers.
|
||
We at Be wrote our PEF loader in the kernel by using publicly available
|
||
documents, but nonetheless it appears we need to pay Apple a license fee
|
||
for the right to open and interpret PEF files. Oh well.
|
||
</p><p>
|
||
We can puzzle over Apple's wisdom in this or any other regard, but life
|
||
is short. We can move on to another vexing question, "Why does Be bother
|
||
with PEF?" The reason we're using PEF is because of Metrowerks. We love
|
||
their tools—they're the best available for the Power PC—and we
|
||
wanted our early developers to be able to use CodeWarrior on the Mac as a
|
||
cross-development platform while the young BeBox was becoming more
|
||
stable. The only executable format supported by CodeWarrior is PEF, so we
|
||
complied.
|
||
</p><p>
|
||
In recent months, we've been asked by a number of developers if we could
|
||
support a more standard format, such as ELF. Our response has been
|
||
positive, but vague. Positive because we'd prefer the more standard
|
||
route, but vague because sharing one object library (libbe.so, currently
|
||
a PEF behemoth) between both PEF and ELF applications is tricky.
|
||
Convincing Metrowerks to support ELF at all has also been a little more
|
||
difficult than we thought it would be. Nonetheless, we strive to an even
|
||
more standard future.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="DevProfile1-29"></a>Be Developer Talk: Green Dragon Creations, Inc.</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Howard</span> <span class="surname">Shere</span></span></div></div></div><p>
|
||
In 1991 I got fired—even though I was putting in 12-plus hour days --
|
||
because I wasn't willing to show up for work at 10:00 am each morning
|
||
(1:00 pm works much better for me). So I figured the time was right to
|
||
return to the contract programming business I'd started three years
|
||
earlier: Green Dragon Creations.
|
||
</p><p>
|
||
At Green Dragon we write games for companies coast to coast. One of our
|
||
first big contracts was "Spectre Supreme"; our next two products (for the
|
||
Macintosh) are "MechWarrior 2" and "Under a Killing Moon."
|
||
</p><p>
|
||
Writing games is the best job in the world. It lets me combine two of the
|
||
things I love most: Programming and playing games. Writing games is a
|
||
sort of game in and of itself—balancing object-oriented programming
|
||
with efficient code.
|
||
</p><p>
|
||
We'll work on any platform except DOS/Windoze/Win95. We'll work on
|
||
Macintosh, Sega Saturn, Sony Playstation, and we're looking forward to
|
||
developing for the Be platform! Every platform needs games, right?
|
||
</p><p>
|
||
I look for a few key things when choosing a platform. On the high end
|
||
(for example, on the BeBox or Macintosh), I look for good tools and a
|
||
good OS/Toolbox to use as a foundation for what I want to write. On the
|
||
low end (for example, on the Sega Saturn), I look for a cool set of chips
|
||
and just enough sample code to write my own OS for the system. I love to
|
||
get down to the bare metal and build an efficient object-oriented system
|
||
from the ground up.
|
||
</p><p>
|
||
I especially like the <span class="trademark">Be OS</span>™. I look at the basic docs and how the OS
|
||
is put together and it looks like a clean, efficient system. I want to
|
||
build games on top of it. It's the first system since the Macintosh where
|
||
the mouse actually works correctly.
|
||
</p><p>
|
||
To start out with, we'd like to port our own code (a 3D sprite engine) to
|
||
the Be platform. We'd also like to convince our clients to let us port
|
||
some of the games we've ported to the Macintosh over to the BeBox. Stay
|
||
tuned!
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Gassee1-29"></a>Define Winning</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Jean-Louis</span> <span class="surname">Gassée</span></span></div></div></div><p>
|
||
Last week I referred to Bill Walsh. As a result, I got a good ration of
|
||
ribbing: “<span class="quote">How can a Frenchman raised on soccer even begin to appreciate
|
||
the subtle nuances of American Football?</span>” As a matter of fact, I endured
|
||
an overdose of soccer in Roman Catholic boarding school, and I'm watching
|
||
the calendar for Labor Day when I can compare Jimmy Johnson's hairdo to
|
||
Mike Ditka's.
|
||
</p><p>
|
||
But I won't invoke past or present coaches in vain anymore. So, we'll
|
||
skip Vince Lombardi and focus this week on our definition of winning. How
|
||
do we know—when will we know that we've won? Is it the day of the
|
||
sacrosanct IPO? Is it when we win our first lawsuit against Bill Lerach,
|
||
when we ship the first 100,000 machines, or reach 100 million dollars in
|
||
revenues? Or is it when we see Be Geeks on a magazine cover, read
|
||
accolades in "Upside," and watch Erich Ringewald, tanned and tattooed, in
|
||
a sunset fade on his sailboat?
|
||
</p><p>
|
||
There's a difficulty and fragility in any definition of winning. Remember
|
||
"Business Week's" 1984 cover, "And the Winner is IBM"? The joke gets
|
||
cosmically better when we realize IBM never made a buck in the PC
|
||
business. At the time, Apple was perceived to be the loser, after years
|
||
of winning with the Apple II, and before years of winning with the
|
||
Macintosh. Ashton-Tate won for a while, so did Software Publishing, but
|
||
—unlike Apple with the Mac—they failed to make a transition and
|
||
never recovered.
|
||
</p><p>
|
||
Then there's Microsoft. They never seem to have lost. Sure, they were the
|
||
unintentional fool in the database court for a while, but the laughter
|
||
stopped when they acquired FoxPro (for a fraction of the price Borland
|
||
paid for Ashton-Tate), and blew life into their second database product,
|
||
Access.
|
||
</p><p>
|
||
The moral seems to be about winning seasons rather than scores in
|
||
particular games. And yet, some teams with winning seasons get their
|
||
names spelled with four L's. So let's pick a definition of winning and
|
||
see if it fits.
|
||
</p><p>
|
||
First, there is the win for developers: For Be to win, our developers
|
||
must win. We have a unique opportunity to help fresh starts in the
|
||
application business, just as we are a fresh start in the platform
|
||
business. I'll make the risque statement that it's more important for us
|
||
to find the next Adobe than to convince Adobe that Be is their next
|
||
platform (this said with great respect for Adobe technical prowess and
|
||
aesthetic elegance). Yes, it would be great to run a Be-specific version
|
||
of Photoshop—and it would be even greater to find the next John
|
||
Warnock or the next Kai Krause. We would add more to the industry and
|
||
we'd probably get more as well.
|
||
</p><p>
|
||
Perception will add to the win: Being seen as a platform on which new
|
||
stars are born will attract more talent. As we win with and for
|
||
developers, we'll win with customers. We give them features and
|
||
price/performance unavailable elsewhere, they help us reach financial
|
||
independence, thus the very perception of success begets success.
|
||
</p><p>
|
||
Our shareholders (including Be employees) are next in line. If the
|
||
company is financially sound, there will be people wanting to buy shares.
|
||
Winning, in this sense, is making our professional investors liquid, and
|
||
helping Be employees along the road to freedom of mortgage.
|
||
</p><p>
|
||
We also want to win by impressing our severest critics: Ourselves. If
|
||
you'll allow the momentary immodesty, we're driven by qualitative and
|
||
aesthetic gauges. We do what we do because we hold to a high standard
|
||
when we measure the quality of personal computing, applications, and the
|
||
building of good businesses. To win in this arena means creating a
|
||
product that feels right, through the combination of the ingenuity of its
|
||
design, the integrity of its proportions, the quality of its execution,
|
||
and the hone sty of its distribution.
|
||
</p><p>
|
||
This may sound a bit too trite for your taste; but I can offer the names
|
||
of companies that won in some—but not all—of the constituencies
|
||
listed above. They didn't last. That consideration drives us also. The
|
||
Amiga was/is a great computer, but Commodore didn't last.
|
||
</p><p>
|
||
Yes, we are naive enough to think we can win, and we're experienced
|
||
enough to know that the future will surprise us no less than the past
|
||
5-1/2 years have.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="BeDevTalk1-29"></a>BeDevTalk Summary</h2></div></div></div><p>
|
||
BeDevTalk is an e-mail discussion group where Be developers and other
|
||
interested parties voice their opinions, commendations, and frustrations
|
||
about the state of the BeBox and the Be OS. In this column, we summarize
|
||
the most attended and contentious of the recent BeDevTalk threads and
|
||
supply, where applicable, the "official" Be opinion or clarification.
|
||
</p><p>
|
||
Threads are listed by the subject lines as they appear (literally, typos
|
||
and all) in the mail. (To subscribe to BeDevTalk, visit the mailing list
|
||
page on our web site: http://www.be.com/about_be/mailinglists.html.)
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id488587"></a>Subject: Suggestions for help system?</h3></div></div></div><p>
|
||
The BeBox lacks a help system. Currently, favor runs to:
|
||
</p><ul class="itemizedlist"><li>HTML (or, more generally, SGML) as the help document format</li><li>Help documents stored in app-specific subdirectories of a central help directory</li><li>The need for both contextual and "big-page" help (in Mac-speak: "Balloon Help/Apple Guide")</li></ul></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id488618"></a>Subject: Hierarcical tables? and more...</h3></div></div></div><p>
|
||
The design and philosophy of database tables is discussed. Some
|
||
questions: Since tables are identified by their names, should the
|
||
storage server provide some sort of name management? Participants
|
||
appreciate that tables are global creatures (and so allow apps to
|
||
easily share data), but should ALL tables be public?
|
||
</p><p>
|
||
THE BE LINE: The design and implementation of the database (including
|
||
the file system) is being revisited. We expect to announce the new
|
||
design sometime *after* DR8.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id488641"></a>Subject: Call for type/creator reorganization<br /></h3></div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">
|
||
A/K/A: File type proposal<br />
|
||
A/K/A: Be All and End All - A Proposal for "Be Types" (long)
|
||
</h4></div></div></div><p>
|
||
Is Be's four-byte document "type" identifier good enough? Alternatives
|
||
were suggested and debated (MIME, in particular). Similarly, the
|
||
application-identifying "creator" was examined—some folks question
|
||
its necessity.
|
||
</p><p>
|
||
For a good, detailed overview of this fiendishly long and winding
|
||
thread, see the page that Chris Herborth put together at
|
||
http://www.qnx.com/~chrish/Be/FileTypes.html.
|
||
</p><p>
|
||
THE BE LINE: The file system/database redesign will address most of the
|
||
issues raised in this thread.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id488677"></a>Subject: Dynamic docks and mouse buttons</h3></div></div></div><p>
|
||
Related to (and sprouted from) the type/creator thread, the arguments
|
||
in this thread broach interface issues: Given a file, how can the user
|
||
most easily find and launch the app that will best display the file's
|
||
contents? To this end, a "dynamic dock" was proposed in which a palette
|
||
of candidate file-opening apps is displayed when you drag a file icon.
|
||
Subject: Storage Kit limitations (request for UNIX features)
|
||
</p><p>
|
||
A number of file system features are seen to be lacking: Mountable
|
||
foreign file systems, network file systems, symbolic links, memory
|
||
mapped files. Many solutions/suggestions have been offered and rebutted.
|
||
</p><p>
|
||
THE BE LINE: Have no doubt that foreign file systems (in particular of
|
||
the shortcomings mentioned in the thread) will be supported. Finding
|
||
the "correct" solution will be one of the primary tasks in the file
|
||
system rewrite (which, as mentioned above, is scheduled for post-DR8).
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id488711"></a>Subject: GUI/shell replacement</h3></div></div></div><p>
|
||
This thread concentrates on a proposed "modularization" of interface
|
||
elements, the app server, the Browser, the shell, and so on. Advocates
|
||
of configurable look and feel would like to be able to replace small
|
||
GUIpieces (such as scrollbars) as well as entire systems (the shell,
|
||
the window drawing portion of the app server).
|
||
Subject: Java ports?
|
||
A/K/A: Plugin Format (JAVA!)
|
||
</p><p>
|
||
Anybody want to port JAVA? Some questions regarding JAVA security (and
|
||
efficiency) grew into a wider pondering of how different languages
|
||
should transmit script-like requests between processes.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id488735"></a>Subject: GUI on UNIX?</h3></div></div></div><p>
|
||
This thread suggests that GUI and UNIX needn't be so beastly to each
|
||
other. With no nay-saying (so far), the participants take a "why not?"
|
||
attitude toward such things as a cron app and "visual" (UNIX) pipes.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id488750"></a>Subject: UI comments</h3></div></div></div><p>
|
||
Complaints and suggestions regarding certain aspects of the UI, notably
|
||
"choice-enforcement" buttons in preferences panels (and other such
|
||
attribute-setting windows). Should they emulate the Amiga's
|
||
Save/Use/Cancel triad (for example)?
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id488765"></a>Subject: BE—No-show at PC Expo??</h3></div></div></div><p>
|
||
Be, Inc. didn't attend PC Expo. Some participants wonder how this
|
||
absence can be explained.
|
||
</p><p>
|
||
THE BE LINE: We simply don't have the bandwidth to attend every
|
||
conference and expo. Furthermore, while PC Expo is important to the PC
|
||
user industry, attendance by our audience (developers) is small. Had we
|
||
attended the Expo, we would have had to short-change some other
|
||
developer-heavy conferences (MacHack, MacWorld, Be's European GeekFest,
|
||
etc.). Look for us at PC Expo '97.
|
||
</p></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue1-28.html">Issue 1-28, June 19, 1996</a> Up: <a href="volume1.html">Volume 1: 1995–1996</a> Next: <a href="Issue1-30.html">Issue 1-30, July 3, 1996</a> </div><div id="footerB"><div id="footerBL"><a href="Issue1-28.html" title="Issue 1-28, June 19, 1996"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume1.html" title="Volume 1: 1995–1996"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue1-30.html" title="Issue 1-30, July 3, 1996"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|