Plan Be

by Henry Bortman and Jeff Pittelkau

from the February 1997 issue of Australian MacUser magazine

The Mac commnunity has been electrified by the announce1nent that Apple’s next OS will be based on NeXTstep technologies. But, if this hybrid OS does not meet our expectations, Power Mac users will soon be able to use a third-party alternative: a strategy we dub ‘Plan Be .’

---

Apple has its work cut out for itself. After slip­ping the schedule on Copland, its much bally-hooed next-generation operating system (OS), by nearly two years, the company has now cancelled the project entirely and announced an alternative strategy that involves the use of NeXTstep technolo­gies. The hybrid OS sounds good, but it will not ship until 1998.

Apple has been beaten to the punch by twice by Microsoft, first with Windows 95 and more recently with Windows NT 4.0. And the word on the street is that Windows NT 4.0 is stable and fast. Finally the PC marketplace has an operating system that can tur­bocharge the key applications, such as Adobe Photo­shop and Macromedia Director, that content creators have historically bought Macs to run.

True, Windows NT’s user interface and APIs aren’t as elegant, extensive, or powerful as the Mac’s. However, many people are willing to trade these things for stability and performance. Weary of Type 11 errors, users are starting to take notice of headlines that say things about NT 4.0 such as ‘Never reboot again!’

If the Windows NT 4.0 challenge wasn’t enough, Apple now has Be, led by former Apple technology head honcho Jean-Louis Gassee, nipping at its heels as well. Be is developing - from scratch - a thoroughly modern operating system that, like the Mac OS, runs on PowerPC processors. Unlike the Mac OS, however, the BeOS demonstrates just how powerful PowerPC processors really are. On identical hardware - Be has ported its operating system to run on Mac hardware - the BeOS leaves the Mac OS 7.x in the dust.

To add to the pressure on Apple, Power Comput­ing has signed an agreement with Be to bundle the BeOS for Power Mac with its Mac clones. That should be beginning to affect shipping product as you read this. The implications of this move are stagger­ing. It is only in the last couple of years that Apple has allowed other vendors to clone the Mac and cus­tomers have had a choice of companies to purchase Mac hardware from. Now, with the advent of the BeOS, Mac users will also have an alternative operat­ing system to run.

So just what is the BeOS, and why all the hoopla? To find out, we hauled a couple of BeBoxes (BeBox is Be’s name for its proprietary multiprocessor PowerPC-based computers), along with an alpha version of the BeOS for Power Mac, into our labs and ran the new OS through its paces. What we found is detailed in this exclusive report on the OS that Power Mac users will soon be able to choose for themselves even though Apple has chosen another OS for us.

Why the buzz about Be?

Take one look at the BeOS, and you’ll be stunned. It’s amazing to see a BeOS system simultaneously play multiple QuickTime movies and an audio file, serve and browse Web pages, and render 3D animation, all in real time. Don’t try this on a Mac.

On the Mac, if you hold the mouse button down on the menu bar, your whole Mac will essentially go to sleep until you release the mouse button. This is true for any Mac, whether it has one, two, or four processors. It doesn’t matter how fast those processors are either: they could be running at lOOOMHz, and your Mac would still grind to a halt.

After we’d pounded on our BeBoxes and Be-pow­ered Macs for a few weeks, going back to the Mac OS - even on powerful Macs - was painful. The rea­son? The BeOS implements precisely those modern operating-system technologies that are missing from System 7 and whose absence holds the Mac back.

To put it bluntly, the speed of the BeOS is nothing short of phenomenal. When we first encountered it, the BeOS was running on a proprietary BeBox. All BeBoxes ship with dual processors, so we assumed that the responsiveness of the system was due in large part to the second processor and faster hardware.

Even if that had been the case, we would still have been impressed. On the Mac, multiprocessor systems are useful only for accelerating specific processor-cycle-intensive functions in a handful of multi-processor-capable applications, such as Photoshop. The Mac OS itself does not know how to use multiple processors. The BeOS, in contrast, imple­ments fully symmetric multiprocessing, so all the work done on a dual-proces­sor system is distributed between the two CPUs and hence every task on the system gets a boost.

Impressive as the BeBox was, it was when we saw the BeOS running on a PowerCenter 150 that our jaws dropped. Keep in mind that by current standards, the 150MHz PowerPC 604 chip in this sys­tem is somewhere in the middle of the processor-speed spectrum. Even though the PowerCenter wasn’t tricked out with the speediest processor available and although it contained only a single CPU, the BeOS ran circles around the Mac OS running on the same machine. When you think about it, though, it actually behaved as you’d expect a computer to behave: when we clicked the mouse on a button or a menu, it responded. Instantly. No matter what else was going on.

We’ve all grown so used to the limitations of the Mac OS that we hardly give it a second thought when we have to wait up to a minute for an application to launch. Or when we can’t do anything but sit and watch a progress bar while we wait for a file to finish copying. Or when we click on the menu bar and several seconds elapse before the menu appears. Or when the Mac crashes. And crashes again. And again.

Did we mention the BeOS’ stability? Although the system software we tested was alpha, it almost never crashed. And when it did, it was rare that anything other than the offending application was affected. The rest of the system, and other applications, stayed up and running. What makes an OS stable? Protected memory, virtual memory, and object-oriented design, and the BeOS implements all three.

To love and protect

In an operating system with protected memory, such as the BeOS, each application runs in its own memory space, which can’t be written to by other applications. If an application tries to access another application’s memory space, the BeOS terminates the offending application without bringing any other application or OS process down.

Memory protection is also provided in Windows NT. In fact, Microsoft takes this matter very seriously in Windows NT 4.0 - if any application can crash the operating system Microsoft considers that a bug. However, in Apple’s System 7, there is no memory protection - applications and extensions are free to stomp on other applications at will. When an applica­tion writes to an inappropriate memory address, you usually h ave to reboot your entire system and relaunch all the applications you had open.

Copland would have provided protected memory for ‘server tasks’. That’s the term Apple uses to describe many parts of the OS and some applications or portions of applications. The catch: in order to qualify as a server task, an OS or application function can’t access the Mac user-interface toolbox. Examples of server tasks under Copland included the Mac file system (although not the Finder) and a Photoshop filter operation - (although not the redrawing of the results of the filter to the screen).

The Mac Toolbox and all applications that have user interfaces - in other words, everything that users interact with directly - would have run together in one shared memory space. Within this shared memory space, applications would have inter­acted pretty much as they do in System 7. Any applica­tion that crashed would have been just as likely to take down the whole Mac user environment as it is today. Server tasks, which would have included much of the nuts and bolts of the Mac OS, would have kept running. The net effect: your Mac would still have crashed, but it would have taken less time to reboot, because you wouldn’t have needed to restart the whole OS.

Virtually there

The BeOS and Windows NT both support a true virtual-memory system. Copland was to have one as well. A virtual-memory system provides an applica­tion with as much memory as it needs, on the fly, first by parcelling out RAM and then by using space on a hard disk as additional RAM. In a virtual-memory system, memory is divided into small sections called pages. The most recently used pages are kept in ‘real’ RAM, where the processor has rapid access to them. Less recently used pages are stored on the hard disk, ready to be reloaded into ‘real’ RAM as needed.

On a true virtual-memory system, you don’t have to specify ahead of time how much memory you want. The OS automatically assigns virtual RAM to an application whenever it needs it. As you launch more appli­cations or work on bigger files, more hard-disk space is allocated to accommodate the demands of your work. This means that you can run a lot of applications with only a small amount of physical RAM in your system.

System 7 has a virtual-memory system, but it’s lim­ited. Its swap file (the virtual-RAM space on the hard disk) is a fixed size. To change it, you have to reboot. Also, you must tell the OS ahead of time how much memory to allocate to each application. Unless you provide enough memory to a particular application, you may be greeted with an out-of-memory error.

I object

The BeOS is a fully object-oriented operating sys­tem. One benefit of this is that programmers have aneasier time developing BeOS programs than they do developing programs for the Mac or for Windows, because they don’t need to use as many Application­ Programming Interfaces (APis). For example, to pro­gram Clipboard functions as well as interapplication communication into a Macintosh app, developers must use two separate APis. But with the BeOS’ object-ori­ented design, the same Be API can be used to accom­plish both tasks. Moreover, BeOS code is reusable. This makes BeOS programs quicker and easier to develop; it also makes them smaller, faster-launching, and - due to their simpler design - more stable.

Be fast

Modern operating systems use a mechanism called pre-emptive multitasking to efficiently allocate micro­processor time among multiple applications and OS services. The BeOS and Windows NT utilise preemp­tive multitasking. In both operating systems, a low­-level task manager called a microkernel schedules tasks in round-robin fashion according to their prior­ity. Each task is allowed access to the processor for only a fraction of a second, called a time-slice, which in the BeOS is only three-thousandths of a second. Preemptive multitasking is what makes it possible for a BeOS system to perform multiple complex tasks simultaneously.

Even in the BeOS, pre-emptive multitasking has its limitations. As you run more and more applications, new apps launch more slowly, text-based apps begin to get a bit sluggish, then multimedia events such as video playback start to get jerky, and finally - if you push the system hard enough - the mouse gets less responsive. But on a BeOS system, you have to try really hard to get things to bog down, and this is almost always caused by an overloaded virtual-mem­ory system.

The Mac OS, on the other hand, uses a scheme that Apple has dubbed ‘cooperative multitasking’. For years, Apple went to great lengths to convince cus­tomers that cooperative multitasking was actually bet­ter than preemptive multitasking. Now that the shortcomings of the Mac OS’ approach have become evident, Apple doesn’t bother singing the virtues of cooperative multitasking any longer.

Under cooperative multitasking, each application can keep control of the processor for as long as it wants. Whenever it feels like it - the application’s programmer decides how often that will be - an application checks to see whether or not another application would like some time on your Mac’s CPU. As a result, an e-mail client program can lock up your Mac for minutes at a time, allowing no other work to go on while it sends a file to the server.

What’s frustrating about this approach is that most applications don’t keep the processor busy the whole time they have control of it. Much of the time, an application is waiting for tasks to complete that aren’t dependent on the processor - sending data over the network or reading a portion of a file from disk, for example. During these precim.is fractions of a second, other applications could be using the proces­sor to get work done.

Under Copland, preemptive mul­titasking would have been available only to server tasks. The reason for this limitation lies in another modern OS feature: re-entrancy. Re-entrancy allows the same toolbox code to be shared by many tasks simultaneously. The Copland toolbox would not have been re-entrant. If, for example, one application requested the Cop­land toolbox to create a new window on the screen but was pre-empted by another app also requesting a new window, the toolbox would get con­fused, causing the system to crash. In a pre-emptively multitasked system, such overlapping calls are common.

Under Copland, faceless parts of the Macintosh toolbox, such as the file system and networking, were sup­posed to be re-entrant. However, without a re-entrant user-interface toolbox, applications that require a user interface - and most do - would have continued to be coopera­tively scheduled, much as 1 6-bit Win­dows applicati ons are under Windows NT. Apple didn’t plan to introduce a re-entrant user-interface toolbox until Gershwin.

Be faster

Part of what makes the BeOS snappy when handling multimedia tasks is its emphasis on multithread­ing. Threads are parts of programs that independently manage individual streams of computation or communi­cation with other programs. The BeOS enables applications to generate threads even when programmers have done nothing explicitly to set the threads up. For example, if you play a video on a BeOS system, the OS gen­erates two threads: one, for the video player, decompresses the video frame by frame, and the other, in the BeOS’ application­-server code, manages drawing those frames in the win­dow on the screen. The short duration of the time-slice allotted to each thread, combined with the high prior­ity given to multimedia threads, is what makes the BeOS so good at doing lots of multimedia tasks simul­taneously. Both Windows NT and the Mac OS sup­port limited threading, but developers must specifically support threading in their programs to take advantageof the feature.

Another performance-boosting capability of the Be operating system and Windows NT is symmetric mul­tiprocessing (SMP), which is the ability for multiple threads to run simultaneously on multiple processors. Right now, the BeOS can support two processors; Windows NT (in server configuration) can support up to 32 . On the BeOS, symmetric multiprocessing allows multithreading to really pay off, especially when there’s lots of input/output (I/O) happening. On a two-processor BeBox, for example, it’s possible for one thread to be decompressing a frame of a movie on one processor while another thread uses the second processor to display the frame that was just decom­pressed. The BeBox’s two relatively slow (and inex­pensive) processors enable the BeOS to do more things at the same time, and more smoothly, than it would on a system with one more-powerful processor.

System 7.5 supports multiprocessing, but it’s not symmetric. In 7.5, all the processors in a multiproces­sor Macintosh work on different parts of the same task. Applications can send requests for performance of tasks - applying a Photoshop filter, for example - to only one of the Mac’s processors at a time. That processor, in turn, can parcel out subtasks - say, applying the filter to different sections of the image - to the other processors. But one processor can’t be working on a Photoshop filter while another is send­ing e-mail over the network. And even this limited multiprocessing must be explicitly supported by the application.

Interface homage

Of course, along with every new operating system comes the opportunity to reinvent the graphic user interface, but this is one arena where the BeOS doesn’t make any great leaps forward. Rather, its interface is a pastiche of features borrowed from other operating systems. It includes the de rigueur file and folder icons. It has menus. It has windows. The windows have scroll bars, close boxes, zoom boxes, and title tabs. Double-clicking on a window’s title tab min­imises the window so that only the tab is visible (a la Copland’s promised Drawers feature).

Be also appears to have made some curious omis­sions and a few bizarre choices. For example, even though there is a desktop, you can’t put icons on it. Instead, Be has placed a NeXTstep-like dock on the left side of the desktop, to which you can drag aliases of files and folders for easy access. But the dock’s capacity is limited. Mean­while, most of the screen’s real estate remains unavailable for drag-and-drop operations.

Then there’s Be’s approach to menus. There is no universal menu bar at the top of the screen like the Mac’s. No prob­lem there. But it seems as though Be couldn’t quite make up its mind about what it wanted to do about menus. At the top left of the dock sits a main menu. It changes as you switch among applications.

In addition, many applications have menus in each window. These are supposed to contain commands specific to the contents of the window. We’re sceptical about how well this partitioning scheme is going to work in a complex application. In the limited set of example programs Be currently ships with its OS, there appears to be no consistent set of rules that gov­ern which commands can be found where.

Be good enough?

Another intriguing feature of the BeOS is its built-­in database. A hybrid of relational and object-oriented technology, the database is a system resource both the OS and applications can take advantage of.

For example, the BeOS’ file system makes exten­sive use of the database. Information about files’ names, types, creators, creation and modification dates, and so on is stored in the database. This makes the Be Browser’s Find command return results in the blink of an eye. It also enables queries to be live: if a filename changes or new files are created, query results update automatically.

Be also uses the database to provide a directory service called People. People contains database records that store information about individuals and compa­nies, such as name, address, phone numbers, and e­-mail addresses. This feature, in turn, is integrated with Be’s Internet-mail application, BeMail. To address an e-mail message, you need only drag People icons to the messaging window’s address fields. Both People information and other OS-managed data can be utilised by application developers.

Beyond the database and its multitude of modern OS features, the BeOS provides little of the elegance the Mac OS is famous for. The Macintosh as we know it today is not so much an operating system as it is a collection of great software technology. What makes the Mac OS great are APis such as QuickTime, QuickTime VR, QuickDraw 3D, WorldScript, and ColorSync. It is these technologies, along with the advantages of its user interface, that continue to make the Mac the platform of choice for publishing, multi­media authoring, and Web-content creation. At this point, BeOS has no colour management. It doesn’t currently support double-byte languages, such as Japanese and Chinese, or localisation of the OS for French, German, Spanish, and so on - which makes building an international market a bit of a challenge. It also has no scripting language, nor does it have anything nearly as robust as the QuickTime Media Layer for managing media.

All these are problems that Be says can be solved with - capabilities already present in the OS. Making marketing claims and delivering the goods, however, are two different things. The question remains how - and when - Be will actually come through with solutions to these problems.

And then there are the issues Mac users will find particularly vexing. The BeOS version we tested couldn’t recognise Mac-formatted floppy or hard disks. In fact, you can’t use the Mac floppy-disk drive at all, even with BeOS-formatted floppies. Be doesn’t yet have a driver for it. The only printer the DR8 release of the BeOS currently supports (an HP Laser­Jet IIp or compatible) requires a parallel connection. Macs don’t have parallel ports. So no printing either. And Be’s contextual-menu feature requires a two-but­ton mouse which, to date, only one Mac OS system (Motorola’s StarMax) supports. So Mac-o-philes can forget about contextual menus, at least for now.

To be fair, dealing with these problems is high on Be’s priority list and you can expect the company to solve them before any widespread distribution of the Mac version of the OS occurs.

Then, of course, there’s the question of applica­tions. There are hardly any. That, too, will change. But at press time, only a few vendors were willing to go on record as developing for the BeOS. Among these were WebStar, working on a BeOS-savvy version of its Web server, and a company developing an installer. Adobe is also supposedly working on a version of Photoshop for the BeOS, but at press time, it had not committed to shipping it.

Be is also investigating ways to enable users to run existing Mac applications on the BeOS. Most of these methods involve some kind of ‘virtual machine’, an emulated Mac environment that runs within the BeOS.

In many ways, it’s similar to how Apple planned to support pre-Copland Mac apps under Copland. But whereas Copland would have offered developers little in the way of advanced OS features, the BeOS - like NeXTstep, the basis of the next Mac OS - offers all the advantages of a modern operating system.

Even with all these problems, every one of us who worked with the BeOS was left with a similar impres­sion. If we could get our daily work done on the BeOS, we’d all have BeOS-enabled Macs in no time.

We may be a long way from that day. But one thing is very clear: with the arrival of the BeOS on the Mac, developers are looking at the BeOS more seri­ously - and so are Mac users.