Time for a New OS?
Mac OS Got You Down? Considering NT? Should You Wait for the Be OS?
By Galen Gruman
Macworld
February 1997
Desperate times, desperate measures. That's what Apple faced this fall, after its Copland operating system strategy fell apart, leaving the Mac with no significantly new OS in sight for several years at a time of crushing competition from Microsoft's Windows 95 and NT.
Into this period of uncertainty comes a potential white knight, a new OS for the Mac developed by a group of Apple refugees at Be, Inc., led by former Apple product-development chief Jean-Louis Gassee. The Be OS provides many of the features promised for Copland (the former code-name for Mac OS 8): protected memory, preemptive multitasking, multithreading, and an all-native code base. But it lacks one key attribute: compatibility with today's Mac programs.
To listen to the people at Be, or to the popular media, it seems inevitable that Apple would purchase or license the Be OS and use it in place of Copland as Mac OS 8. That would be a major shift for all of us–forcing us to update all of our software or switch back and forth between the Be OS and System 7–but would give the Mac the next-generation OS platform that many believe is essential to the Mac's survival. However, sources close to Apple tell Macworld that Apple likely won't buy the Be OS, even though it may license some Be OS components (see the sidebar "What Is Apple's Mac OS strategy?"). To follow this developing story, be sure to check Macworld's Daily News.
Apple CEO Gilbert Amelio admits that the two companies are discussing possible partnership or licensing arrangements that could result in some Be OS technologies making their way into the next Mac OS. Be is also discussing licensing the Be OS to Motorola Computer and other clone makers (Power Computing already has a license); Gassee said he would be willing to license to everyone but Apple if Apple balks.
Behind the Scenes
A couple of years ago, the Mac had a good OS and slow hardware. Then the PowerPC came to the rescue, and with continuing speed increases today and more expected in the next few years, the Mac hardware platform is at least as good as PC hardware. Now it's the Mac's longtime advantage–the OS–that's failing us. Today, the Mac has good hardware and a slow OS.
Copland was supposed to change that by throwing out the guts–called the microkernel–of the decade-old Mac OS and replacing it with NuKernel, a microkernel based on the Mach OS, a variant of Unix favored by engineers. But something went wrong–Apple focused so much on backward compatibility with Systems 6 and 7 that it stymied Copland's development and essentially weighed the OS down until it sank under the load. The problem isn't NuKernel, but all the OS components loaded on top of it to both provide new features and support all of today's applications.
The Be OS is different. Unfettered by compatibility with 680X0 processors, applications, and the Mac OS in general, the Be OS looks to be a powerhouse, one that can rival Windows NT in multimedia authoring, image editing, 3-D graphics, and video production:
In short, the Be OS sounds a lot like what Copland was supposed to be.
Like Copland, the Be OS uses a new microkernel. But that's not what makes it attractive to Apple. Be's kernel and Apple's NuKernel are not very different. What Be brings to the table is the rest of the OS–the equivalents of the Mac's Toolbox routines, extensions, and managers, which provide all the services you and your programs rely on. Because the Mac OS has evolved over 14 years, it has a lot of patches, exceptions, and tricks in its OS services made to ensure compatibility. The Be OS, by contrast, is streamlined. It offers clean services without all the patches. This should make it more efficient and more stable.
Momentum for Be
Three months ago, Be showed the Be OS running on a Power Computing PowerCenter system. Since then, the Mac industry has been abuzz over the possibility: forget Copland and adopt the Be OS as the next Mac OS. Apple's negotiations with Be about a possible deal or buyout have been fueling those cries.
There is more momentum behind Be as well:
But–and it's a big but–the Be OS doesn't run Mac programs, and it doesn't have several key Apple technologies, or equivalents, that would be essential for Mac developers to offer Be OS versions of their Mac software.
What's missing? A network-abstraction architecture like Open Transport, as well as personal file sharing (like AppleShare) and a network file system. Scripting, agents and other active-assistance technology, and a component architecture like OpenDoc. Mac-quality printing services, including PostScript drivers, desktop printing, and n-up printing. A complete multimedia architecture like the QuickTime Media Layer. Be could develop these components or perhaps license them from Apple to bring to the Be OS, but that won't happen overnight.
Be's Possible Paths
Could the Be OS be the next Mac OS? Or is the Be OS just another OS that will enjoy a little fame and then join other wannabes like the Next OS, OS/2, AmigaDOS, and GEM? Or will Be take a third route–that of the high-end OS for Mac systems, similar to NT's path on the PC platform?
Be as the Next Mac OS
Forget Copland and go with Be–that's what some Mac enthusiasts urge as they hear about 1999 as a realistic date for when the major Mac OS rewrite needed to compete with Windows NT will ship.
True, the Be OS has many of Copland's promised features, but the Be OS is not complete–Be engineers still have a fair amount of work to do in adding file services, network services, and other key components. That was clear to Macworld when we worked with a prototype version and found its core services just half-built. While the first shipping version of the Be OS is expected soon, don't be surprised if it needs some updates and improvements. In fact, Be plans to ship twice-a-year upgrades on a subscription plan.
More important, the Be OS won't run any Mac programs, and the number of commercial programs now available on the Be OS is zero. The latter problem could be alleviated if Adobe ships Photoshop for the Be OS and other companies follow suit with critical programs. But that will take a year or more to reach critical mass in just those specialty areas.
The first problem is trickier–none of the programs that you use today would be available to you if you switched to the Be OS. The engineers at Be don't have a magic answer to this problem. There are two options they could pick, and both have strong drawbacks.
The first option is to write a Mac emulator–basically a port of the Mac OS that runs within the Be OS and that itself runs a Mac program within it. A user would not see the Mac OS; instead, double-clicking on a Mac application's icon would launch the program within a Mac OS "wrapper." The downside is that the Mac program could not take advantage of extensions or interapplication communication with other Mac programs that might be running, which means it would lose functionality or not run at all.
The second option is for Be to create a full or nearly full Mac emulation or port that would run Mac programs just like the Mac OS. This would be essentially a port of the Mac application programming interfaces (APIs) to the Be OS's inner core, the microkernel. Sound familiar? That's because this is exactly what Apple needs to do to port the current Mac OS to the NuKernel microkernel chosen for Mac OS 8. The API port would take Be several years–longer than it will take Apple to finish its work on Mac OS 8.
While they're cagey about the discussions with Apple on the Be OS's future, the engineers at Be indicate that they don't like either option. They're not interested in replacing Copland with a Mac OS-compatible version of the Be OS. They'd rather see people adopt their OS and run Be OS-native software. Still, Be and Apple seem to be heading to the conclusion that if the Be OS becomes Mac OS 8, a Mac compatibility window is the option they'll pick.
Be as a Mac OS Alternative
What Be seems to want–and the option that I believe gives Be the best shot for success–is to coexist with the Mac OS, in a way similar to how Windows NT coexists with Windows 95. And Apple seems to agree.
The Be team likes to compare its OS to the Amiga, the multimedia wonder of the early 1980s that gained a fanatical following (Mac owners look like PC owners when put up against Amiga owners) in the music and video crowd. The Amiga failed, but the Be team says that's because the technology was premature–15 years ago, there weren't hard drives big enough, CPUs fast enough, memory cheap enough, or peripherals capable enough to handle digital audio and video. Today, there are.
The Be team also sees the high-end multimedia crowd as its entree into the Mac's traditional stronghold. The strategy is–and Be officials will politely confirm this if asked–to take over the high-end users who once drove the Mac's innovation. First Photoshop, then media authoring, then publishing, then Internet serving. That leaves the hobbyists and office users, who can stick with the Mac OS, use Windows NT, or wait until the Be OS squeezes out the Mac OS (if it does).
While some people position Be as the savior for the Mac, a successful Be OS could in fact marginalize the Mac OS, leaving the Mac hardware platform in place but replacing its soul. That's why it would make the most sense for Apple–if it wants to use the Be OS as the foundation for the next Mac OS–to buy Be and subsume it, rather than merely license it and watch control over the Mac OS slip to another company.
Ironically, Apple had a similar opportunity three years ago, when its engineers ported the Mac OS to the 80486 chip and got it to outperform the 68040 Macs of the day. This was before Windows 95. A Mac OS for PCs could have squeezed out Windows, which had suffered for years through terrible implementations and was only just getting a decent version (3.1). Apple's management at the time decided not to move forward with the Mac OS for the PC, and the rest is history.
The Be OS's potential to rescue the Mac platform by slowly easing out the Mac apparently has not been lost on Apple's current management, leading to the licensing and acquisition discussions with Be. (This is also the strategy that Microsoft is using to replace Windows 3.1 and 95 with Windows NT.)
With or without Apple's support, Be has a shot in getting the Be OS onto the Mac platform. What's needed are a few key programs like Photoshop and the ability to run the Mac OS and the Be OS separately but simultaneously, requiring you to switch windows or change view modes–similar to how SoftWindows or DOS-card users switch between the Mac OS and Windows. Add Power Computing's distribution of an affordable package from Be with its new systems, and it could be common among high-end users to use the Be OS on their Macs, even if their business software and utilities remain on the Mac OS.
If Apple buys Be, it could follow the same strategy, providing a high-end OS and a midrange OS simultaneously for a few years, giving developers time to port to the Be OS.
There are four possible barriers to this complementary-OS scenario:
The Last Word
The Be OS has rekindled some of the excitement the first versions of Copland created two years ago. It even has a chance to save the high end for the Mac platform, if not for the Mac OS. But it's a new, untested OS that could soon be battling with Windows NT directly. My bet–short of Apple's acquiring Be–is that the race will continue to be between Windows (NT) and Mac OS (8). The Be OS has a chance, and exploring it won't cost you any more than the price of the OS itself, the extra drive space, and your time. Beyond that, it's a familiar game for Mac OS watchers: wait and see.
Macworld executive editor GALEN GRUMAN has worked with at least ten operating systems since 1978.
Sidebar
How Do the Operating Systems Compare?
The Be OS Has Much That the Mac OS Doesn't–And Vice Versa
Everything about the Macintosh inspires passion, and this latest brouhaha about which operating system to use is no exception. One side believes Apple should scrap its plans for Mac OS 8 and replace it with the Be OS. Other, equally fervent believers contend that Apple should concentrate on finishing what it started with Mac OS 8. Perhaps the best solution lies somewhere in between.
Why are some developers so enamored of the Be operating system? For starters, it uses the latest OS technology and offers many features that even Mac OS 8 can't. With protected memory, if one Be application crashes, it won't bring down the entire system. With Mac OS 8, it is still possible for one application to crash all the others. Also, because each window in a Be application operates in its own thread and is preemptively scheduled, you would, for example, be able to open multiple Adobe Photoshop files and simultaneously run a different filter on each of them while copying files in the background–and still have a responsive system.
The Be OS also fully supports multiprocessing systems, unlike Mac OS 8, where cooperatively scheduled tasks (that is, anything using the Toolbox) cannot run on different processors.
These features were not scheduled for Copland mainly so that it could retain backward compatibility with current applications. For Apple to integrate them into the Mac OS now would cause another long delay in its schedule.
But Who's Going to Build It?
All these features sound great–but no platform can be successful unless developers embrace it. If Apple were to replace Mac OS 8 with the Be OS, its developers would have to rewrite their applications to be compatible with, and take advantage of, the new operating system. The developers would also have to familiarize themselves with C++ and object-oriented programming.
Even facing this challenge, many developers are excited about Be. Several have noted how easy the Be OS is to code for, even going so far as to describe programming for the Be OS as "fun," a word not usually associated with writing Macintosh applications. The Mac OS, from years of evolution, carries a lot of baggage, and developers often complain about how much work it takes to support the system and create even the most basic application. The Be OS itself handles much of the basic work of application development, from handling event loops to creating threads. The APIs that developers need to communicate with the operating system are much simpler than the Mac's. Documentation for the Be OS is considerably more concise than Apple's for the Mac OS, freeing the developer to concentrate on implementing its program's features.
Of course, there's a simple explanation for some of Be's programmatic simplicity: it doesn't support many, often complex, technologies that form the core of what we take for granted in the Mac OS. Remote Access, desktop printers, multilingual support, and use of multiple monitors are all unavailable in the Be OS. Some technologies that already exist in cross-platform versions–such as the QuickTime Media Layer and OpenDoc–may be relatively easy to port to the Be OS. Some Mac-specific technologies are another matter altogether. OpenTransport, for instance, is not currently platform-independent, nor does Apple plan to make it so. Given how difficult it was to incorporate Open Transport into System 7.5.X, it probably won't integrate easily into a new environment.
Apple is unlikely to support an OS that does not offer these features. However, migrating the features into the Be OS would more likely than not take several years–perhaps as long as it would take Apple to finish implementing them for Mac OS 8. Finally, once these Mac features are ported over, the Be OS's advantage of API simplicity, the very reason many developers would embrace Be, will have been erased.
Interface Problems
There is also the issue of the user interface. Apple's Human Interface Team works very hard to ensure that Macintosh users are presented with a consistent and easy-to-use interface. Be's interface lacks a universal menu bar, which may shock many Mac OS users. In fact, some applications do not even have a menu bar–quitting the application requires that you go to a menu attached to Be's version of the Launcher. The use of the two-button mouse, while well implemented in places, is not always consistent from application to application. Nor will the Be OS readily support customized views and appearances.
To create a hybrid Mac-Be OS, both companies would need to sacrifice. Apple would need to abandon application compatibility (but if it were willing to do that, it probably could have shipped Mac OS 8 by now). Be would have to sacrifice its API simplicity. It may serve both companies better to merely collaborate on new developments.
Sidebar
What Is Apple's Mac OS Strategy?
Don't Look for the Be OS to Become the Mac OS Anytime Soon
As we go to press, Apple has been discussing possible use of Be technology, but it appears unlikely that the company will buy the Be OS and use it as the platform for Mac OS, according to sources close to Apple. Instead, the company is evaluating technologies from several sources–within Apple, at Be, and elsewhere–for adoption into Mac OS 8.
The New Mac OS 8
The company has also figured out a new strategy for Mac OS 8. This calls for Mac OS 8 to have three basic components: the microkernel that provides the basic file-management, networking, and computational services; the modern application programming interfaces (APIs) and services expected in Copland and its original follow-on, Gershwin; and the System 7 APIs that ensure compatibility with today's programs. Examples of APIs include QuickTime, QuickDraw 3D, Open Transport, and OpenDoc.
Apple's new plan lets Mac OS 8 run most of today's programs, including system extensions (which the original Copland did not support).
Among the Mac-compatibility options being explored at Be for the Be OS is to create the equivalent of a SoftWindows or Macintosh Application Environment–a separate workspace that runs Mac applications isolated from Be applications. Apple's approach won't erect such a wall. Instead, System 7 programs will use System 7 APIs, while Mac OS 8 programs will use Mac OS 8 APIs.
This is similar to how Apple let PowerPC and 680X0 applications coexist on Power Macs. It differs from the original Copland approach to compatibility, which tried to graft modern OS services onto today's System 7 APIs. That effort compromised both compatibility and the effective use of modern OS services.
Under Apple's new plan, system extensions would run, but only System 7 programs could use them. Mac OS 8 programs would not use extensions. This scheme lets Mac OS 8 programs be separate tasks in the OS, with their own protected memory. Even the original Copland didn't go that far–it was the Gershwin OS that was planned to offer memory protection for each program.
For users, the difference between Mac OS 8 and System 7 programs would be largely invisible. The programs would simply use the APIs they needed, and not be affected by the other ones. Thus a System 7 program would need to use the DayStar multiprocessing API to take advantage of multiple CPUs, while a Mac OS 8 program would use the new SMP API. This lets Apple focus on using advanced technology for Mac OS 8 programs without needing to lard the Mac OS 8 APIs with features for System 7 programs. Having essentially two OSs in one will likely make the System Folder significantly bigger, but that's a small price to pay.
Where Apple Stands
The microkernel is mostly done, and the System 7 APIs are of course done. That leaves the modern OS components plus the glue needed to have the modern OS and System 7 OS coexist in Mac OS 8.
Obviously, developing all the new technologies will take some time, since Apple can't use most of the Copland APIs so far developed. Sources close to Apple say the company is also shopping around for needed technologies, looking to buy technologies that are further along than Apple's internal efforts. One example: the Java Virtual Machine, an API that Sun has already written.
Apple has no estimated time for releasing Mac OS 8, although late 1997 or early 1998–not 1999–seems increasingly likely given the new approach.
Copyright 1997