Subject: Rhapsody Report
Date: Tue, 3 Jun 97 11:52:17 -0400
From: "Steve M. Chazin" <chazin@apple.com>
To: Folks,
This is the most detailed Rhapsody report I've ever seen and it comes from folks in academe. If you don't want to read all of it...I did but now my eyes are tired...just skip to the last paragraph. I know it creates as many questions as answers but this is good. Enjoy. Oh yeah, go get yourself a cup of coffee or a coke and send me the bill. :)
Steve
Hi.
Yesterday a friend of mine pointed me to John Norstad's report on theWWDC Rhapsody tracks at
http://charlotte.acns.nwu.edu/jln/wwdc97.html
--Eric
Last week, I attended Apple's annual Worldwide Developers Conference (WWDC) in San Jose, California. This is a report on my trip. I concentrated exclusively on the Rhapsody track. Rhapsody is Apple's next-generation operating system combining Apple and NeXT technologies.
I skipped the other four tracks on Mac OS, Interactive Media, Internet and Web Technologies, and Hardware. So this talk is almost entirely about Rhapsody.
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. Dual OS Strategy and Delivery Schedules
Apple is committed to parallel development of Mac OS and Rhapsody for the foreseeable future. This strategy permits customers to migrate to Rhapsody at their own speed.
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:
Rhapsody represents the future, however, and that's what I'd like to talk about tonight. The schedule for Rhapsody is:
We all know that Apple has had a very rough time the last few years. Everyone is concerned. I'd like to briefly give my perspective on these problems, cast in the form of a "good news, bad news, good news" story.
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 some 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 incredibly over-engineered, huge consumers of hardware resources, completely 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 is 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. Bad news: Apple is dying
Apple's business problems are serious. They must somehow manage to overcome the downward spiral of bad press leading to negative public perceptions leading to poor sales leading to more bad press and perceptions and sales, etc.
Apple must return to profitability soon. Amelio 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. Good news: There are signs of a resurrection
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!
In this section, the heart of my presentation, I'll give a reasonably detailed overview of Rhapsody's architecture. We got lots of new information at the Rhapsody technical sessions which I'd like to share with you.
Please see architecture diagram #1, 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.
The blue box is the classic Mac OS rehosted on the new Rhapsody core OS. The blue box makes it possible to run the vast majority of existing Mac OS software on Rhapsody.
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 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:
The blue box will also provide improved stability via "guard pages". These are special virtual memory pages which are marked read-only and are placed at the beginning and end of each program's stack and heap. In the regular Mac OS, programs sometimes "run off the end" of their stack or heap when writing memory, and end up trashing memory belonging to the system or other programs. This often causes bad crashes. In blue, such a misbehaving program will crash, but it won't take down other programs or the whole blue box along with it.
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.
The yellow box is a major component of Apple's new operating system. It is based on OpenStep technology from NeXT.
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, but there's a serious element of truth here. 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
Applications running in the yellow box enjoy the full benefits of all the services provided by the Mach kernel, including preemptive multitasking and protected memory. We'll talk about this more later when we go into more detail about the core OS.
The user experience in Rhapsody is that of using two almost completely separate computers. The blue and yellow environments are quite clearly separated and only share a few well-defined resources. 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 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.
The human interface of Rhapsody will be based primarily on the Mac human interface, with new ideas incorporated from the NeXT human interface. Contrast this to the internal "guts" of Rhapsody, the yellow box and the core OS, where the situation is the opposite: the foundation is NeXT technology, with additional elements incorporated from Apple technology.
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!
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". For those of you not familiar with the NeXT browser, this is somewhat similar to the Microsoft Windows "Explorer".
Rhapsody will use Mac-style 32x32 large icons, not the huge NeXT 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.
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.
I have one huge concern about this "advanced Mac look and feel" sitting on top of the NeXT-based system foundation. Can Apple hide the UNIX? They must do a better job than X-Windows, Be, or even NeXT. 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, install software, learn it and use it, troubleshoot problems, and keep it running all by herself?". This is the acid test Apple must pass with Rhapsody. For example, Rhapsody's multi-user features are based on UNIX. How is Apple going to deal with the complexities of the goofy UNIX file permissions? I don't know how your Mom would deal with this, but I know mine wouldn't stand a chance.
I see this as the single biggest challenge in making Rhapsody a success. I'm a bit comforted to know that the right people are working on this problem (like Kurt Piersol). If anyone can pull this off, Apple can.
Rhapsody will have superb support for Java. Apple has decided that Java is a very important part of their future and has devoted significant resources to integrating it into Rhapsody. In his keynote speech, Avie Tevanian said that "Java is Apple's biggest opportunity." I found the Java information to be some of the most interesting and pleasantly surprising news to come out of the conference.
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 mature 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 Objective-C uses a semiautomatic garbage collection system involving reference counters and "auto-release pools". 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. Core OS
The core OS includes the Mach kernel, I/O services, file systems, and networking protocol stacks.
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 modern commercial operating systems.
Avie Tevanian, the senior vice president of system software at Apple, 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.
The core OS device drivers run in the kernel's address space and provide I/O services to both the blue and yellow boxes. They support true plug-and-play, have integrated power management, can be loaded and unloaded dynamically, and are modular and extensible. They are programmed using object-oriented techniques in Objective-C or C++ using the I/O Kit. Writing drivers is fairly easy. For example, Martin Minow of Apple reported that it only took him about three weeks to port the Copland SCSI driver to Rhapsody. He says that "it's easier than you think to write drivers."
Apple is working on an enhancement to the current Mac OS "HFS" file system named "HFS Plus". This new file system will be released as part of Mac OS in a maintenance update later this year (after Tempo), and it will also be part of Rhapsody. HFS Plus fixes the small allocation block size problem, so small files will no longer waste such large amounts of space as in HFS. HFS Plus also removes the limits on the number of files per volume and the sizes of files. It also uses 255 character Unicode file names. HFS Plus will be the default disk format for both blue and yellow.
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:
Yellow files do not have resource forks, but blue files do. To solve this problem on shared volumes, Apple has decided to use the AppleDouble format. The resource fork and Finder metadata (type/creator, icon position, etc.) are stored in a separate file with a tilde in front of the file name. These extra files are invisible in the yellow box, and are automatically copied and moved along with their partners.
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. 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 the Mac OS, but it accomplishes the same goal, and it's considerably more flexible and easy to work with. Networking
Rhapsody will support at least the TCP/IP and AppleTalk protocols in both the blue and yellow boxes. The blue box will use Open Transport for both TCP/IP and AppleTalk. The yellow box will use BSD 4.4 sockets for TCP/IP and a port of the AIX Workgroup Server AppleTalk stack for AppleTalk.
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 packets and sending them to either the blue stack or the yellow stack based on the port number in the packet.
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 the existing BSD 4.4 sockets implementation of TCP/IP 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. UNIX
Rhapsody will ship with a full BSD 4.4 UNIX distribution as an optional-install item. This includes the usual BSD command line shells, utilities, POSIX libraries, programming tools, and other UNIX amenities. They will even ship the Apache web server! 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!).
Apple has a cross-platform strategy as part of the Rhapsody product plans. While some of this information was available before the conference, much of it was new, and this was the first time we saw a complete view of the cross-platform picture. I think it's quite interesting.
So far we have discussed just one of the Rhapsody products - Rhapsody for Power Macintosh and PowerPC Platform hardware. This is the "next-generation Macintosh", if you will. Now it is time to discuss the other four products which make up the cross-platform plan. Please turn once again to the architecture diagrams.
With this cross-platform strategy, software developers who use OpenStep and don't use any platform-specific features can write their programs once and deploy them everywhere, on 100% of the modern PC market! (We're defining "modern" here to exclude Windows 3.1 PCs and 68K Macs). This target market for these "pure" OpenStep applications includes Windows 95, Windows NT, Mac OS, and Rhapsody users. That's a big market! 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!
Comparison to the Cross-Platform Alternatives
I think that OpenStep is superior to the current major alternatives for cross-platform development, although 100% pure Java is a serious contender.
100% pure Java is certainly the closest reasonable competitor to OpenStep for cross-platform development. Mac developers are busy making the difficult decision between these two directions as we speak!
Rhapsody has the potential to be a superb system which leapfrogs the competition. If Apple delivers this system on-time and executes it well, and manages to solve the very difficult problem of passing the "Mom test", I think the result will make today's Mac and Windows PCs look like toys.
With Rhapsody we get three complete and mature operating systems in one package: Mac OS, Rhapsody, 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 development environment for rapid application 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:
I'm excited about Rhapsody, more excited than I've been about any Apple technology in years, and I hope you are too.
(Q&A)