BeOS releases for PowerPC processors have been shipping for around two years, right? So why on earth is it taking so long to get an x86 release out? Just recompile it and ship it—come on!

It's amusing to examine the factors involved in porting a shippable product to a new processor architecture. The x86 project was actually started in mid-1996, when Dominic Giampaolo created a working kernel bootstrap. Much of the dirty work remained to be done (page table management, program loading, etc.) but we did have some Be code running on an x86 processor.

At the time, however, Be was playing "Lets Make A Deal" with Apple, and a compelling PowerPC release was pretty important. The PowerPC version of Developer Release 8 loomed large, and all engineers were caught up in the maelstrom of getting that release out the door. Dominic switched over to creating the new file system that shipped in the Preview Release—a more than full time job for the next several months. Thus, the first attempt at the x86 port died on the vine.

In January 1997, a new effort at an x86 port began. Two engineers from outside the company holed up in a cube, took a snapshot of what was then a rapidly changing source code base for the Preview Release, and set off on an excellent porting adventure. Aided by Cyril Meurillon and Mani Varadarajan, they had a working kernel in a couple of months. Soon they were loading and running command line programs using the shell over a serial port.

Having outside engineers do the work proved beneficial in many ways. They had expertise in x86 processor architecture that Be engineers did not, and they were focused exclusively on the port, while the rest of Be was working on the massive changes for the Preview Release.

Taking a source snapshot and hacking away is great for getting something running quickly. Rather than being subject to the vagaries of the daily build, the porting engineers worked with a known quantity. All problems were theirs, not something introduced by a midnight check-in gone awry. Once they had something running, though, their sources were several months out of date.

Several competing forces come to bear on what happened next. As the Preview Release neared its final testing phase, merging all the x86 changes was deemed too risky to that schedule. But since Be was embarking on a major fund raising effort, having a demo of the x86 release was a necessity. The old source snapshot, while stable, did not have the pizazz of the Preview Release. We decided to take another, current snapshot, merge the x86 changes, and get the road show demo ready as soon as possible. Cyril, Mani and Pierre Raynaud-Richard took over the merge effort and soon had a relatively stable version up and running. This version was shown to investors, and to the general public at Boston Macworld in August 1997.

Finally, after the Preview Release 2 source tree was frozen, the x86 changes were merged into the main source tree for all Be engineers to share. This was a tricky process, because kit, graphics, and application engineers were developing primarily for the stable PowerPC version. They needed a reliable build every day. However, the x86 changes to the kernel and elsewhere were many and varied, and typically needed to be done all at once to work correctly. It often seemed as if we were trying to change engines on a moving train.

The August demo version was very compelling, but a few critical features were missing. There was no support for shared libraries, so all applications were statically linked. In this form the average application was huge—the /boot/beos directory alone was over 300 megabytes of object code, without fonts or other such fluff. The disk had to have a Linux partition on it, as we used the Linux bootstrap loader "lilo" to start the BeOS.

We spent the next few months working on our dynamic loader, and working with Metrowerks to resolve compiler and linker issues. The peculiarities of the import/export mechanism for the PE-COFF object file format necessitated more massive changes to our header files. All this was done under the dual constraints of keeping the PowerPC version building and stable on a daily basis, and also keeping the PowerPC version binary compatible with the shipping Preview Release versions.

Stability, booting issues, and expanded hardware support have also been at the fore this fall. Two recent additions to the kernel team, Arve Hjønnevåg and Dmitriy Budko, contributed significantly. Arve joined Be one week before Cyril took a well-deserved vacation, and dove right into the labyrinth of endianness problems, compiler bugs, and hardware incompatibilities. We scarcely noticed Cyril was gone! Dmitriy brought an extensive knowledge of the various chipsets, standards, and undocumented quirks in the x86 world from his previous job at Intel. Much of the improved hardware support, as well as selective use of chipset-specific features is a direct result of his efforts.

We continue to work on the final features for the upcoming x86 release. Every Be engineer now has a PowerPC machine and an x86 machine side by side on their desk. The nightly automated build is done for both platforms. When you look at a monitor, it is almost impossible to tell which version is running.

If we had dropped everything a year and a half ago and focused exclusively on the x86 version, it would have shipped long ago. The pressures of continuing to ship PowerPC versions, coupled with the need for compelling products to demonstrate to potential partners and investors, have pushed back the release date. Now we are getting close, and we hope you'll find our efforts worth the wait.

(By the way, this was written using StyledEdit on x86, and sent using BeMail and the net_server to our Newsletter editor.)

In perusing the Newsletter archives, I've noticed that not a whole lot has been said about (or done with) printing on the BeOS. Fortunately, I will be rectifying this in the coming months by designing a "new and improved" BeOS printing architecture. (After all, it's what I was hired to do... };-> ) So, to start the ball rolling, I'd like to talk a little about my ideas for the future of printing on the BeOS.

First, however, my general purpose disclaimer and engineering excuse #4: What I will be discussing are my ideas about printing. They are not commitments for new printing features, enhancements, or bug-fixes. It is simply too early in the design process to talk about specific feature commitments and (gasp!) schedules and such. So much for CYA-speak. Now what about printing?

The first thing everybody should be aware of is that a lot of things will change. The printing API and BPicture will be modified, as will the way printers are added and chosen. Of course, some things won't change. For example, there will still be a Print Server and add-on printer drivers. The print job will still take the form of a spool file.

As for new features, it is easier to simply list them for now. Here are a few I've come up with so far:

• ICC profile-based color matching

• Encapsulated graphics support

• Direct-to-printer job streaming

• Print-time application interface from add-ons

• Internet Printing Protocol (IPP) support

• Integrated PPD and PPD-like printer description support

• Attributed spool files, print queues, and printer scripting

• Random page-access spool file

As noted above, one of the fundamental changes affecting the BeOS printing architecture deals with BPicture. Basically, BPicture will incorporate a function callback table whose elements map to all the existing (and new) primitive drawing instructions on playback. This allows the picture format to be abstracted, so that it can be modified as needed by Be without unduly affecting applications. (In short, don't mess with picture internals, or else.) Printer add-ons, for example, will be able to take advantage of this design by installing bottleneck functions for any desired graphic primitive that they wish to translate, modify, or image themselves when a page of the print job is played back.

Another issue (a pet peeve, really) I'd like to touch on deals with encapsulated graphics support. I've talked to a couple of application developers and invariably they ask (aside from "When can I expect printing to work?") about PostScript support a la Macintosh picture comments. Admittedly, there is a certain perverse appeal to being able to inject PostScript into the job stream to tweak things to one's satisfaction. Be that as it may, however, to these people I amicably say, "Read my lips: No, no, and no!"

My experience with helping develop the LaserWriter 8 printer driver for the Mac OS leads me to believe that application developers invariably make hacks that end up decoupling the graphics state a driver generates from the actual graphics state in the printer when the job is executed. The result is typically catastrophic, and almost always the printer driver is blamed for it. Given that similar problems exist in the PCL world, the best solution I can think of is to allow only encapsulated PDL graphics to be included in a picture.

What are encapsulated PDL graphics? For PostScript printer add-ons, it would be Encapsulated PostScript Files (EPSF). For PCL printer add-ons, it might be HP-GL/2 files. (In the event that the BeOS images the job, encapsulated graphics wouldn't be supported, as the application should convert the graphics to BBitmap objects and image them with DrawBitmap().) Regardless, the application is responsible for loading the encapsulated graphics; calling the appropriate printer info APIs to make sure it is the right kind of graphic for the targeted printer/printer driver; and calling the appropriate encapsulation API which, when picked-up by the add-on via the callback table, will allow the add-on to bracket the encapsulated graphics with graphic state saves and restores. This should prevent the application from inadvertently blowing away the add-on's graphic state.

Finally, I would like to again point out that these disjointed musings are simply my ideas on future BeOS printing. Some of them will likely end up as part of the BeOS. Others will undoubtedly end up in the bit-bucket where they belong. What I ask of all you developers out there is not only your criticisms of my ideas, but also your ideas about printing! What printing features do you need that I might not have a clue about?

There's a window of opportunity here for developers to have a some input on how printing works on the BeOS. That window, however, is swiftly closing, as I will need to shift from designing to implementing in the next month or so. So speak now or hold your peace until the next big revision.

The engineering articles in the next few issues of the Be Newsletter will almost certainly concentrate on features that you'll find in Release 3. Without stealing my cohorts' thunder, here are some rumblings:

Look for a wagonload of Tracker improvements, among which:

• Tracker will remember the correspondence between windows and workspaces such that when you reboot your machine, your restored windows will be placed in the correct workspaces.

• When you open a folder window that's already open in some other workspace, the folder window will be brought to the workspace that you're in (and removed from its present workspace).

• Tracker will let you drag a text selection from a document and drop it on the desktop; a file will be created to contain the "clipped" text. If you then drag the clipped text file and drop it on an open document, the text will be pasted at the insertion point.

• Tracker will be scriptable. You'll be able to ask for the Tracker for specific windows, examine their contents, create or extend a selection, and so on.

Speaking of scripting:

• The suite of scriptable objects has been expanded. Of particular note, you'll be able to talk to a window's menus and play with its controls.

And speaking of windows:

• The BWindow class will let you create window "sets". A particular window can be told to float (or be modal to) all the other windows in its set. You'll also be able to float a window above the other windows in the same app, or above all windows on the screen.

• BWindow has divided its notion of "type" (bordered, titled, floating, etc.) into "look" and "feel". You'll be able to create a window that has (for example) a titled "look" and a floating "feel".

• You'll also be able to sort window layout front-to-back through a new SendBehind() function.

MIME support has been improved:

• In compliance with the MIME spec, MIME string comparisons will be case-insensitive.

• The MIME-knowledgable classes (BMimeType, BNode, BAppFileInfo) will be smarter about the relationship between supertypes and their subtypes. For example, you'll be able to ask a type whether it's "contained" within some other type.

• The FileTypes app will let you draw icons for specific MIME types.

Some odds and ends:

• The BTextView class will provide a simple, single-branch undo mechanism, and will give you a hook so you can install a more complicated system.

• BListView will let you sort, swap, and replace items. BOutlineListView will let you perform these tricks to the list at large, or to a single branch of the tree.

• The Node Monitor will send a notification if an attribute is added or removed from a monitored file.

• NetPositive is even more positive. Look for frames, Java, and (my favorite) scrolling memory: When you click "back", the returned-to page is automatically scrolled to the place where you left it.

And, of course, this will all run on a slightly wider audience of processors.

During the Xmas break I received a few e-mail messages asking why we were participating in the annual San Francisco MacWorld. What are you doing there? I thought you guys were moving to Intel processors, this is a PowerPC show. That's one way of looking at it. Our perspective is, of course, a little different.

First, we have a PowerPC version of the BeOS, and a partner, UMAX, shipping Power Mac clones bundled with the BeOS. UMAX also makes Intel-based PCs and we'll show the BeOS on these machines, too.

Second, the San Francisco MacWorld is an excellent venue for us to gain additional exposure; it's close to home, and many attendees are just the kind of creative, enterprising users we'd like to attract to our software platform. The BeOS adds value to both PowerPC machines and Intel-based systems. This fact, and for whom it is relevant, are more important issues than what hardware the BeOS runs on.

Some correspondents were aware Apple had officially turned down our request for technical support to port the BeOS to the latest G3-based Power Macs. They asked what our response was and what it meant for the future of the PowerPC version of the BeOS. Well, we're still scratching our head. We'd be happy to add a little value to Apple's hardware, but we're not interested in engaging in reverse-engineering efforts, or in public controversy, over this issue. As for the future of the Power Mac version, as long as we have willing partners, and developers and customers for it, we'll continue to make it available.

But all this leaves out the most important reason why we're at MacWorld: BeOS developers—both current and future ones. With our current developers, we'll be showing off what can be done on our platform, which we expect will stimulate new developers into writing software for the BeOS.

For the latest news on this topic, please point your browser to http://www.be.com/developers/, to the section on BeOS developers and applications—many are available for sale and/or test drive at BeDepot, http://www.bedepot.com/.

This said, in the future, our intent is clearly to promote our Intel-based product. So we'll exhibit at Software Development '98 next month and, in June, at PC Expo in New York City. I guess we'll know we're doing the right thing when we get mail asking why we're showing a PowerPC version at such an Intel-dominated venue.