|
Be Newsletter
Issue 44, October 9, 1996
Table of Contents
Be Demo Tour: BeBox Demo in Illinois!
Be, Inc. is coming to the University of Illinois in October
to show the BeBox.
REGISTRATION FOR BE DEMO TOUR EVENTS: E-mail
bedemotour@be.com to register for any event. Please tell us
your name, the names of the people coming with you, and the
meeting name (Houston, Austin Wednesday, or Austin
Thursday). Admission for unregistered guests will be on a
first-come, first-served basis.
BE ENGINEERING INSIGHTS: Be on the Mac
By Bob Herold
At the Macworld Expo in Boston last August, Be demonstrated
a version of the BeOS(TM) running on Macintosh hardware. In
light of all the mischief this caused, a brief romp through
the technical issues should be entertaining. At least to
some.
How did we get the BeOS to run on a Mac? Tackling the
intricacies of starting an alternate operating system using
the Mac ROM's Open Firmware was too much to stomach on the
hard deadline schedule that we had for Macworld. So, we took
the easy route: Rather than boot from scratch, we let the
Mac OS come up, and then we launched the BeOS as an
application. The application is called OS Doubler, a name
sure to send some lawyers scurrying for their legal pads and
cell phones. Lest they get too upset, remember that this was
just a demo.
OS Doubler loads a piece of code that's remarkably similar
to the boot ROM in the BeBox. This code is called
BeOS_Enabler -- a name that is, we realized later, a bit
confusing since it has nothing to do with Mac "enablers."
More lawyers -- yikes!
Once BeOS_Enabler is loaded, the application grabs complete
control of the machine and jumps to the start of the
enabler. From there, things proceed much as they do on the
BeBox: Look for disks with a Be file system, find a kernel,
load it, start the app_server, and so on. The Mac memory
image slowly disappears, eroded by the constant infusion of
vibrant new BeOS code.
The Mac version of the BeOS differs very little from the
BeBox version. The kernel is different, and a few drivers
were added and some removed to address the different
peripheral hardware controllers. The rest of the software is
the same.
What Macintosh platforms does/will the BeOS run on? The demo
ran on a very limited subset: The 7200-based platform with a
604. In fact, it didn't support the 604e when we arrived in
Boston. Power Computing lent us one of their new boxes, we
got the kernel sources in the booth after hours, added 604e
support back in the hotel room, and demonstrated a 225 MHz
system the next day!
Here's a list of the architectures that we support now and
those that we plan to support in the coming months:
Now (the demo):
Power Computing PowerCenter (7200, 604)
Power Computing PowerTower (7200, 604)
Power Computing PowerTower E (7200, 604e)
November developer release (DR8 software with better Mac
support):
Power Computing PowerWave (9500, 604)
Power Computing PowerTower Pro (9500, 604e)
Apple 9500 (604)
Apple 7600 (604)
Apple 8500 (604)
UMax S900 (9500, 604)
Q1 97 (DR9 with complete Mac support):
Power Computing PowerBase (5400, 603)
Apple 5400
The 9500 support involves writing a few graphics card
drivers as there is no onboard graphics controller in that
machine. We need to write a SCSI Interface Module (SIM) for
the 9500's MESH SCSI controller. We also want to quickly add
support for the onboard Ethernet controller -- for Macworld,
we used one of the PCI cards we ship in the BeBox.
Supporting the multiprocessing cards is high on the list as
well. The BeOS is built for SMP from the ground up, so this
is a natural fit. Barring any unforeseen technical problems,
this should be straightforward. All the words count here...
Living comfortably in the Mac world is very important. Media
sharing, network compatibility, and installation all are
important issues. We will tackle them all and come out with
the BeOS on the Macintosh in Q1 next year.
NEWS FROM THE FRONT: A Pleasurable Stick?
By William Adams
I recently joined Be, Inc. as a Technical Evangelist. My
mission (as I've decided to define it) is to spread
merriment, write code, and help developers realize how fun,
easy, and beneficial it is to develop applications for the
BeOS. To this end I will be producing a number of
applications and tools that help developers get the most out
of our system. At the same time, I want to find out what
you're thinking and get your comments right back to the Be
engineers as quickly as possible.
I've been one of you before: I was a third-party developer,
critic, sometime-advisor, and guinea pig for NeXT and NT.
I've also worked with things that never really saw the light
of day, such as Taligent.
I'm a decent, highly opinionated programmer who thinks he
has something to say about everything. And that's why I
joined Be. I like the BeOS so much that I couldn't pass up
the opportunity to take my opinions right to the source
where they will have the most impact.
I really enjoy the bleeding edge. I feel most comfortable
pushing the envelope, while at the same time presenting with
dramatic understatement the power of a new technique,
algorithm, or paradigm.
The BeOS offers a fertile ground upon which many
applications will find purchase. As I see it, my job is to
help developers ply their trades on this fertile ground and
produce applications that they and their users will find
great pleasure in and laugh giddy with excitement down the
halls because it was so easy to do. But the system isn't
perfect and is ever-evolving. So that's the other part of my
job, to bring your comments into our house so our engineers
can benefit from our developers' wisdom to make a better
system.
Every week I'll present "News from the Front" in the "Be
Newsletter." There's a lot of information in the Be
community -- some of it ends up on the comp.sys.be news
group, some ends up on the BeDevTalk mailing list, and still
more shows up on the ftp.be.com ftp site. I'll summarize
some of the more interesting things and try to highlight new
apps that no one can do without.
In addition to the highlights, we'll put out "From The
Bench." These are application snippets that either I have
written, or I have wrenched out of the hands of some poor
unsuspecting engineer while they were screaming "it's not
clean enough yet!!"
To start things off, my first sample deals with the care and
feeding of the game controller ports on the BeBox. This
sample code shows how these interfaces can be used in a
multithreaded environment to maximum effectiveness. Some of
the concepts demonstrated are:
- Polling a device using a thread
- Automatic calibration and self-centering a joystick
- Message dispatching
The tutorial packet can be found at:
ftp://ftp.be.com/pub/Samples/Joystick.tgz
I have also taken on responsibility for the sample code that
currently exists at the site. I hope to keep it up-to-date
with the current release, and will archive old stuff for
posterity.
Well, I weaseled my way into this issue of the newsletter,
and even wangled myself a permanent spot. So, I hope y'all
are ready to have some fun, because I'm enthusiastic about
programming this OS, and I intend to spread my infectious
enthusiasm as widely as possible.
BE DEVELOPER TALK: Frithjof Kuntze, Johns Hopkins University
E-mail: fritz@entropy.bph.jhu.edu
The goal of my endeavors with the Be system is to develop
low-cost molecular modeling software for students and
researchers who need power and a sophisticated graphic
interface, but who don't have the financial resources for an
SGI. My interest is in providing a software tool that has
the performance to allow users to visualize their ideas
without being chained to the canned algorithms supplied with
many commercial applications.
Currently, I am completing a PhD in molecular biophysics.
Most of my work is developing computational studies that
predict the structural stability of proteins under changing
solution conditions. But a personal interest in computers
has taken me further towards software than science. My
NeXTstation is still running as good as the day I bought it
six years ago, and when I first heard of Be, it seemed a
kindred spirit. In addition, the multiprocessor technology
is appealing since it promises better price/performance for
the kind of graphics-intensive work I am interested in.
Working with Be is a chance to find like-minded people with
a vision who are willing to take risks. The port of OpenGL®
sounds like another opportunity to expand my horizons, but I
hope to incorporate its strengths into my software. So far,
the hardest thing for me has been figuring out how to
organize a commercial-grade application (all thrust, no
vector). The projects I have designed myself are relatively
large but nothing I would think of as having commercial
characteristics (for example, robust error checking,
standard documentation, and upgradability).
BE MARKETING MUTTERINGS: Channeling
By Alex Osadzinski
As a relative newcomer to the US, much of my knowledge of
the culture of this great country has been derived from what
I read and saw while still a resident of England. During my
formative years, I learned all that I needed to know about
the US by watching Kojak, Hawaii-Five-O, Scooby-Doo, The
Monkees, and Lost in Space, and by reading books about
American history. One learning experience stayed most
strongly with me and, ultimately, affected my decision to
move to California: A British documentary about the
eccentricities of Californians. Nobody loves and embraces an
eccentric quite like the British, and nobody is able to
examine the eccentrics of other nations with quite the same
combination of smug superiority and restrained amusement.
The documentary in question portrayed a number of activities
popular in California during the 1980s: Self-trepanning
(cutting a hole in one's skull, mostly to see what would
happen), crystal therapy, psychic counseling, and (my
favorite) channeling. It was channeling that most caught my
attention: Earnest individuals who claimed that, during what
Edgar Allen Poe called "moments of exquisite tranquillity,"
their minds were controlled by spirits. For those brief
moments, they became representatives of the spirits,
speaking in their voices and generally behaving like them.
My decision to move to California was partly solidified by
seeing one such person seated in a room filled with bemused
Californians who had paid $295 for the privilege, channeling
a deceased dolphin. As the possessed channeler squeaked,
clicked, whistled, and hissed, I concluded that any state
that would put up with this would definitely tolerate my
relatively mild peculiarities. And any state where people
would pay $295 to watch this would probably afford me a
decent living.
The people with holes in their skulls, those with fingers
callused from rubbing too many crystals, those who no longer
feel the spirit of the dolphin and the ones who've put away
their crystal balls survive (mostly) into the 1990s as HR
managers and 900-number psychic friends. But the concept of
channeling remains interesting to me and, with a little
luck, to you.
Be is a small company, with growing, but modest, sales. Most
of our customers are developers, and most of them interact
directly with us. However, as our application base grows, so
will the number of people using a BeBox or the BeOS to do
something other than develop programs. Some of those people
will want to buy directly from our web site, while others
will prefer to deal with someone more local, more relevant
to their application, or simply someone more familiar. It's
important to everyone at Be to stay close to our customers,
because it makes good business sense and because, well, we
like customers! So our strategy is to create channels that
can represent both Be's spirit, and Be's products.
During the next few weeks, I'll be exploring our channel
strategy. As always, I'm very interested in your comments
and feedback. In our channel strategy, we're aiming for
simplicity, just as with the rest of what we do. So you
won't see a whole lot of discussion of staircase discounts,
minimum commitments, coop funds, bill backs, and other
channel arcana.
The earliest, and perhaps the simplest, channel for Be
products is Value Added Resellers (VARs). Already, some of
our developers, with products nearing completion, wish to
sell a packaged solution to their customers. That package
includes some combination of BeBoxes, the BeOS, custom
hardware, and custom software. This is the simplest and
"purest" channel in that the customer is really buying the
solution, and not just a BeBox or just the BeOS. The
customer may not even know or care that Be technology is
present; do you really care if your car's trip computer is
managed by a Motorola or Intel CPU? The VAR is responsible
for first-line customer support, with Be providing warranty
and software support to the VAR as required. In return for
providing volume sales, a single ordering point, and first-
line support, the VAR is able to buy Be hardware and
software at a discount. Conflict between VARs is minimal, as
each has its own unique value to add and the customer is
choosing on the basis of solution quality, not hardware
pricing. Our VAR program is ready to roll, so if you're a Be
developer wanting to package a solution for your customers,
rather than simply selling software and letting customers
assemble the solution themselves, please drop me a line.
In future articles, we'll explore other channels, none of
which, sadly, are as simple as the VAR channel, but which
offer the dual promises of choice and flexibility.
Seymour Cray
By Jean-Louis Gassée
One of our early shareholders passed away. Seymour Cray. Two
weeks ago, on a highway North of Colorado Springs, a driver
made a risky passing move. Seymour's Jeep was broadsided and
rolled over. Seymour suffered massive head, neck, and chest
injuries and died last Saturday in the early morning hours.
He was 71.
I met Seymour for the first time in December 1985 in Eau
Claire, Wisconsin. As Apple was purchasing a Cray X-MP for
its R&D organization, we came to visit the Cray Research
production line and meet the great man. Later, in 1989,
Seymour invited me to serve on the board of directors of his
new company, Cray Computer Corporation, located in Colorado
Springs. There, I witnessed him challenge the laws of
physics -- and capital formation -- until the company folded
in 1995.
When I left Apple and started Be, Seymour kindly expressed
interest in helping us. So one day in September 1991, Steve
Sakoman and I flew to Colorado Springs and gave a
presentation of our project to Seymour and Neil Davenport,
the company's CEO. Seymour stood still during the process
and asked very few questions -- I was terrified and wondered
if I had said something unspeakably stupid. We rode to
dinner in Seymour's Jeep, he never locked it and left the
keys in the ashtray, an amazing habit for someone born and
raised in Paris. On the way to the restaurant, Seymour
jokingly complained to Neil that he was losing money on his
gold investments. I suggested a stake in Be might be a way
to compensate for that. He smiled: "Why not?" Finally, at
the dinner table, I had to ask if he meant what he'd said in
the Jeep. Yes. How much? One million. Seymour never wasted
words.
A month later we had dinner at my house in Palo Alto and a
misfolded carpet caused a plateful of osso bucco to take
flight and hit the dining room wall. As we nonetheless got
Seymour's check the following day, the dish became known in
the Gasse family as the million dollar osso bucco.
Seymour's career is too well documented for me to add much
to the public record. His name became synonymous with
supercomputers, and we're sure to see many articles, books
and web sites celebrating his achievements. One of us,
Dominic Giampaolo, suggests the following two URLs:
http://www.usa.net/gazette and
http://innovate.si.edu/history/cray/craytoc.htm.
The media made much of Seymour's alleged or real
eccentricities. "Time" magazine yesterday made derogatory
comments about a habit Seymour had for a part of his life:
Building a boat during winter, sailing it during summer, and
burning it when autumn came. I had asked him about this. He
just wanted to move on to the next design, unencumbered by
the past. Something he did all his life when he started
Control Data, then left and started Cray Research, going to
a repro shop to print stock certificates and selling shares
from the Control Data parking lot.
My last meeting with him was in June of this year. He was
quite philosophical about the demise of his last venture and
ready to start a new one. At the time, he was considering a
deal for Intel's ailing supercomputer business, for the
customer list he said. In any event, he had ideas for the
large memory systems required by supercomputers and "having
been hit over the head enough by microprocessors" intended
to use them in his next design. I'm sad to see Seymour die
prematurely, in the midst of planning yet another start-up,
SRC, but he led a good life and I'm grateful for his
generous help and for the memories of a hero of our
industry.
BeDevTalk Summary
BeDevTalk is an unmonitored discussion group in which
technical information is shared by Be developers and
interested parties. In this column, we summarize some of the
active threads, listed by their subject lines as they
appear, verbatim, in the mail.
To subscribe to BeDevTalk, visit the mailing list page on
our web site: http://www.be.com/aboutbe/mailinglists.html.
- ---WEEK 5-------------
Subject: AES/EBU
Subject: COMPLETE Newsletter article #42, September 25, 1996
If Be can't provide highest-quality audio equipment because
of the cost, could Be at least build some extensions to the
hardware that it could sell to audio-interested developers?
The theory is that Be could do a better job of building and
supporting their own hardware than a third party could do
with a card.
The premise of the no-AES reasoning was questioned: It was
contended that computer users are (or should?) be willing to
pay for good audio as part of a base technology.
- ---WEEK 2-------------
Subject: Application Architecture
Can you use the same image as both an add-on and a distinct
executable? Yes. This flexibility was lauded, but its
corollary -- executables and add-ons have the same file type
-- was condemned.
- ---NEW----------------
AKA: There is no OS UI like no OS UI.
AKA: hot boot
Should the UI and the OS be "just friends?" It was suggested
that the Be GUI be abstracted from the OS proper, thus
allowing different GUI standards on, potentially, different
hardware. The rebuttal: A nice theory, but the overhead to
"re-couple" the two layers (messaging, for example) would
probably be deadly.
This led to a discussion of "hot booting," different schemes
to decrease boot time: "snooze" mode; ROM-loaded OS;
loadable, preconfigured environments.
- ---NEW----------------
Subject: Clicks, doubles n' drags
AKA: User profiles
This human interface thread focused, mainly (but only as an
example), on the "correct" ways to dismiss an application.
Should a developer define app-specific quit methodologies
(such as double-clicking a window's title bar)? Or should
deference to the user's learned behaviour be the guide?
- ---NEW----------------
Subject: General Cursor Stuff
How do you set your own cursor? Currently, you do it through
the BApplication object -- but there was an impassioned plea
for a dedicated BCursor class.
- ---NEW----------------
Subject: Is your BeBox your primary machine?
A call was made for a show of hands of those folks who use a
BeBox as their "everyday" computer.
- ---NEW----------------
Subject: OS services...
It was suggested that the BeOS should provide some sort of
URL recognition, such that you could open an Internet
address just as easily as you can open a file.
- ---NEW----------------
Subject: Plug-in thought
Should Be settle on a standard for "global" add-ons (or
plug-ins)? It was considered a reasonable request to allow a
single add-on to be called by *any* application that can use
the add-on.
- ---NEW----------------
Subject: PPC Optimisation question
This week's computer science question asked for the fastest
method of stuffing four bytes into a single ulong. The
answer: Use assembly code. This lead to a discussion of the
utility of register declarations (not needed), and some
questioning of the way certain inline (and so header-
visible) functions are implemented.
- ---NEW----------------
Subject: Real Desktop?
Should the Be "desktop" act like a general-purpose clipboard
(a la Macintosh)? Some say yes, some no, and, of course,
there was a vote for providing a preference to let the user
choose.
- ---NEW----------------
Subject: App-server connection
Can the message-based communication between an application
and the app server be extended to allow the user to "drag" a
window or running application between BeBoxes?
|
