|
Be Newsletter
Issue 70, April 23, 1997
Table of Contents
BE EVENTS: Berkeley MacFest and Be Developer Conference
- APRIL 26: BE AT MACFEST IN BERKELEY
BeOS demo and Jean-Louis Gassée keynote at MacFest 97,
organized by the Berkeley Macintosh Users Group in Berkeley,
CA.
For more information about the Be Demo Tour, please visit:
http://www.be.com/events/schedule/index.html.
- MAY 10 AND 11: BE DEVELOPER CONFERENCE
If you're a developer for the Mac, UNIX, Amiga, Windows,
BeOS, or any other platform and want to know more about the
BeOS, please come meet with us at our Be Developer
Conference on May 10 and 11 in Santa Clara/San Jose, CA. For
more information and to register, please visit our Web site:
http://www.be.com/developers/may_dev_conf/index.html.
BE ENGINEERING INSIGHTS: The Long and Short of It
By Ming Low
This past Sunday, I slept through most of a double-header
between the San Francisco Giants and the New York Mets.
Between games I became sidetracked and started looking at
the layout for the DR9 developer CD.
As I went through the file list, I was struck by how much
new engineering went into DR9. A brief summary goes
something like this: A newly written file system and
queries, new font engine and support for Unicode, new
scripting capabilities, drag-and-drop, a new MIDI
synthesizer, ATAPI CD support, new networking and graphics
driver models, expanded printing and AppleTalk support, the
new Tracker and a new UI, better POSIX compliance, Mac
floppy and 32-bit support, support for a slew of new Mac
models, and massive API changes.
By my own absolutely unscientific and rough mathematical
calculations, an equivalent of 20 engineering years went
into making DR9 where what it is today. But to put it in
perspective, that's roughly 25 engineers working lots of
late nights and weekends for about 7 months. In another
perspective, every file with code on the CD was changed. I
don't envy the task of our writers to document all the
changes.
One of the API changes we're making for DR9 is to do away
with most of the long data types in the BeOS. At one time,
using a long to represent an integer may have been a good
idea, but new we realize this was probably not the most
prudent decision. (I'm sure there's no truth to it, but I
was once told that the idea of using longs was insisted on
by a short guy with rat-pink eyes who's since been fired.)
Instead of longs in DR9, you'll see int32, int16, or int8
spring up to replace it -- depending on the signed data
size. We also used this same bit-size naming scheme to redo
the unsigned and volatile data types. An unsigned 32-bit
integer is uint32; volatile signed is vint32; volatile
unsigned is vuint32; and so on for 16 and 8-bit types. Data
types such as char* are left alone, because there's no gain
in making them int8.
As discussed in previous newsletters, DR9 will approximate
POSIX compliance. POSIX provides separate types for
measuring data, depending on whether it's memory or file
bound. Memory-bound data is given as size_t, and file-bound
data is given as off_t. The most important aspect of these
types is that they set the maximum value that can be used as
an address; which amounts to setting a limit on memory and
file sizes. DR9 is a 64 bit file system, so off_t represents
64-bit integers. RAM today can't accommodate such massive
areas, so size_t is a 32-bit integer.
There are some cosmetic typedefs changes in DR9. These are
types that are not strictly necessary, but our documentation
folks insisted on these changes to make the API much easier
to read. The most notable of these is the status_t type,
which is used to mark functions that return constants.
Another DR9 type change is the way time is represented in
the system. Currently, time is measured in microseconds,
expressed as a double-precision, floating-point integer. As
someone pointed out, this is like giving a dog a bath in the
squirrel house. Huh? So for DR9, time will change to a more
reasonable and efficient 64-bit integer (the time quanta is
still microseconds). A few other time changes were done, but
the most important is that system_time() in DR9 will be
measured from January 1, 1970 (the UNIX epoch).
Before I go, I'll leave you with a quote from our editor
that's stuck in my mind every time I check my watch, "You
see it's like this the big hand is playing poker and the
little hand is motioning for another drink...."
BE ENGINEERING INSIGHTS: DR9 Uber Alles
By Melissa Rogers
The question I am most often asked is, "When's DR9 going to
ship?" (DR9 is one of our internal names for the forthcoming
Preview Release of the BeOS.) They hired me just so I could
answer that question with a straight face. Just between us,
DR9 is the release from Hell. What started out as a nice,
tidy, incremental release has turned into everything,
including Doug Fulton's kitchen sink. Which, when I think
about it, I kinda like.
By now I think you all have an idea of what's in DR9. I like
to think of DR9 in terms of what hasn't changed. There are
approximately 7894 source files for the release version of
the BeOS. Of those, 1900 files haven't changed, and that's
only because it's the GNU source. Bottom line: Everything
has changed for DR9.
Why would anybody like me let engineers go wild and do this,
change everything? Don't they pay me to keep a rein on the
engineers? Isn't it my job to "manage" the project? Frankly,
we needed to do this and, despite my misgivings, it's
turning out pretty well.
We needed a new file system. Dominic and Cyril have
succeeded beyond my wildest hopes. To use our new file
system is to love our new file system. "One CD does it all,"
that's Bob Herold's motto. Whether you have a Power Mac or a
BeBox our single DR9 CD will install on it. Our debug server
was very painful to use at times, Mani has made it
infinitely better and has fixed exceptions and some of the
standard libraries. Robert Polic has added a stunning new
app, currently called DriveSetup. I swear you can mount
anything with this app, including DR5. You wanted ATAPI
support and you got it, Guillaume Desmarets is giving it to
you. My personal feature vote was for "fork." I got it
thanks to Michael Burg. (Next stop system builds on the
BeOS.)
PPP did you say? We now have loadable drivers and AppleTalk
(PAP) printing, too, all courtesy Brad Taylor. Rico Tudor
couldn't help himself, he had to add pty as well as working
serial drivers for the Mac.
We needed a new Tracker and UI. Steve and Hiroshi are
kicking some serious butt with help from their friends. I
think you're going to like this new look. I do and as
everyone can tell you, I'm the biggest critic here at Be.
Bless Doug Fulton's and Don Larkin's pointy little hearts
our API's have been cleaned and shined. Peter Potrebic has
added scripting and MIME support everywhere, hooray! A
number of helpful apps have been added by Pavel Cisler.
We've decided to give Roy, our User's Guide writer, the
biggest challenge of them all: shrink the installation notes
down to 3.5 inches by 3.5 inches and still make them
readable.
Our previous font renderer sucked. Our new one is very nice.
Pierre has done an amazing job of adding anti-aliasing
support, Unicode support, and other nifty not-so-little
things into DR9. Of course now that we have the appropriate
font support, printing comes along. Benoît Schillings and a
developer friend of ours, Mark Verstaen, have printing to
PostScript printers working. Scott Bronson cleaned up the
graphic driver API and added more support in the Game Kit.
My guess is that the game writers out there will love this.
The Midi and Media kits have been cleaned up also. Marc
Ferguson has been listening to your requests. Secretly off
in a little closet back east, George Hoffman has been
working on a 3D driver. With any luck we'll see that for
DR9, too.
With changes like these I couldn't rely on the engineers
doing all their own testing as we have in the past, so we
added four QA kings: Baron Arnold, King of All You See;
Robert Chinn, King of the Underpinnings and API: John
Standerfer, King of Graphics and File System Destruction;
and William Bull, King of the Application Server (no small
task there).
The question you may ask is, who really manages all the
source files, builds, external releases? Certainly not the
lowly project manager. No, the man who makes it all happen,
the one that the Be world revolves around, is Ming Low. You
can thank Ming each and every time you get a release.
So when's DR9 supposed to arrive? Soon, real soon now.
News from the Front
By William Adams
Are you practicing safe hex? C++ is at times a tricky little
beast, which requires much pampering to coax out its speed
and flexibility. There are some basic assumptions and
practices that are much safer than others. When you go and
port code from one release to another, you inevitably begin
to question why you did just the way you did it. An example:
class Base
{
public:
Base();
Base(char *aPtr, uint32 size);
~Base();
char *fPtr;
uint32 fSize;
};
class Derived : public Base
{
Derived(char *);
~Derived();
}
Two simple classes, one derived from the other, classic
style. A subtle problem.
First off, both of the destructors won't be called, since
the destructor of the Base class isn't virtual! So if you
implement a destructor, make sure that your base class
declares the destructor as virtual. Not a big deal, but
something that causes pain if you're not careful. In DR8 the
BObject class declared a virtual destructor, so you probably
didn't put anything into your own code to ensure that it was
virtual. In DR9 the BObject class goes away, so there you
are. Subtle, but possibly painful.
One of the other processes associated with porting is that
you have to unlearn a lot of what you took for granted in
the past. In DR9, you're now responsible for deleting your
BMessage objects whenever you do a PostMessage(). This will
not show up as a compiler error, but your app will leak
memory all over the place if you're not careful.
And another thing. A lot of the interfaces in DR9 have
gained a const for the parameters and on the class methods
as well. So you'll see things like:
class AClass
{
public:
uint32 foo(const int a);
status_t GetFoo(int *a) const;
}
In the first case, the class designer is telling you that
they won't change the value of the parameter, so it's safe,
and probably optimal to do something like:
AClass fooInst;
fooInst.foo(5);
Whereas without the const, the compiler would probably
create a temporary variable in which to store the value.
This is another copy, and slows down code a teeny bit. Of
course if it were a large object, creating a copy could slow
down code quite a bit.
Naming a method const, as in the case of GetFoo(), is the
class creator telling you that calling this method won't
change the state of the object. Some of these things make
your code safer, some of them just make your code more
tedious. If you pay attention to the compiler warnings that
are inevitably generated, you'll no doubt eliminate a number
of bugs right off the bat without further pain.
In porting to DR9 I've found that the changes in semantics
of where you should allocate an object on the heap versus
the stack can be troublesome. But once you're doing the
right thing, you'll live in a much safer world. Tighter
control of memory, explicit control of your instance
variables and methods, these all lead to safer hex, tighter
apps, and a more sane world.
What do you get when you stay up till all hours in the night
porting code to DR9? Safer apps and daughters who wake up
from naps asking, "Is daddy at the computer?"
The Future of the Home PC
By Jean-Louis Gassée
As hard to imagine as it might seem, given the incredible
success of PCs, there was a time when people scoffed at the
notion of a personal computer in people's homes. Ken Olsen,
DEC's founder, is often quoted dismissing PCs as a stupid
idea. This is no legend. I sat next to him at a dinner
preceding the announcement of the soon to be famously
infertile Apple-Digital alliance. In our conversation, he
professed bewildered acceptance of people's interest in
personal computers. A "glass teletype" with an Ethernet
connection and All-In-One software covered all his needs
with an easy-to-use, two-character command set.
I'm not recounting this by way of dissing one of our elders.
I like and respect this founding father of our industry.
Having worked for a while in the minicomputer industry (not
at DEC but at one of its siblings), I personally benefited
from his pioneering work. But when it came to PCs, he had no
insight into what moved customers. A sobering thought for
all of us with any amount of experience in our business.
When, where are we making similar mistakes? Let's continue.
With hardware and software improvements, the early home PC
moved from a hobbyist and a game machine to a home
workhorse. Today, the home PC is often more powerful, more
media-rich than the corporate office productivity machine.
On the way, we invented nice genres, such as Quicken, and
not-so-nice words, such as "edutainment." And then there was
the Web. We can describe it in terms of IP packets. This is
about as useful as describing a human being in terms of the
atoms that make up a body. We're still trying to understand
the life form that will emerge from this IP soup.
Over the years, the PC industry kept looking with envy at
the consumer electronics business. A strange desire. It
can't be margin envy. VCRs generate a lot less profit than
the humblest of no-name PCs. I know, some PC companies
occasionally lose money, but so did RCA, and on a much
grander scale, only to be acquired by a French conglomerate.
So it's not margin envy. Can it be volume envy? Not any
more. Last year, Americans bought more PCs than TVs. Then
what is it? My own guess is the PC industry looks down at
consumer electronics devices as dumb objects.
Alleging a parallel between the smarts of the products and
the wits of their makers, the PC guys are the victims of an
aberrant superiority complex. We should own these markets
because our selves and our products are so much smarter. PCs
are so much better at manipulating and representing digital
data, any kind of data. In fact, any consumer electronics
device can be reduced to data format and rendering. That's a
job for computers, and software gives them infinite, protean
flexibility. So far, mundane reality has belied the beloved
abstraction. A $149 VCR bought at Costco plays tapes very
nicely, it boots real fast, and as long as I don't try
anything fancy like programming, offers a real nice UI:
Play, Pause, Stop, Rewind.
Is this state of affairs eternal, or is the combined rush of
new digital media and more affordable computer power about
to make living room entertainment the next big new market
for PCs? At least one idea says it will, and another says it
won't. But first, by living room we mean TV and we're once
again toying with the merger of the PC and the TV predicted
long ago by Nicholas Negroponte, the founder of the MIT
Media Lab. Against the PC/TV idea is the fundament-al
difference in physiological and psychological use of our
seat. As couch potatoes, we're passive passengers -- the
screen is ten feet away. As PC users, we're pilots, sitting
forward, creating and navigating -- the screen is three feet
away. The pro side says this is an aging distinction. DVD-
ROM drives will let us watch Das Boot on our PC monitor. The
Gateway PC/TV and, of course, WebTV are blazing the new
trail. Never mind their currently modest sales, the Mac
started slowly, too. There are other interesting pro
arguments. The user interface, for instance. Both Netscape
and Microsoft, in their fight for primacy in the Web, are
experimenting with less PC-like screens and more TV-like
UIs. And yes, there's the perennial problem of programming,
controlling all these consumer electronics devices. For
these, a point-and-click UI can spell relief from setting
PIP tuners or recording tomorrow's game. There is even the
nirvana of the FireWired house, with the DVD jukebox in one
room and the speakers or the TV in another. Dreams indeed,
but perhaps not as outlandish as they once were, and more
fun than yet another version of office productivity
bloatware.
|
