|
Be Newsletter
Issue 59, February 5, 1997
Table of Contents
BE ENGINEERING INSIGHTS: Dogcows and Goodbyes
By Joe Palmer
On my way home last night I passed under highway 280 on
Alpine Road. It wasn't a momentous or meaningful occasion --
I drive that way home almost every night -- but you see
there is a pothole under the bridge that looks a little like
Clarus the dogcow (aka "Moof"). Passing over it and
marveling at the randomness of the universe that would
causes a pothole in the shape of a famous Page Setup dialog
box icon to be created is just one of the little things that
I'll miss about working at Be. He's been there for a while
now, and with the erosion of the road surface he's put on a
little weight.
I can't say why that sticks in my mind today, but this
afternoon as I drove back from Mountain View, where I
registered a domain name for my new venture, I was reminded
of the feelings I had 18 years ago moving out of my mother's
home in Green Bay, Wisconsin, to make my future in
California. As I drove my '69 Red VW Van, "Fritz," down
Highway 1, I was overcome with mixed feelings. When I looked
in the rear view mirror I felt remorse and loss and felt an
urge to drive back and throw out the anchor in Green Bay,
but the future was there in the windshield. Up there I had a
wide-screen view of a starkly new world. Warm air caressed
my arms through the open windows, assailing my nose with
sea, dirt, and flowers. The roar of the Pacific called to
me, "Hey! where have you been all your life?"
With every corner I felt a flush of life, newness, and
anticipation. I had this cassette tape that my friend John
had made for me. When I passed Big Sur I plugged it into the
player, having saved it for just that moment. The Grateful
Dead's Estimated Prophet* came pouring forth. I never felt
more alive. I was home.
Be is leaving the hardware business, and I am leaving Be,
and how do I feel? I feel good. I feel good because it's the
right thing for Be to do. You as developers should feel good
about it too, because it means that Be is determined to make
decisions that will benefit the long-term viability of the
BeOS, and your BeOS applications. Be has proven that it's
willing to stop doing something when it stops making sense.
As someone personally affected by this decision, I think it
is my place to say that this is a remarkably rare virtue
these days. I'm very proud of the work I've done for Be and
consider it to be the best work I've ever done, but now my
job here is done. The BeBox(TM) gave the BeOS a safe nursery
at a time when other platforms were far more hostile to yet
another (unproven) OS. The BeBox proved to be a pedestal on
which to display the capabilities of the OS. Those of you
who've been frightened** by my demos will remember that I've
always stressed that the software is the most important
thing, and that the hardware was only there to run the
software. Now the BeOS has found its way to the Power Mac,
and thousands of new developers can see what the shouting is
all about. (Hint: It's the OS, stupid.)
I like to make up metaphors, as Jean Louis will attest, and
this one comes to mind today. On a warm summer night in
1969, I stood in my yard in northern Minnesota and looked at
the moon. There was no traffic that night, and every house
in view was darkened, but lit from within by the bluish glow
of televisions tuned to Tranquillity base. A few days
earlier a Saturn rocket had lifted from the Kennedy space
center, a noisy necessity to putting man on the moon. The
booster did its job and placed the rest of the ship in low
earth orbit. Then its job was done, and the attention of the
world turned to the moon. I like to think that the BeBox is
in some way related to that thunderous booster. Its job of
lifting both Be and the BeOS safely into orbit is complete,
but the focus must now be on the OS and applications. While
it might be romantic for a little company to be in the
computer hardware business (let's stretch this metaphor till
it creaks), think of the odds of success for our hero, Mr.
Armstrong, should he have elected to bring that booster
along with him to the Sea of Tranquillity.
For those of you wondering what I might be up to next, I'm
now dreaming the Silicon Valley dream and will be putting
together my first start up. I'd always planned to start my
own company one day when Be was successful, but now with Be
leaving the hardware business, I guess today is a good day
to start a new business.
I'm not prepared to go public with my product plans, but my
new venture is called "Video Storage Systems," so you may
safely guess it involves video hardware, and yes it will
work with the BeBox. I haven't gotten confirmation on my new
domain name yet so I won't reveal it, but those of you
interested can watch for an announcement on my personal home
page full of Ranma 1/2 Fan fictions:
http://www.best.com/~jpalmer
* You can find Estimated Prophet on Terrapin Station. Or see
the lyrics at
http://cyclone.weather.net/zarg/dead.htmls/EstimatedProfit.html
** From comp.sys.be, where I was once accused of giving
demos that scared small children.
BE ENGINEERING INSIGHTS: Graphics Drivers are Hardware Devices Too
By Scott Bronson
First, an introduction. Consider for a moment the expressive
simplicity of a file. A wide number of things in this world,
both conceptual and physical, can be expressed in terms of
open, close, read, write, and seek. And, of course, ioctl
fills in any metaphor imperfections. Eek! Maybe I'd better
get outside, but not until I explore this further.
Device drivers are particularly well suited for a file
metaphor. All hardware devices need to be opened and closed.
Reading, writing, and seeking are optional but useful when
the metaphor fits. In fact, you can see that the BeOS has
been tending in this direction for years. In DR8 and
previously, to open serial port 2, you:
int fd = open( "/dev/serial2", O_RDWR );
This will be fully realized in DR9. "/dev/serial2" will no
longer be a pseudo-pathname. Finally the /dev directory will
be a complete and upstanding member of the DR9 file system.
You'll be able to use POSIX calls, the BeOS file system API,
and even shell commands to manipulate devices. For instance,
to list all installed serial ports:
$ ls -l /dev/serial
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 Modem Port
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 Printer Port
Even though these aren't files, their charade is very
convincing. There are only two differences to notice here.
In the first column, where 'd' normally indicates a
directory and '-' a file, 'c' indicates a character device
and 'b' indicates block. Also, these files appear to be zero
bytes in size. Were you to open one, however, you would find
that reading and writing would work as expected and seeking
would be ignored.
As an example, say it's nighttime, and for now you want your
modem to operate silently. If your modem or terminal program
didn't come with this feature (most don't), have no fear.
Using the shell to send the modem the appropriate AT command
is as simple as:
$ cd /dev/serial
$ echo "AT &M0" > "Modem Port"
To save typing and memorization, this would fit nicely into
an alias or shell script. Flexible, simple, standard. I love
it.
Another great DR9 benefit is that graphics drivers will move
back into the kernel, rejoining their driver siblings. This
allows graphics drivers to service and synch to VBLs,
perform DMA, respond to drawing-completed interrupts, and do
just about anything else that would be expected of any self-
respecting driver. This, of course, means that the boot
process will be quite different.
When the kernel is starting up, it asks each driver in the
/system/drivers directory to install itself. The driver will
interrogate the system, installing one entry per hardware
device found into the /dev directory. All graphics drivers
will ask to be installed into /dev/graphics, serial drivers
into /dev/serial, and so on.
For example, assume a particularly well-equipped system has
a TwinTurbo 128 and two Xclaim VR cards installed. The IMS
driver will find its card and create its "TwinTurbo 128"
/dev/graphics device. The ATI driver will find the two
Xclaim VR cards and install a unique entry for each. All
other graphics drivers in /system/drivers (S3, Cirrus, and
so on) won't find appropriate hardware and therefore won't
install anything into /dev. This would be the result:
$ ls -l /dev/graphics
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 TwinTurbo 128
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 Xclaim VR (Slot A1)
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 Xclaim VR (Slot B4)
Later in the boot process, the Application Server starts up
and opens and uses the graphics devices found in
/dev/graphics. It will not, however, coddle them as it has
in the past. The driver will now (as appropriate) have to
enable its device's PCI spaces, initialize its hardware, and
even map its own memory spaces. Don't worry, we'll tell you
how.
Notice that nowhere in this process has a PCI-centric
assumption been made. Feel like getting that dusty ISA VGA
card working? Remember those early PowerBook SCSI displays?
The possibilities are wide open.
All interaction with a graphics driver will be through
ioctl. Read and write will do nothing. In addition to the
standard Get/SetRaster, Get/SetIndexedColor and Get/SetGamma
requests, we'll include Get/SetPowerState for VESA power
management and GetSense for Apple Cable Sense. VESA's DDC
(Display Data Channel) won't make it into DR9, but we'll
leave room for it.
An important distinction: The kernel driver only sets up the
frame buffer; it doesn't draw. Drawing using hardware
acceleration is finicky, difficult, and subject to very
different requirements than kernel graphics drivers.
Therefore, another piece of code will be called upon to
draw. The final acceleration architecture won't be in place
when DR9 ships, so we'll have to continue to put up with the
copious synching performed by DR8 for now. But don't worry,
we won't have to put up with it for long.
We'll include a compatibility driver that will support all
loyal DR8 drivers, easing DR9 adoption. Don't hesitate to
start using that Millenium or Trio64V+ card; its driver will
continue to work.
Is it any wonder I'm excited?
News from the Front
By William Adams
My daughter has had this one comfort since birth. It's a
multicolored segmented snake. Its name is Annie. My daughter
likes to hold onto it because of the neat colors, and some
of the segments make a crinkly sounds or have bells in them.
We like her to experience new things, though. So we've
introduced her to new toys which don't have the same
features as Annie. Usually she's a bit reluctant at the
start, but then she really warms up to it and has a good
time. One of her current favorites is this four-wheel car
thing that she can ride around the house with the help of
some people power... Put your feet up... Wheee. By embracing
the car, she's found that she can go more places and have
more fun than she could with Annie alone. Annie still serves
her purpose but has been relegated to night duty in her
crib.
And so... This week, as promised, we have new serial support
for the Power Mac version of the BeOS. When the MacTech CD
went out, we didn't have support for PPP because we didn't
quite get the serial driver working by the time the CD
needed to be pressed. Since then, many users have lamented
the fact that they couldn't connect to the Internet from
their new BeOS Power Mac. Well, now we remedy the situation.
The caveats:
Truly supported PPP won't really be available until DR9.
That's to say, we're anxious to hear how things are going
for you, but our main work is concentrating on DR9, so if
there's an obscure problem, it may not be fixed until DR9.
PPP has been tested with a few modems on a few Macs, but we
haven't done extensive testing with all configurations. Here
you can possibly help us. When you have a configuration that
works, let us know.
You must have a thick skin and patience to use a developer's
release, and this software is offered in the same spirit.
ftp://ftp.be.com/pub/dr8_update/macserial.tgz
Before joining Be I did a lot of BeOS software that ended up
at my own Web site and never at the Be ftp site. One of the
pieces that I did was called the esoteric library. This was
a library of things that are useful for programming in C++.
I want to use these thingies in some of our tutorials, so
I'm bringing them into the fold.
ftp://ftp.be.com/pub/samples/support_kit/obsolete/bebits.tgz
Take a look. Utilities, sorting algorithms, container
classes, that sort of thing. Of course the standard C++
library will cover some of it, but not all of it.
Geoff Woodcock is at it again. Geoff has a wild hair to do
networking stuff, and he wanted to create a tutorial that
was fun and showed off networking. So he's come up with this
multi-user drawing thingy that allows you to do drawing over
the net. The tutorial will not be available until next week
some time, but I thought I'd mention it anyway. We'll be
working on three or four more DR8-specific tutorials before
we move on to preparing for DR9.
And how do we get to DR9? Well, last week I sort of hinted
at wanting get apps up and running before DR9 actually ships
out the door. What I'm thinking is that we want to have a
porting lab. That is, an opportunity for developers to come
to Be a little before DR9 ships to port their wares. I think
we can benefit from having apps ported before DR9 shows up,
so we don't have to send out a disk with only our demos
available. We want to highlight the work of our third-party
developers and give them early exposure, and I see this as
an excellent opportunity.
So if you think you would want to participate in such an
event, please send me e-mail (wadams@be.com). It promises to
be an exciting time, and no doubt you'll have a lot of fun
being the first on the block. No dates or other details have
been set yet, but we want to know whether it's worth
pursuing. Of course space will be extremely limited, so only
think about coming if you absolutely want to get early
exposure.
As DR9 approaches, we'll see some of our developers turn
toward seriously commercializing their products. One thing
that the Be platform has offered is extremely high exposure
for the smaller developer. But there's one thing missing.
Small developers want to code. Some of them want to run
companies and become big developers. For those who don't
want to make the big time, but want to be rewarded for their
efforts, shareware is often an option. Others will want to
go with a more traditional publishing route, with
advertising and the like.
One of the things that Be Developer Services can do is help
developers bring their products to fruition. That is,
helping with suggestions on commercialization, helping put
developers in contact with publishers, and helping put
together partners that make sense.
So you can look forward to our getting more into your
business if that's what you desire. Our mission isn't only
to help you program but to make sure that the fruits of your
labors bring you commercial success.
Mailing List Mumbo Jumbo
By Michael Alderete
Be runs six e-mail mailing lists. You can learn about the
nuts and bolts of what they are, how to subscribe and
unsubscribe, and other information on the Be Web site:
http://www.be.com/aboutbe/mailinglists.html
The recent publicity surrounding Be in the wake of Macworld
Expo at the beginning of the year has lead to a significant
increase in the number of people subscribed to our various
mailing lists. With this increase in subscribers, we've
started receiving a larger number of questions about the
lists that aren't necessarily covered by the Web page.
I'm the guy who gets to answer all those questions.
So I'd like to tell you a bit about the lists, some recent
history, why certain things happen, and what's going to
change in the coming month or two.
First of all, the server itself is a PowerMac 7100/80
running ListSTAR 1.1, from Star*Nine/QuarterDeck. Under
normal circumstances, this combination is more than capable
of handling the dozens to hundreds of messages that go out
to several hundred subscribers every day.
Over the holidays and through Macworld, the server developed
some disk and preferences problems and was crashing on a
very regular basis, resulting in delayed mail to list
subscribers. This was, to say the least, very irritating,
but a complete rebuild of the server three weeks ago has
greatly improved stability.
Also during Macworld, Be sent four press releases to the
BeInfo list from a machine in our booth on the show floor.
Some quirk in the show network apparently resulted in each
of the messages being sent multiple times. It wasn't the
list server's fault, it actually received the messages
multiple times and faithfully sent them on.
More recently, and probably due to the bombardment that
happened during Macworld, people have been noticing and
commenting that they receive more than one copy of the Be
Newsletter each week. These comments generally come to
Valerie Peyre, the Newsletter's editor, and it was she that
dragooned, er, suggested I write an article explaining the
phenomenon.
When a person receives multiple copies of the Be Newsletter,
it's generally for a simple reason: They're subscribed to
more than one Be mailing list, and each list was sent a copy
of the Newsletter. The person receives one copy from each
list (I receive four copies of the Newsletter each week!).
You can see that this is happening by examining the "To:"
field of each message. The four lists to which the
Newsletter is sent each week should have unique "To:" field
entries:
List Name "To:" Field
============= ======================
BeInfo beinfo@be.com
BeDevNews bedevnews@be.com
BeUserGroup beusergroup@be.com
BeResellerNews beresellernews@be.com
Of course, a reasonable person might suggest that there's no
reason to receive multiple copies of the Newsletter, even if
subscribed to multiple lists. Indeed, I agree! Later this
month I will test and implement a separate, hidden list just
for sending out the Be Newsletter.
Once this solution is working you should receive one copy of
the Be Newsletter -- no more, no less. Then hopefully people
won't feel as though Be is mail bombing them. At least, not
until this fall's Macworld Expo in Boston.
Exiting the Hardware Business
By Jean-Louis Gassée
Let me start with an apology. When we stated we'd provide
software support for BeBoxes for at leat 12 months, we got
our just desserts, a swift e-mail lashing. We saw the errors
of our ways and will provide software support for at least 3
years. I apologize for the frustration we created, and I am
grateful for the feedback and for the opportunity to quickly
correct the situation.
Now, why do we exit the hardware business? When we started
Be, multiprocessing didn't exist on desktop PCs, only on
servers. Once you've paid for the entire infrastructure of a
personal computer, we thought, the cost of one or a small
number of processors is but a modest addition to the whole
bill of materials. More important, perhaps, we thought
symmetric multiprocessing, SMP, a type of architecture where
all processors are used in the same fashion, couldn't be
felicitously retrofitted on a design. To work well, to offer
all the benefits it promised, SMP had to be designed in from
the very beginning.
So, we designed SMP hardware. With the AT&T Hobbit at first;
the PowerPC didn't exist then, and AT&T's processor was fast
and inexpensive. Fast, but not exceedingly fast. This
started us on healthy habits of getting good performance
from less than turbocompressed hardware. When the PowerPC
appeared and AT&T helped us move to our new target, we
enjoyed the sudden boost, even on the slowest member of the
PowerPC family, the 66 MHz 603.
Later, a strange idea came to us: Porting our software to
the highest-volume PowerPC design, the family of Power Macs
and clones. As a result, Be developers gained a broader
playing field, and we started a happy partnership with Power
Computing. Not only did our young OS shine on a larger
number of machines, but multiprocessor Power Macs moved out
of the system software orphanage. Previously, they were
condemned to hacked applications. Neither the OS nor
standard applications could use the extra hardware. On the
Be platform, all software automatically benefits from more
processors. A four-processor DayStar machine draws strong
reactions from the audience, achieving more impressive
performance than much costlier workstations.
We were watching two trends. First, the total value of our
software to all participants, developers, users, hardware
partners, and ourselves increases with the number of users.
Not really a surprise, but our migrating to the Power Mac
family accomplished such an increase. Second, and speaking
of the Power Mac family, there is now a healthy Mac clone
community. To wit, a MacWeek story
(http://www.macweek.com/mw_1105/nw_sales.html), in which
Pieter Hartsook, Apple vice president of marketing analysis
and research, estimated that clone vendors shipped 100,000
to 120,000 machines during the fourth quarter. We came to
feel there was little we brought to the PowerPC camp now
that MP machines were available and more accepted.
So we decided to focus on software and on doing whatever we
could to help the PowerPC build momentum. Of course, we're
aware of our minuscule size; a 55-person company in Menlo
Park can't influence the PowerPC platform as much as its
largest player, Apple. But we feel we can do the most good
by focusing our resources on adding value to the largest
possible number of PowerPC machines.
Unfortunately, it's not that simple. On the human side,
we're losing Joe Palmer, our Director of Hardware
Engineering. Joe's fine work put us in orbit. He himself
uses the booster rocket metaphor to describe the role the
BeBox played for the Be community. We'll miss Joe's
presence, his work, his endless supply of metaphors,
especially ones that require lengthy explanations for this
immigrant, his demonstrations. We get to keep the memories
and the good feeling of being in the debt of such a classy
man.
BeDevTalk Summary
BeDevTalk is an unmoderated discussion group that's a forum
for the exchange of technical information, suggestions,
questions, mythology, and suspicions. In this column, we
summarize some of the active threads, listed by their
subject lines as they appear, verbatim, in the group.
To subscribe to BeDevTalk, visit the mailing list page on
our Web site: http://www.be.com/aboutbe/mailinglists.html.
- -----WEEK 2---------------------------
Subject: GUI (in)consistency
AKA: Applications without windows
More desktop UI talk:
- Should all app menus be collected into a centralized
location so you can, for example, switch among them quickly?
What if there are tens or hundreds of apps running?
- Should the method for making a running (and possibly idle)
application be the active application be different from
launching the application in the first place?
- Certain GUI functions could be split between separate
handler and "displayer" apps. For example, a Web browser
could be divided into a net-crawling, image-caching back
end, and an HTML-displaying front end. Fronts and backs
could be mixed and matched.
- The BeOS should have "zoomable" process control. You could
zoom out to see all apps, zoom in to see just user apps,
zoom in more to see the threads of a certain team, and so
on.
The GUI discussions spilled into mutli-user land.
Specifically, the evilness of root (or "administrator") was
debated. But, some folks wondered, how do you create a
secure multi-user system without a root permission level?
Delegating permission seems to be popular: Power is
distributed among (as Loren Wilton put it)...
"...a pantheon of small local gods... [who] don't have the
power on their own or communitively to erase the trails of
their actions."
- -----WEEK 2---------------------------
Subject: Tracker suggestion
AKA: A Better name for Tracker?
Practical Tracker suggestions have pretty much bottomed out.
The name mail continues.
- -----NEW---------------------------
Subject: Be's hardware plans
AKA: Very, very, very Bad Be...
AKA: No more BeBox HW - whence MIDI?
AKA: Good Audio
[and others]
The hot topic of the week was the announcement that Be is
getting out of the hardware business. A number of developers
were understandably agitated by this move; some
characterized it as a betrayal. Others mourned the passing
of the BeBox but saw it as an economic inevitability. And
there was even some scattered applause to commend the
decision.
Some specific (and relatively unemotional) topics:
- Hardware Abstraction Layer (HAL)
Be's platform support will naturally need to be more
generic. Will this make Be see that hard-wiring parts of the
kernel to support specific platforms is a bad idea? Dominic
Giampaolo briefly described Be's plan to move platform-
specific components (file systems and CPUs in particular)
out of the kernel -- it's not a full-fledged HAL (yet), but
it's headed in the right direction.
- MIDI
Are built-in MIDI ports necessary? It was pointed out that
(A) the Mac is the platform of choice for MIDI applications,
and it doesn't have built-in ports, (B) a professional
studio setup needs more than two ports anyway, and (C) PIOS
will offer plenty of "music-friendly" IO hardware.
- "CD-Quality" Audio
The loss of quality audio hardware was lamented. This was
countered by the claim that Macintosh audio hardware is
pretty much the same as what you get with a BeBox; none of
it lives up to professional studio standards, but it's more
than good enough for general-purpose use.
- -----NEW---------------------------
Subject: let's talk about cursors
Performing context-sensitive cursor switching is difficult
because there's no "the mouse has left the building"
message. It was proposed that Be provide a MouseExited()
call back (plus a GetCursor() so the old cursor image can be
remembered and restored when the mouse exits). Two primary
objections:
Objection #1: Every Exit is complemented by an Enter in some
other window (the Tracker if you exit to the desktop) -- why
not just let the Enter do the work? This means that every
window or view should set the cursor to the image that it
needs; if there's no handler in a view, the default image is
used.
Objection #2: There's no way to guarantee that the
MouseExit() will run before the concomittant MouseEntered()
so the user may end up with the wrong cursor.
Another proposal: Provide cursor regsitration and let the
Application Server change the cursor as the mouse moves
around.
Objection: You can't (easily) perform cursor image
processing or other dynamic cursor updating.
- -----NEW---------------------------
Subject: BitMap storage format: PNG?
There is no "official" Be bitmap data format; Jon Ragnarsson
wrote in to propose that PNG (Portable Network Graphics) be
sanctioned as such. This was met with general acceptance,
although there were some questions about the speed of
compression and decompression.
For more on PNG, see http://www.wco.com/~png or
http://www.boutell.com/boutell/png/png.html.
The status quo Be screen dump format and the DATA_BITMAP
datatype were also proposed as possible standards.
More philosophically the question was raised, "what's a
standard for?" It was suggested that a standard is
meaningful only when data crosses application boundaries;
within an app, you can do whatever you want.
|
