Issue 81, July 9, 1997
Table of Contents
BE EVENTS: Be Developers Conference in Boston, Massachusetts
MACWORLD Expo in Boston, Massachusetts
- Monday and Tuesday, August 4-5, 1997
Be Developers Conference
Hynes Convention Center
The Be Developer Conference is the ideal forum to get up
to speed on development for the Be Operating System, to
find out the latest on Be technologies, and to meet and
discuss technology and products with other Be developers
The conference is open to all software developers; this
includes people who are Registered Be Developers and those
who aren't yet. An understanding of C++ is highly
recommended; the conference will get quite technical at
For more information, please see:
To register, please complete the registration form at:
- August 6-8, 1997
World Trade Center
Be Booth # 5119
BE ENGINEERING INSIGHTS: Onward and Upward with DR9
By Erich Ringewald
Well, it's been eleven long months in the making, but the
Preview Release has finally been set free from the
developmental cocoon. What started out as a simple release
whose only major goal was to replace the portions of our
system responsible for data storage turned into the most
major release we've ever done. And only five months late.
I know it's only software, and software is always late, but
at Be we've always been pretty timely with our software
releases. And that's been something to be proud of when you
consider the amount of Apple OS team engineering blood,
admittedly diluted with infusions of SGI and NeXT plasma,
coursing through our veins.
But the uncertainty of a brand new file system, complete
with all the modern features, and the even-better
integration of our famous database technology left us five
months late on what was to be about a five month development
cycle. Being off by 100% is impressive, but if I have to do
it I'd rather it be on a five month project than a four year
But enough talk about Apple.
What's next, after the Preview Release? This is the
traditional time to fix up some of those nasty little bugs
which were elusive enough to escape detection prior to CD
duplication. Why they show up as the FedEx truck is driving
away I don't know, but there it is.
But it's DR10 that is really the focus of our attention
these days. What should we implement, what should we skip?
What will be the most important things we can do to improve
the availability, stability, and usability of the
applications our developers are writing? More kits? More
classes? Fewer kits? More supported platforms? A PowerBook
portable, or an Intel desktop port? Both? Neither?
Believe me, the real list here at Be is quite daunting. The
pressure for the next release is now on, and we confront
that list daily, brows furrowed in deep contemplation. But
with continued guidance from our keen developers' insights,
I'm sure that DR10 will be right on target. Let's hope it's
also right on time.
It's the Customer, Stupid!
By Bradley Taylor
Or, in other words, it's NOT the technology.
To prove my point, all I need to do is point to DOS, circa
1982, which many people, myself included, sneered at as
being technically uninteresting compared to the alternatives
at the time such as Unix. I remember the general wisdom then
was that the superior Unix would eventually replace DOS.
Even Microsoft seemed to believe this, and for a time,
developed its Unix successor to DOS called Xenix (later
Well, here we are today and Unix (with the exception of
Linux) is gasping for breath as it is beaten down by the
likes of Windows NT, DOS's grandchild. Yes, Virginia, there
is still a DOS prompt in Windows NT and it still has all the
same primitive commands it did in 1982. Oops, I caught
myself sneering again!
So, something was terribly wrong with the analysis that many
engineers made of DOS in 1982. What was it? Some will say
that the engineers didn't consider the importance of the
computer having the letters "IBM" on it. I think there is
some truth to that, but it doesn't explain the whole story.
Because soon thereafter, IBM lost its monopoly, yet
consumers continued to buy DOS, and continue to buy Windows
My opinion (and I fully expect to be flamed for saying this)
is that consumers care little for technical wizardry, and
care deeply about things like price and simplicity. And
compared to DOS, Unix was (and still is) an expensive and
The one exception, Linux, thrives only because it is free.
The Macintosh, though more expensive, was indeed simpler
than a PC, and had a few years of bounty because of it. But
had the Mac been the same price as a PC, it would be faring
much better today. Apparently, the only technical wizardry
consumers cared for at the time was the ability to launch a
single application, and they really didn't feel like
shelling out a lot of money for any other features, however
appealing those features may be to engineers.
Today, consumers are a bit more savvy, and want more out of
an operating system than just a glorified program loader.
Multitasking, GUIs and Internet capabilities are all
expected now. But these features are not just checkbox
items; people are really going to use them! So, they need to
be there without sacrificing simplicity. Windows, Mac OS
and, I have to admit, BeOS are all too complicated in this
area. However, I think of the three, BeOS comes closest to
meeting the goal, because unlike the others, it was designed
to do all of them from the very start.
One of the examples of this is our file typing scheme in the
BeOS, which is based on MIME types, the Internet standard.
We don't have to convert downloaded files into some outdated
proprietary file typing format as Mac OS and Windows do.
Because of this, Internet applications such as web serving,
web browsing and e-mail are simpler for the user to operate
under the BeOS. With just a little more work on our part,
like making network setup easier (PPP and LAN), we can make
the BeOS the simplest OS by far.
That brings me to price. PowerPC machines are still more
expensive than equivalently configured PCs, but clone makers
like Power Computing have been doing a great job of
narrowing the difference. CHRP machines should erode the gap
even further. And a BeOS port to Intel would help to erase
the difference entirely. This is NOT an official product
announcement, just something to keep in mind, remembering
that the BeOS is a very portable operating system. But
things are looking promising for PowerPC prices coming down
Left out of this discussion has been applications. BeOS
could use a few, I'll admit. But remember that DOS didn't
have any applications when it started out either, but
because of its price and simplicity (compared to the
alternatives at the time, such as CP/M and Unix), it
attracted many. The point is simply that perhaps if an
operating system does what the consumer wants, and offers it
with simplicity and a low price, the applications will
follow. There are things Be or others can do to grease the
wheels, like provide a Mac or Windows emulator. But it may
not be necessary. After all, DOS couldn't run CP/M programs,
nor could the Mac run DOS programs.
My main goal in this article is simply to motivate you to
write applications for BeOS by seeing the market potential
for it, which could be huge. I'm not claiming that the BeOS
will overtake Windows anytime soon, but it is quite possible
that it will carve out a nice niche for itself as a simple
and inexpensive application platform. An application running
on the BeOS, such as a web server, may be simpler and lower
cost, in total, than the same application running on another
platform. This is a great benefit to the consumer.
A secondary goal of this article is to deflect some
criticism we get from engineers because we are missing
certain features that they feel are important. If we put in
every feature in that engineers want, we would end up with
an operating system like Solaris: complicated and expensive.
There is a lot of value in keeping things simple. I'm not
saying we don't welcome criticism; we certainly do. What I
am saying is that we, developers and Be alike, will all
benefit by keeping the BeOS simple and inexpensive, and
criticism must be weighed against these two all-important
We are about to release the "BeOS Preview Release." This is
the first release which promises binary compatibility. That
means the API and ABI we will be shipping will remain in the
BeOS for many releases to come, allowing applications
written for the BeOS Preview Release to run in future
releases. We will add more API in the future, but the
current API will not change. I think our API is very nice,
but there will always be engineers who may sneer at our
current API (or almost any API, for that matter). Sneer they
may at their own risk. Remember, DOS's much sneered-at API
(API, what API?) was not a serious impediment to its
For the sake of provoking thought, I have simplified things
in this article a bit. Yes, things are actually more
complicated than I describe. But we should never forget the
customer's desires, however basic they may seem to us. I am
reminded of a poster my boss has in his office. On the
poster, you see a somewhat tall and fit man, with his arm
around a stouter, cigar-smoking man. The tall man states
something like this, "This is a customer. He has money to
spend. I like him."
News from the Front
By William Adams
BEntry is a wonderful thing. It gives you a C++
representation of an
BPath is also a wonderful
BPath will easily represent your
BEntry and allow
you to perform some very useful operations. In this
particular case, we can use the
BPath object to get the
parent of the application file. In this case the parent is
the directory in which the application is actually living,
HomeDirectory. Passing in a
BPath object is
better than a char * with a length simply because memory
allocation is taken care of for you with less potential for
mistake. Among the other interesting things you can do with
Flattening allows you to
store a path in a archive.
Append() allows you to add onto a
path. This is often the case when you're looking for files
that are located relative to your launch directory.
Now you can use the path to create a
BDirectory object to
find files, or whatnot.
Another question that seems to be coming up a lot is, "How
can I set type and creator for my files?" Well, in the new
MIME world, you don't use type/creator like in DR8. Instead
you will set a MIME type on a file.
BNodeInfo object is your connection to getting and
setting various pieces of meta data on a node.
nodes, and so are BDirectories. Among the interesting things
you can get/set on a
BNode are the MIME type, its icon, and
the preferred application. This is particularly handy if
your application is one that generates files and you want
your application to be the one that launches those freshly
created files. So,
BNodeInfo is the place to go for all your
meta data needs.
There you have it. The new file system is not only 64-bit
clean, snappy, and robust, but it's darned useful to boot
and pretty darned easy to harness those added features. The
attributes are there, and largely hidden. This
class makes some of the more commonly used attributes more
readily available to your application.
A couple of weeks ago my BeBox had what I thought was a sure
melt down. I did figure out that the disk drive was touching
the power regulator on the motherboard. This is about the
hottest piece of metal you can touch on your motherboard.
The disk drive actually came out OK. The outer plastic
casing was fried, but not to the point of causing any real
damage. I turned it on, and I've been happily using it ever
since. Although now it make some strange rattling sounds, so
I think it's time to retire it anyway.
The 4th of July has come and gone. On that day, I stood at
attention in front of the American flag and smartly saluted
in recognition of the freedoms that I enjoy...to program
the BeOS in the face of tyranny of the desktop and against
all odds of the oppressors. I didn't actually stand in front
of the flag, but I did think about it.
The Rebirth of the Set-Top Box
By Jean-Louis Gassée
About 1992, every hardware company was either doing a
set-top box, or claiming to be designing one. Apparently,
these efforts didn't go anywhere. With hindsight, the reason
is obvious: Too much computing power for too little money.
The tasks expected from a new generation "digital" box
required more computing power than a mid-range PC could
offer at the time: Decompressing video, creating some kind
of user-interface for navigating the service, security
services and, in extreme cases, a loop back to the server
for "interactive" applications. Even with some absorption of
the cost by one or more participants in the food chain, the
financial burden was too much.
I used the word "apparently" above. In one of the reassuring
mysteries of our industry, one of these episodes that remind
us of the difference between PowerPoint and reality, that
set-top box false start gave us Java, nee Oak, a programming
language originally designed for safely distributing small
executables over cable and satellite networks.
Now, with the impending but still undefined arrival of
digital TV, the set-top box is coming back. Even with three
or four cycles of Moore's Law, broadcasters and cable
operators are still complaining about the cost of the
device. One friend of mine argues this is the reason why
Microsoft is making investments in cable (COMSAT) and is
rumored to be eyeing, forgive the pun, CBS. In other words,
if links in the food chain are too tentative, Microsoft will
buy them and make sure the whole chain is completed,
ensuring the availability of an infrastructure "sorely"
missing today. Such an infrastructure is needed to develop
really juicy commerce and entertainment applications.
I don't know, yet, whether my friend is fantasizing or
merely prophesizing, but it's an interesting speculation.
Bill Gates' impatience with the clumsy, slow development of
a better infrastructure is no speculation; it is part of the
public record. If Microsoft used its considerable resources,
financial and otherwise, to such an end, I believe the
benefits to all of us would outweigh the danger of Microsoft
dominating yet another industry. Please don't call me a
Microsoft apologist, I'd just like to see new markets we've
been hoping for finally arrive.
Now, it's not that easy. Microsoft's fiat, powerful as it
is, isn't a guarantee of success. Many successful companies,
from IBM to Sony, from Matsushita to AT&T, from Xerox to
Digital Equipment, have seen their famed expertise vanish as
they ventured into unfamiliar territories. Microsoft has
shown a remarkable ability to change its mind and refocus
itself, ask Netscape and CompuServe. But their ventures into
the content space with MSN and MSNBC are, at this time, less
than convincing. Interesting times ahead, as always.
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.
Subject: [Hey Be!] B_SAFE_WRITE please?
What's the best way to do a "safe save" (in which you're
guaranteed to have a copy of a given file at all times, even
if the machine crashes while you're writing the file)?
Suggestions were offered, as were objections to the
particulars, such as where you should safe-save a file, when
you should sync, and so on.
Some folks would like to safe-save as part of the file
system itself. It would be appreciated if the file system
BFile) were to ensure that certain files always existed
-- perhaps by writing new data to a temp file and then
moving the file to the "real" location. Others think that
deciding when, where, and how to save can *only* be decided
by an application. The file system could guess, but at the
cost of either performance or integrity.
Speaking of synching -- the Storage Kit doesn't provide a
Sync() function, nor can you convert a Kit object (
BNode) into a file descriptor that you can pass to
This lack was lamented.
Should panels (open file, save file, print, etc.) ever be
It was argued that in a multi-threaded OS, modality isn't
necessary, and can be obnoxious.
Subject: C++ question and handling errors
Is it possible to delete "
this" inside a constructor? Most
folks agree: Don't delete "
this"; instead, either set a
status variable (that must then be checked by the caller),
or throw an exception.
More elegantly, if your object needs to be initialized to be
used, and if the init can fail, put the init code in some
other function. In other words, you should never write a
constructor that can fail.
Subject: Persistent driver data
Should a device driver be allowed to launch an application
(to ask the user for settings, etc.). The BeOS says no. Some
folks think this is too restrictive -- they feel that a
driver should be allowed to initialize itself; relying on a
server is clunky and possibly unsafe (since there's no
guarantee that the server will load before the driver.)
Subject: Dumb sound question
Is it possible to (easily) play a sound from a buffer rather
than from a file? Not as easily as
creating an audio subscriber and implementing its stream
function is fairly easy, as a few folks pointed out. Still,
it would be appreciated if the Media Kit were to accept
pointers to sound data (and a pointer to a header), and
simply do the right thing.
Also, what's the best way to mix your data into the sound
output stream? Simple addition could cause overflow. But how
often will peaks collide? Some folks think that if you mix
disparate signals (from different apps, for example) the
natural disparity will average to in-range values. So you
may not need to "divide by the number of subscribers".
However, you *do* have to clip overflow (to the max/min
value) -- overflow otherwise wraps around, causing painful
and embarrassing digital distortion.