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...."

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.

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(constint 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?"

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.