Originally published: May 23, 1997
Last modified: June 14, 1997
Rhapsody Architecture Diagrams
Apple's Rhapsody Pages
I'll begin with some introductory remarks about Apple's dual OS strategy and delivery schedules and my perspective on Apple's problems. Then I'll give a fairly detailed overview of Rhapsody's architecture. Then I'll briefly discuss Apple's cross-platform plan, which I think is quite important and interesting. I'll finish with some concluding remarks and invite questions and answers.
Please keep in mind some important terminology I'll use throughout this presentation. When I say "Mac OS", I mean the classic Mac OS that we use today and will continue to use for the foreseeable future - System 7 and its soon-to-be-released successor System 8, code-named "Tempo", and future versions (Allegro, Sonata, etc.). When I say "Rhapsody", I mean Apple's future completely different operating system.
Since the first publication of this report on the web on May 23, I've received an enormous amount of very positive feedback. There's clearly a huge amount of interest and enthusiasm about Rhapsody. The page got 30,000 hits in the first week alone! As people send me comments and corrections, I've been editing and expanding the report to include them. I'd like to thank everyone who has contributed. I'm continuing to tinker with it pretty much continuously.
The Mac OS is alive and well. By the end of the ill-fated Copland era, there were only six engineers on the Mac OS team. There are now over one hundred! Apple plans an aggressive schedule of major Mac OS enhancements and new releases. Mac OS will continue to improve in stability, performance, and features. It should survive and prosper for another 5-10 years. Apple has concrete plans and schedules for at least the next four major Mac OS releases:
There will be separate server and workstation versions of Rhapsody, again similar to Windows NT.
In his fireside chat, Steve Jobs said that Apple's problem was bad engineering management. While Jobs is well-known for his private reality-distortion field, and I often disagree with him, on this point I think he's correct.
This problem is fixed. Apple is a very different company now. They have all new engineering management. They are very focused on their core business and they have learned how to say "no". The Apple and NeXT engineering teams are merging effectively, although there are still many rough edges and evidence of cognitive dissonance. They have made great progress despite the acquisition and restructuring. The teams only started working together on February 4, but they already have the major foundations of Rhapsody working. We saw many impressive demos at the conference, some of which I'll mention later.
For the first time in several years, I am confident that Apple will deliver on its promises, and it will deliver on-schedule.
I noticed a common reaction to the conference by many of the developers who attended. Nearly all of us came to the conference depressed, bitter, and extremely skeptical. Many people didn't bother to come at all. Attendance was down from previous years. We've all been burned too many times by promises that went unfulfilled. By the end of the conference, many of the developers I talked to felt much better. They found the technology exciting and were cautiously optimistic about the future. This was not a universal reaction by any means, just a common one. Everyone is still very cautious, and few developers have actually committed to doing any native Rhapsody development. Everyone is taking a wait-and-see attitude while they begin to play with and learn about OpenStep and continue to develop and support their Mac OS products.
Apple is no longer in the business of throwing hundreds of millions of dollars at futuristic projects to completely change the way we do computing - projects which inevitably end up being over-engineered, huge consumers of hardware resources, inoperable with the standards used by the rest of the industry, slow, buggy, impossible to program, difficult to use, and late or never delivered at all. As Jobs said in his chat, "we put a gun to their heads and shot them dead". (I'm paraphrasing Jobs here, but he said something close to that - it was equally brutal, anyway.) Say good-bye to PowerTalk, OpenDoc, Copland, and their ilk. Good riddance, I say.
Apple is, however, still in the business of producing best-of-class hardware and operating system software which are significantly better than that offered by their competition, relying heavily on industry standards and proven technology, with innovation where it is reasonable, feasible, and appropriate.
Apple's business problems are serious. They must somehow manage to overcome the downward spiral of bad sales and declining market share leading to negative public perceptions and bad press leading to more bad sales, perceptions and press, etc. Steve Jobs says the press is not to blame for this, and that if Apple can get its engineering and business acts together, the press will take care of itself. I agree.
Apple must return to profitability soon. Gil Amelio, Apple's chairman and CEO, predicted a profit in Apple's next fiscal quarter (ending in September). He also mentioned that Apple has $1.4 billion in cash, so that it can afford to ride out a few more bad quarters, but it's clear that Apple simply cannot continue to lose money. They must start showing a profit, and they must do this soon.
Apple must find a solution to the problem of clone-makers cannibalizing their profits. Jobs recommended that Apple freely license everything, hardware and software, but adjust its fees to make them more "fair". Jobs also pointed out repeatedly that he doesn't make decisions, and this is not Apple's current policy. I confess to total ignorance of these business matters, but some kind of solution must be found for both Apple and the clone-makers to prosper.
Finally, Apple must do a much better job of delivering its new products to customers. There is demand for Macintoshes, but Apple continues to do a terrible job of producing and delivering them. They must solve their manufacturing and operational problems.
Apple has had some very strong new product introductions this year, including fast new price-competitive desktop models and very impressive and popular new PowerBook models. These new hardware products have received generally favorable reviews in the press.
Apple's advertising has improved, in my opinion, although Jobs disagrees.
Some of the press reports on the conference have been quite positive. In particular, there was a nice piece in the San Jose Mercury News, which is generally quite negative about Apple.
Dataquest has predicted an "upgrade windfall" for Apple this Fall. Other industry analysts have also predicted better financial performance in the coming quarters.
Let's all hope for the best!
Please see the first architecture diagram, which shows the major components of Rhapsody and how they fit together. We'll discuss in some detail each of the boxes in the diagram. You might like to open the diagram in a separate window or print a copy of it so that you can refer to it as you read the information below.
Apple removed the low-level parts of the Mac OS and replaced them with a new "abstraction layer" which completely isolates the blue box from the yellow box, the core OS, and the hardware.
While the core OS engineering team worked on getting the Mach kernel running on PowerPC hardware, the blue team worked simultaneously getting the blue box working on top of the old "NuKernel" microkernel from Copland. When the core team got Mach running, the blue team slid out NuKernel and replaced it with Mach.
There was a blue box compatibility lab at the conference running the NuKernel version. The Mach version was completed shortly before the conference started, and it was used in the demos, but it wasn't quite stable enough for use in the lab. In both the lab and in the demos, the version of Mac OS used was the latest Tempo beta 3 version.
The blue box is very impressive, especially the fact that they've got it working so well in such a short period of time. It provides excellent application and extension compatibility. Over 400 pieces of software were tested at the conference, and only four of them failed! Even Steve Jasik's low-level debugger worked!
I tested my software, and I'm happy to report that the Disinfectant application, the Disinfectant INIT, and the non-networking parts of NewsWatcher all work fine. (We didn't have an Internet connection in the lab, so I wasn't able to test NewsWatcher's networking parts.) It would have been inappropriate for me to conduct live virus tests in the lab, but I'm confident that the current crop of Mac viruses which work on System 7 and 8 will also continue to work just fine and spread quite happily in blue. This is perhaps not such good news, but it does provide more evidence of the high level of compatibility provided in the blue box.
In the demos we saw Photoshop, Marathon, QuickTime, and CodeWarrior all working in the blue box running on Mach.
Blue provides much better compatibility than Copland. For example, almost all extensions work fine in blue. Copland would have broken all extensions.
Playing with blue in the lab was actually quite boring, since it was almost indistinguishable from a plain Mac running Tempo. That's the whole point, but it was still boring!
In terms of compatibility for old Mac OS software, the transition from Mac OS to Rhapsody should be very similar to the very successful transition from 68K to PowerPC several years ago. Most software will "just work". There will be a few problems and exceptions, but they should be minor.
The only old software which will break under blue are programs which talk directly to hardware without going though the Device Manager, some kinds of extensions which patch File Manager traps and expect to be able to intercept all file system I/O (yellow box file I/O to shared disk volumes will not be intercepted by these kinds of blue box patches), and any other software that modifies or relies on the internals of shared system services.
Blue is not an emulator of any kind. It is mostly an exact copy of today's Mac OS, bug-for-bug, feature-for-feature, just rehosted on the new core OS. Most programs should run just as fast as they do on Mac OS, or perhaps only a little bit slower. Some operations will even run faster, due to performance improvements in the core OS.
Blue is very similar to MAE (the "Macintosh Application Environment"), an Apple product which lets you run Mac software on UNIX systems. Blue is simpler than MAE because it does not require a PowerPC emulator.
Blue uses a RAM-based ROM image. There's no hardware ROM.
There is no preemptive multitasking or protected memory inside the blue box. A blue application that crashes can still take down the entire blue box, just like an errant application on Mac OS can take down the entire Mac. An errant blue application, however, cannot crash the core OS or yellow box. In Rhapsody, if a blue crash occurs, you can easily and quickly reboot just the blue box, without having to restart the entire computer.
To the Mac OS running inside blue, it appears as if virtual memory is turned off on a Mac with 1 gigabyte of memory! The core OS does virtual memory operations behind the scenes, but this is mostly transparent to the blue box. There are two important benefits of this new scheme:
Several people asked about the following obvious idea: How about having multiple blue boxes? This would give some of the benefits of preemptive multitasking and protected memory to Mac OS programs. Apple's answer is that there are problems that would have to be solved. For example, each copy of the blue box expects to have exclusive write access to desktop database files. Also, the memory footprint would be rather outrageous. While it might be possible to do this in the future, it is unlikely that this feature will be included in the Unified release.
In summary, the blue box provides excellent compatibility for Mac OS software, comparable performance to the regular Mac OS, even better performance in some cases, and somewhat better stability.
OpenStep is a second generation object-oriented system. It's advanced, mature, and very rich. It has three components:
As an example of OpenStep's richness, I'll compare the Mac OS "styled TextEdit" package to OpenStep's text object. Styled TextEdit is used on the Mac to display and manipulate wrapped paragraphs of text. It can handle fonts and styles, but is limited to a maximum of 32K of text. In conjunction with WorldScript, it can be coerced into doing non-US English and non-Roman languages. It was originally designed for simple small text entry fields in dialogs, but has been extended by Apple and abused by programmers for more complicated uses for years. It is a nightmarish labyrinth of complexity for programmers, with hacks layered on hacks layered on hacks. NeXT's text object is much richer and much, much easier to work with. It supports tabs, rulers, kerning, the Unicode character set, and has no restrictions on size.
One of the most impressive demos at the conference involved an extension of the text object (a subclass) which does HTML. This new HTML-aware class will be part of the yellow box version of OpenStep. The object was used to build a fully functional web browser in Interface Builder in only a few minutes, without having to write a single line of code! The browser had a text field where you could type URLs, forward and backward arrows for navigation, and the usual large scrolling field to display the web page.
Steve Jobs has a favorite story about OpenStep which he repeated in his fireside chat. I'll paraphrase it here. Software development is about managing complexity. We build our software in layers that become increasingly complex as layers are added. Experience shows that we can only build about four layers high before the complexity becomes overwhelming and our programs collapse of their own weight. As analyzed in the well-known book "The Mythical Man-Month", adding more programmers to such a complex project actually hurts more than it helps. The human mind just doesn't seem capable of building higher than about four layers of complexity. Jobs likes to compare this to constructing a building. With other systems, enough foundation is provided by the system so that it is like starting your building at the fourth floor. By adding your own four floors (layers of complexity), you can build up to an eight story building. Because OpenStep, the Objective-C programming language, and the NeXT development tools are so rich, with OpenStep you start at the 23rd floor, and can thus build a 27 story skyscraper!
This Jobs story is typically extreme. In particular, it begs the question of how the NeXT engineers managed to build this system foundation with 23 layers of complexity, if the rest of us mortal programmers can only manage four of them! There is, however, a serious element of truth in this story. OpenStep is indeed superior to the competition, and it does significantly improve productivity and the "height" of the software we can produce. Every programmer I've met who has used OpenStep has confirmed that they are much more productive using OpenStep than with any other environment. Many of them have used other current popular industry object frameworks like Apple's MacApp, Metrowerk's PowerPlant, and Microsoft's MFC. The unanimous opinion is that OpenStep is much better than any of them. I look forward to finding out for myself!
In addition to its OpenStep foundation, the yellow box includes the following advanced technologies from NeXT:
There will even be two Finders, one for blue (the Tempo version of the Mac OS Finder), and one for yellow (the new Rhapsody Finder)!
The blue box can run in full-screen mode or inside a yellow window. You cannot mix blue and yellow windows together on top of each other on the same shared screen in the same way you do when you are running with a single operating system.
Full-screen mode is the fastest and most compatible. There will be a hot key to switch between blue and yellow in this mode. The yellow box will be invisible in this mode, except for a command in the Process menu to switch from blue to yellow. When you select this command or use the hot key, all the blue windows will disappear (including the blue Finder), and all the yellow windows will appear (including the yellow Finder). The user experience in this mode is definitely one of switching between two completely separate systems.
By "full-screen" here, I mean all the monitors combined (the "virtual" screen). So in full-screen mode, the blue box takes over all of the monitors. (By the way, both blue and yellow will be able to handle multiple monitors in the same way as today's Mac OS.)
Drag and drop works within the blue box, and within the yellow box, but not between the two boxes. For example, when using blue inside a yellow window, if you try to drag something out of the blue window and into the yellow part of the screen, the dragged object will be pinned to the edge of the blue window.
This lack of tight integration between blue and yellow is unfortunate. Everyone hated this when they first started to hear about it. It was a hot topic at the conference. There was also a great deal of debate about this within Apple. My impression is that this is the most contentious design issue in the entire Rhapsody project.
There is no ideal solution. Apple made a tough call. The decision to keep the two environments clearly separated was made for human interface reasons, for technical reasons, and for time-to-market reasons.
Kurt Piersol, a long-time Apple human interface guru, tried to explain this decision in some detail in his session on "The Rhapsody User Experience". I'll try to reproduce his arguments here. Piersol also said that all of these issues are subject to further examination and modification based on user testing in Apple's human interface labs. Piersol and other speakers also mentioned that the integration will improve as Rhapsody matures after the Unified release.
The basic problem is that the two environments are quite different, in both obvious and subtle ways. One of the basic principles of human interface design is to avoid hidden modes. If you can't provide seamless integration of two modes, make the mode switch obvious. Other basic rules to keep in mind are: Don't change modes unexpectedly, don't try to hide differences that make a difference, and don't make the user guess what changed.
Here's some examples of human interface problems that would arise if Rhapsody tried to hide the distinction between blue and yellow programs:
Here's some examples of the technical integration problems:
In summary, there are four main reasons for not attempting to tightly integrate the blue and yellow boxes:
After listening to Piersol explain all of these problems, I reluctantly agreed with him that the weak integration of blue and yellow is a necessary evil. After thinking about it, I don't think it will be all that bad.
While the blue and yellow halves of Rhapsody are mostly separate, they do share some significant resources:
Rhapsody will support dual boot. At startup time, you can choose between running Rhapsody or the classic Mac OS.
Rhapsody will have the familiar Mac menu bar across the top of the screen. When we saw the first demo with a menu bar at the conference, the audience cheered loudly and let out a collective sigh of relief - Yes, it WILL be a Mac! Most NeXT users think this is a terrible travesty because NeXT-style menus are clearly superior, in their opinion. A very large flame war has errupted over this issue and similar user interface issues on Usenet. I'm trying to stay out of the debate.
Rhapsody will let you drag icons to the desktop, just like the Mac OS. The NeXT dock will become superfluous for this reason and will probably be eliminated.
Rhapsody will use Mac-style windows and controls, using the new appearance of Tempo.
Rhapsody will have aliases.
Kurt Piersol promised full plug-and-play in Rhapsody! Apple has to deliver on this promise.
In Finder list views, the columns can be resized and reordered.
Enhancements borrowed from the NeXT human interface include improved scroll bars with proportional thumbs and rearranged scrolling arrows, live scrolling, live window dragging, and the ability to resize windows from any corner or side.
A NeXT-style "browser" Finder window view will be added to complement the Mac icon and list views. It will include the NeXT multiple panes and "shelf".
Rhapsody will use Mac-style 32x32 large icons, not the larger NeXT 48x48 icons.
The Finder in Rhapsody will be extensible and replaceable. It will be just another application in the yellow box, not as much an integral part of the system as is the Mac OS Finder. It will support plug-ins. The icon, list, and browser views will be standard views other programs can use to display and permit manipulation of their own collections of hierarchical data.
Rhapsody will retain the Mac OS type and creator experience. However, some file systems can't support this (e.g., NFS). In these cases, file name extensions (.txt, .html, etc.) will be used as a fall-back.
We'll be able to put applications anywhere we wish in a file system, as in the Mac OS. We won't be resticted to special directories as in the current NeXT OS.
Rhapsody's help system will be based on HTML. Help text can contain links to Internet-based help and other sources. The system will have powerful navigation with both linking and searching facilities. Apple also plans some kind of extension for task-based help. This help system will not be the same as the Mac OS balloon help and Apple Guide, but it will be similar and serve the same purpose.
Rhapsody will have Internet integration. It will support desktop URLs and Internet data types as first-class citizens. The text object will be extended to handle HTML (as I mentioned earlier).
Rhapsody will have a new installer system which will include built-in uninstall and upgrader features.
Rhapsody can be set up as a multi-user system. In this case, each user will have his own desktop, preferences, etc., similar to Windows NT (but much better than NT, I hope).
I have one huge concern about this "advanced Mac look and feel" sitting on top of the NeXT-based system foundation. Can Apple really hide the UNIX? There's something called the "Mom test" in the Apple world (like the Turing test in AI). The basic question is: "Could my Mom use this computer? Could she set it up out of the box, learn it and use it, install new hardware and software, troubleshoot problems, and keep it running all by herself?". This is the acid test Apple must pass with Rhapsody.
I may be hopelessly naive and nostalgic, but I still believe in the dream of the Macintosh as the "computer for the rest of us". This is a political dream. Originally it was about unleashing the power of computing from the control of the corporate MIS priesthood (people like me) and giving it to ordinary people (like my Mom). That's what the "personal computer revolution" was all about. That's especially what Steve Jobs, Steve Wosniak, and Apple were all about in the early days of the Apple II and the Macintosh. That's what the "Mom test" is all about.
Today's systems are horribly complicated. This includes Mac OS, which in my opinion stopped being a system for "the rest of us" somewhere in the late 80s or early 90s (although it's still much better than the competition, especially Windows). We've let our insatiable appetite for more power and more features kill the dream. None of today's systems even come close to passing the Mom test.
I see unmanageable complexity in our operating systems as being the single biggest problem in the computer industry today. This isn't idle utopian dreaming. It's a real and immediate problem I see in my work every day. Rhapsody has to address this problem.
Steve Jobs, Larry Ellison, and other major industry potentates agree with me about how OS complexity is the industry's current biggest problem. They use the complexity problem as an argument in favor of "thin clients" and "network PCs". Their basic argument is that the complexity is unavoidable, and the solution is to move the complexity out of the client, over the network, and onto high-end servers managed by professionals. Jobs talked in his chat about how Apple should be working on developing this kind of product. He bragged about how he has a T1 line to his house and uses it to mount his file system at work using NFS, with a staff of UNIX geeks paid to keep it all running for him. For Jobs, this is the model of how computing should and will be done in the future. It's an interesting argument, and quite fashionable. I understand its attraction, and I'm definitely a fan of distributed file systems, but I don't buy it. It's a return to the old MIS priesthood mainframe days in a new guise. We can do better than this. Rhapsody must do better than this.
I'm not ready to give up on the dream of a modern personal computer operating system with preemptive multitasking, protected memory, object technologies, and all that other great computer science stuff which we desperately need to get the kind of performance, stability, and features we require, but which still passes the Mom test. I don't believe that these are inherently incompatible goals. I'd like to think of Rhapsody as a step towards realizing this dream.
I don't object to Apple's plan to initially target Rhapsody as a system for servers and high-end enterprise users, and I'm willing to live with a modest amount of exposed complexity and a few rough edges in the Unified release. In the long term, however, I think Rhapsody must become a system for everyone. Moms need the benefits of a modern OS just as much as enterprise users do, even more so when it comes to the stability aspects of a modern OS. The challenge for Apple over the next several years is to make this possible.
Since I first published this report, I have corresponded with many NeXT users who have tried to reassure me that NeXT has already done a terrific job of "hiding UNIX". In particular, Joshua Burton, a visiting scholar here at Northwestern and a long-time NeXT user, has very kindly spent a great deal of time teaching me about how NeXT has dealt with this problem. I'm particularly impressed by how NeXT has managed to deal with the horrible complexities of the UNIX multi-user system and the goofy file and directory permissions. For example, by default, the NeXT OS installs as a simple single-user system. You don't have to log in with a username and password, and you don't have to worry about file system protection, root privileges, or any of the other UNIX complexities. I'm far from having a complete understanding of how this works, but it looks very promising.
After talking to Joshua and others, I feel more confident and reassured, but I hope they will forgive me if I remain a little bit skeptical and still concerned about the problem.
I'm a bit comforted to know that the right people are working on this problem (like Kurt Piersol). After all, Apple and NeXT are the only companies in the industry who have even attempted to seriously deal with the problem. If anyone can pull this off, Apple/NeXT can.
Rhapsody will support Sun's "100% Pure Java". This includes compilers, bytecode interpreters (including JITs), the abstract windowing toolkit (AWT) and all three of the new "foundation classes" under development in the industry: Sun's JFC (Java Foundation Classes), Netscape's IFC (Internet Foundation Classes), and Microsoft's AFC (Application Foundation Classes). There will even be support for the new "Kentucky Foundation Classes" (KFC). (That last one's a joke - feel free to moan.)
One of the most interesting presentations at the conference was titled "The Uncommon Object Model - The Rhapsody Runtime". It turns out that the Java runtime environment and the NeXT Objective-C runtime environment in Rhapsody share many attributes. They both use dynamic method dispatch, single inheritance of implementation, multiple inheritance of abstraction, introspection, exceptions, and garbage collection. Both systems include frameworks with collection classes, Unicode strings, OS abstractions, a distribution model, and a persistence model. This similarity is not entirely a coincidence, since Java has parts of its roots in NeXT Objective-C technology, and both share a common inheritance of concepts from the SmallTalk world.
Because of these similarities, and because of the perceived strategic importance of Java, Apple decided to tightly integrate the existing NeXT Objective-C runtime model and the Java runtime model. The match between the models isn't perfect, but it works very well. A Java/Objective-C runtime "bridge" handles messaging across the boundary between the two environments. The bridge maps Java packages into Objective-C frameworks. The bridge also maps classes, scalars, exceptions, and objects.
Java has "true" garbage collection, while OpenStep uses a semiautomatic garbage collection system involving reference counters and "auto-release pools". This OpenStep garbage collection feature is provided by the Foundation Kit classes, not by NeXT's version of the Objective-C language. The bridge takes care of the details of making these two systems interoperate properly.
This runtime bridge permits programmers to mix and match Java code and Objective-C code freely. You can even subclass an Objective-C class in Java! (Apple is working on the other direction too.)
The entire OpenStep API will be exposed to Java. Java programs can take full advantage of the services of OpenStep. If they do, they won't be "100% pure" anymore, but there are many advantages to using the rich services of OpenStep instead of the AWT and various xFCs.
The NeXT "Project Builder" and "Interface Builder" development tools will support Java. Java Beans will be first-class components in this environment. For example, you can place a Java Bean component on your Interface Builder palette, then use it in your Objective-C and Java applications as if it were a regular Objective-C palette object.
We saw a demo of a Java application built with Interface Builder and Project Builder which used OpenStep's Application Kit and Foundation Kit. This stuff actually works!
Apple is working closely with Sun on Java development. They promise simultaneous releases with Sun of new Java versions in Rhapsody. It's much easier to do this in Rhapsody than it is in Mac OS, because Sun's Java releases are based on UNIX, and Rhapsody includes a standard UNIX environment to make porting such code relatively painless. For example, it took Apple less than two weeks to port JavaSoft's recent version 1.1 Java virtual machine to Rhapsody.
Rhapsody uses the Mach 2.5 kernel with enhancements. This is often referred to as a "microkernel", but that's technically incorrect. Mach 3.0 is a "true microkernel", but Mach 2.5 is actually a "monolithic kernel". I try to just call it a "kernel".
Mach is a modern, small (30K lines of code), proven kernel that is used in several current commercial operating systems.
Avie Tevanian was one of the designers of Mach at Carnegie Mellon in the 1980's.
Mach 2.5 provides the usual full set of kernel services:
The enhancements to Mach 2.5 for Rhapsody include symmetric multiprocessing and power management (for PowerBooks).
The blue box runs as a single preemptively scheduled Mach process within a single shared memory address space. Within the blue box, the traditional Mac OS Process Manager does the usual cooperative multitasking between blue applications.
In addition to HFS and HFS Plus, Apple will also support at least the following file systems in Rhapsody: UDF (the format used by the new DVD disks), UFS (UNIX file system), NFS (network file system), AFP (AppleShare), FAT and VFAT/FAT32 (Wintel file systems), and ISO/9660 (for CD-ROM disks).
File systems are implemented in Rhapsody using an abstraction named "virtual file system layer" (VFS), a standard part of BSD 4.4 UNIX. VFS includes the notion of "stacked" file systems, which can be used to implement compression, encryption, and virus checking software. This mechanism replaces the old Mac OS technique of patching file system traps.
For servers, Rhapsody will also support spanning, striping, and mirroring for disk management, performance and reliability.
File names will be case-insensitive.
In the blue box, there are three ways file systems can be mounted:
Some Mac users have expressed concern about the lack of resources in OpenStep. Don't worry. OpenStep has something even better called "nib files". These files are built with Interface Builder, the NeXT tool which corresponds to ResEdit in the Mac OS. Nib files contain archived user interface objects, target/action connections, and other object relationships. OpenStep's "NSBundle" class implements the notion of a "group of application objects" and offers facilities akin to the Resource Manager in Mac OS.
Nib files, application binary files, and other files used by a program (e.g., picture files) are gathered together in an "application wrapper", a directory that appears to the user as if it were a single file. This is quite different from how application packaging is done in Mac OS, but it accomplishes the same goal, and it's considerably more flexible.
Rhapsody may support Novell and Windows NT networking, but the plans are not firm and we don't have any promises.
Rhapsody will support 10 and 100 megabit per second Ethernet and PPP. FDDI will be supported soon. LocalTalk support is planned, but no date has been set for support yet. There's no token ring or ATM support yet, and the plans for these media are not yet firm.
The blue and yellow protocol stacks are completely separate and operate in parallel. They meet at the device driver layer. The device driver is responsible for demultiplexing incoming IP packets and sending them to either the blue stack or the yellow stack based on the port number in the packet. There was some confusion in the Rhapsody networking session about what happens with ICMP packets, which do not have a port number.
The blue and yellow boxes share a common IP address, although at one presentation there was an indication that there may be an option to use two separate IP addresses. This isn't clear. Yellow can have additional IP addresses.
The blue and yellow boxes have separate AppleTalk node numbers. It's not clear that this is workable in many environments, however, and Apple may have to rethink this decision.
TCP/IP in the yellow box supports IP routing, multicast, multihoming, IP aliasing, and raw sockets. Yellow AppleTalk is high performance, multiprocessing efficient, and supports RTMP and AURP.
Networking services include bind and NFS. Netinfo is used for network management (a NeXT system which is similar to NIS).
Kurt Piersol said that the yellow box will not use the Chooser, but he did not say what will replace it.
In a feedback session, Apple promised that we will be able to change network configurations without rebooting, using a friendly "Macish" user interface.
Networking is clearly one area where Apple needs to do more planning and work. There has been quite a bit of controversy over the decision to drop Open Transport in favor of BSD 4.4 sockets in the yellow box, but at least as of the WWDC it looks like Apple's engineering management is sticking to its guns and going with sockets. This was a very frequently asked question at the conference, and the subject of much debate. Amelio recently stated in an interview that the decision to drop Open Transport was being reconsidered based on feedback from customers and developers, but there was no evidence of this at the conference.
I'm an agnostic in the great streams (OT) vs. sockets holy war. I'm much more concerned about having stable and fast networking in Rhapsody with support for all of the major protocols, network file systems, and network printing systems. As a programmer, I'm very concerned about the proliferation of networking APIs, especially for cross-platform development. OpenStep definitely needs a network abstraction layer so that developers can code to a single networking API for all platforms. We need this for TCP/IP at the very least. XTI or a similar API for transport independence would be desirable but not essential.
All of the major UNIX utilities, servers, and applications have already been ported to BSD UNIX and will run without change in Rhapsody. One serious concern is the well-known security holes in these programs, especially in servers like sendmail.
It will be easy to port other UNIX programs to Rhapsody.
Note that BSD UNIX is not depicted in a box in the Apple Rhapsody architecture diagram! This was most likely a wise marketing decision (we don't want to scare the users, you know!).
Some people have questioned the wisdom of this cross-platform strategy, expecially the Rhapsody for Intel product. Why buy an Apple PowerPC hardware product when you can run Rhapsody on a cheap Intel box? One clear advantage of Rhapsody for PowerPC is the blue box for running Mac OS software. It also seems very clear to me that Rhapsody for Intel will never have the same kind of plug-and-play benefits or the same level of hardware and software integration as Rhapsody for PowerPC. In his keynote speech, John Rubenstein, Apple's VP of harware engineering, said that Apple's strength is its ability to unify hardware and software. He said that Apple is a systems company, not a hardware company or a software company. I think this is the primary reason Rhapsody for PowerPC will be more attractive then Rhapsody for Intel.
Using a technique my friend Leonard Rosenthol has dubbed "obese binaries", it is even possible to ship a single properly packaged application which can run on all the target platforms. Basically, all you have to do is recompile your program multiple times.
If you use Java to write your OpenStep application, you don't even have to recompile!
With Rhapsody we get three complete and mature operating systems in one package: Mac OS, OpenStep, and UNIX. We get close to 100% compatibility for old Mac programs. We get the best Java platform on the planet. We get a superior object-oriented environment for rapid application development. We get great tools for enterprise computing, distributed computing, and web development. We get an exciting cross-platform strategy.
In our higher education environment here at Northwestern, I think Rhapsody would be a first-class platform for every kind of computing we do: