|
Be Newsletter
Issue 29, June 26, 1996
Table of Contents
BE DEMO TOUR IN TEXAS: Be Demo
Meetings in Austin, Houston, Dallas
- JULY 16
University of Texas at Austin
WHAT: Austin BUG Meeting Demo
WHEN: 6:30 pm, Tuesday, July 16
WHERE: Taylor Hall 2.106 (2nd floor, room 106),
University of Texas at Austin (Taylor Hall is on the
corner of Speedway and 24th)
MEETING NAME (for registration): UT-Austin Tuesday
- JULY 17
University of Texas at Austin
WHAT: Austin BUG Meeting Demo
WHEN: 6:00 pm, Wednesday, July 17
WHERE: Goldsmith Hall 3.120 (3rd floor, room 120),
University of Texas at Austin (Goldsmith Hall is on the
corner of Guadalupe and 22nd)
MEETING NAME (for registration): UT-Austin Wednesday
FOR MORE INFORMATION: The Austin BUG has provided maps
to aid your search for Taylor and Goldsmith Halls. See
http://www.be.com/user_groups/events/austin.html on the
Be web site.
- JULY 18
University of Houston at Clear Lake
WHAT: Be Demo at the Institute of Electrical and
Electronics Engineers (IEEE), Galveston Bay Section
meeting
WHEN: 6:45 pm, Thursday, July 18
WHERE: Bayou Building, Forrest Room (next to cafeteria),
University of Houston at Clear Lake
NOTE: This demo is being held during the IEEE Galveston
Bay Section meeting, with an optional social and dinner
beforehand. The social begins at 5:30 pm with dinner at
6:00. If you're interested in attending the social &
dinner, please contact Charlotte Garner at (713)
333-6131. Attendance at either event is not required in
order to attend the BeBox Demo at 6:45.
MEETING NAME (for registration): IEEE Meeting
- JULY 20
Dallas, Texas
WHAT: Be Demo at the Apple Corps (Macintosh) Meeting
WHEN: 8:30 am, Saturday, July 20
WHERE: Informart, Room 7001, 1950 Stammons Freeway,
Dallas, Texas
MEETING NAME (for registration): Apple Meeting
WHAT: Be Demo at the SCOPE Meeting (Commodore and
Amiga)
WHEN: 1:30 pm, Saturday, July 20
WHERE: Informart, Room 3008, 1950 Stammons Freeway,
Dallas, Texas
MEETING NAME (for registration): SCOPE Meeting
REGISTRATION FOR BE DEMO TOUR EVENTS: E-mail
bedemotour@be.com to
register for either event. Please tell us your name, the
names of the people coming with you, and the meeting name
(UT-Austin, Tuesday or Wednesday; IEEE Meeting; Apple
Meeting; or SCOPE Meeting). Admission for unregistered
guests will be on a first-come, first-served basis.
BE ENGINEERING INSIGHTS: PEF - The
Patently Extraneous Format
By Erich Ringewald
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.
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.
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:
int very_important_table[300000] = { 12345
};
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?
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.
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.
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.
BE DEVELOPER TALK: Green Dragon
Creations, Inc.
By Howard Shere, President, Green Dragon
Creations, Inc.
E-mail:
hshere@greendragon.com
URL:
http://www.watervalley.net/
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.
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."
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.
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?
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.
I especially like the Be OS(TM). 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.
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!
Define Winning
By Jean-Louis Gassée
Last week I referred to Bill Walsh. As a result, I got a
good ration of ribbing: "How can a Frenchman raised on
soccer even begin to appreciate the subtle nuances of
American Football?" 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
BeDevTalk Summary
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.
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.)
- Subject: Suggestions for help system?
The BeBox lacks a help system. Currently, favor runs
to:
- HTML (or, more generally, SGML) as the help
document format
- Help documents stored in app-specific
subdirectories of a central help directory
- The need for both contextual and "big-page" help
(in Mac-speak: "Balloon Help/Apple Guide")
- Subject: Hierarcical tables? and more...
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?
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.
- Subject: Call for type/creator
reorganization
A/K/A: File type proposal
A/K/A: Be All and End All - A Proposal for "Be Types"
(long)
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.
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.
THE BE LINE: The file system/database redesign will
address most of the issues raised in this thread.
- Subject: Dynamic docks and mouse buttons
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)
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.
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).
- Subject: GUI/shell replacement
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!)
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.
- Subject: GUI on UNIX?
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.
- Subject: UI comments
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)?
- Subject: BE -- No-show at PC Expo??
Be, Inc. didn't attend PC Expo. Some participants
wonder how this absence can be explained.
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.
|
