Volume Number: 13 (1997)
Issue Number: 7
Column Tag: Rhapsody

Rhapsody FAQ's

by Michael Rutman, independent consultant

You've heard the rumors, but how much is true?

With today's ever changing technology, finding out information about future technologies can be challenging, especially when it is difficult to get hands-on experience with that technology. Rhapsody is no exception. Even though Rhapsody is based on OPENSTEP, which has been out for almost a decade, most developers have not had a chance to play with it themselves.

Most developers rely on word of mouth and trade magazines for obtaining their information. While trade magazines are great for getting facts, word of mouth is what most people rely on. Unfortunately, word of mouth isn't always as reliable as one would hope.

After seeing these technologies in action at WWDC and talking with Apple engineers and Evangelists, many of the rumors are clearly wrong. In this article, I hope to cover popular rumors and debunk them one by one.

Display Postscript is slow

OPENSTEP uses the Display Postscript model for all drawing. This allows true WYSIWIG and easy printing code. OK, sounds good, but aren't there downsides? Isn't my Postscript LaserWriter very slow?

Yes, Postscript used to be very slow, but was so powerful it was worth the wait. Waiting for a high quality printout is not as painful as waiting for the screen to update. When NeXT decided to use PostScript for their screen display, Adobe and NeXT realized they would need to improve PostScript's speed. The optimizations they implemented included using integer font metrics for screen fonts, lazy depth promotions, compression of the backing store of a window, better algorithms for color conversion and dithering, file mapping, and many more.

So, did this work? In a nutshell, yes, it worked very well. As Apple is proud of saying, Display Postscript is 266 times as fast as the LaserWriter NT. So, if you believe Apple statistics, and if your LaserWriter NT can do 16 pages a minute, then you should be able to do 71 frames a second, which is as fast as the monitor can display anyway. It is nice what you can do with statistics, but how does it feel?

To prove that Display PostScript is quite nice, Apple put up two windows running different QuickTime movies with a lot of motion. During their live demo, they dragged the windows around the screen overlapping the two windows; the audience saw perfect clipping, no stutter, no delays. The QuickTime movies continued playing as they were dragged. Most Macintosh users are used to dragging an outline of a window instead of a window. MacOS drags outlines for speed. Under Rhapsody, Display Postscript is fast enough to continue displaying QuickTime movies while being dragged.

Seeing is believing, and I saw Display Postscript displaying a lot of nice graphics very quickly.

I need to know postscript to program under Rhapsody

Rhapsody draws in PostScript, and knowing PostScript would be useful. However, there is a difference between it being a good idea to know PostScript and having to know PostScript.

The vast majority of PostScript is hidden from the developer. OPENSTEP's framework, called the AppKit, handles all the setup PostScript needs for drawing or printing views. A developer that wants to modify the default behavior would have to know PostScript, but the vast majority of developers will never need to do this.

The common PostScript commands - the ones for drawing lines, circles, rects, setting colors, and so on - are wrapped by C functions. Drawing a rectange is done with NXFillRect( const NXRect *). A developer need only pass a rectangle to this routine and the rectangle is drawn. Even though the low level drawing is done in PostScript, the developer need only know that there is a routine that draws a rectange. For finer control, PSsetcolor(NXColor *) sets the drawing color, PSmoveto, PSlineto, and PSStroke can do individual lines.

Almost all entities displayed, such as boxes, buttons, popups, and windows are objects that hide all of the PostScript needed for drawing. As long as standard controls are used, no PostScript need be created. Of course, if a complex PostScript entity has to be generated, the code can be written into a PSwrap and downloaded to the PostScript server. However, to do this one would have to learn PostScript. My experience is that pswraps are useful, but rarely necessary.

My mom isn't going to want to learn unix

Rhapsody is based on unix, but what does that mean? Many people believe that unix is a command line interface into a file system where you have to type grep a lot. Nobody wants to dump this on an unsuspecting user, and NeXT has worked on hiding unix for years. Now that NeXT and Apple are combined, there is a strong push to hide unix even farther.

How to hide unix has always been tricky, and early versions of NEXTSTEP didn't do a very good job of it. Because unix kept peeking up its ugly head in the early days, there is a lot of word of mouth bashing of Rhapsody, and that is unfortunate. Over the last 8 years, NeXT has done a good job of putting the unix layer well under a pleasant user experience. Everything your mom can do on the Mac can be done under Rhapsody in the same way.

OPENSTEP, however, is for both your mom and you. For power users, OPENSTEP still has a terminal window that accesses the unix layer directly, and those developers who want to can type grep to their hearts content. If they don't want unix, there are other ways to do what they want to accomplish. The unix command line is there only for the people that want it. It is important to remember the difference between having a tool available to you, versus having to use a particular tool to get your job done. Rhapsody is offering a choice.

Game developers won't be able to make their software work

Game developers program to the hardware. The life of a game is measured in months, not years, so working with the next system upgrade is a low priority, but an extra frame a second can make or break a game. To get that extra frame a second, game developers need access to the hardware, and the Rhapsody framework hides the hardware.

The Rhapsody engineers understand this problem, and they want to play games as much as the rest of us. They have placed hooks in at the lowest levels called interceptors. Interceptors allow game developers to write code that accesses the monitors at the lowest levels, completely bypassing anything that might slow down a game. Game developers that need to take over an entire monitor and blit bits around can grab the monitor through an interceptor.

It won't look like the Macintosh I've come to love

This is the opinion that is mostly contested. Rhapsody is going to look like MacOS 8, not Mac 7.5. How different are the two is still up for debate. MacOS 8 has a more "modern" look and feel, but it also is still in development as I write this article. Some have argued that the "modern" look and feel is unpleasant, but it is still being cleaned up, so it is hard to judge.

On the other hand, the Macintosh look and feel has been evolving since 1984, and current Macintoshes do not look much like they did 13 years ago. The argument that the latest system doesn't look like the Macintosh I've come to love could have been made years ago, and we would not have a lot of the little things that make the Macintosh fun. Color is a good example. When Apple added color to the Macintosh, it changed the look and feel. Most people now agree that color was a good change.

So, it won't look like the Macintosh you bought 5 years ago, then again, neither will any other Macintosh you buy next year, whether it is running Rhapsody or not.

It's not a Macintosh, no matter how much it looks like a Mac

This is an interesting argument, and it goes along the lines of: The Macintosh is what I have on my desk, and what I've learned to program. If you go to unix, and change the Toolbox, then it isn't a Macintosh. Since it won't be a Macintosh, it won't work like a Macintosh. Since the Macintosh is easy to use, and this won't be a Macintosh, it will be hard to use. Believe it or not, I've heard that argument from people that should have known better. Despite all the flaws in the argument, it's an emotional fight, and those are always tricky.

This is my feeling about whether Rhapsody will be a Macintosh. If it looks like a duck, walks like a duck and quacks like a duck, then it's a duck. In the same vein, if it looks like a Macintosh, runs my Macintosh software, and follows all the Macintosh guidelines, then it's a Macintosh.

Now, I'll be the first to admit, change is bad and should not happen, but in the computer industry, change is inevitable. The Macintosh look and feel is evolving, and those changes are going to effect us. Most of the changes to the look and feel are actually going to appear in MacOS 8, (code named Tempo) not Rhapsody.

Programming Rhapsody is so easy, we won't need programmers anymore

In a way, there is a grain of truth to not needing programmers. Traditionally, creating a user interface required code changes. Each item in each window needed hard coded locations. Changing a button title or position could require a code change and a recompile. Some dialogs could be edited with ResEdit, but ResEdit is hardly a tool for novices.

Under Rhapsody, interfaces are completely separated from the code. Editing User Interfaces is done through a program called Interface Builder. Interface Builder has a lock mode where non-programmers can safely make changes to a UI without breaking links. On many of my OPENSTEP applications, non-programmers have done the final cleaning up of my user interface files.

Separating the UI from the coding usually cuts the need for a programmer in half. This is not the same as not needing a programmer, because someone has to make the program useful. The graphic artist can then make the program usable without taking up the programmer's time. The reality is that making a software package useful as opposed to pretty, still needs a programmer.

None of my Macintosh programs are going to work under Rhapsody

Again, there is a grain of truth here, but not much more than a grain. Most code written to the Toolbox must be rewritten to take advantage of the new Rhapsody world. Even though programming for Rhapsody is easier, getting developers to rewrite hundreds of thousand of lines of code is not likely.

Transitions to a new architecture can be painful for users. Fortunately, Apple went through this when they moved from 68K machines to PowerPC. Even though few existing applications "worked" in the native PPC, the 68K emulator allowed almost all existing software to run on the PPC, even though it wasn't native. This allowed some people to upgrade, running their software without abandoning all their existing software. Today, some applications being shipped work only on PPC.

In a very similar way, Apple has provided a mode under Rhapsody that will allow users to run old applications. Currently, this is called the Blue Box, but over the next 18 months Apple marketing may decide on a more user friendly name.

The Blue Box has two modes: one puts Blue Box in a Rhapsody window, the other lets the Blue Box take over the entire display space. In the latter, the machine looks and acts like a traditional Macintosh, while Rhapsody applications continue to run underneath the UI. The user experience is almost the same as a machine running MacOS 8, but having Rhapsody underneath adds stability for Rhapsody applications.

When Blue Box is run in a Rhapsody window, all of the Blue Box applications will put their windows inside the Blue Box window. While switching between window and full screen mode is easy, the overall experience is ugly. At least it allows users to run their one or two Blue Box apps while living in a Rhapsody world.

Rhapsody does not support Undo

Undo is very difficult to implement, and many applications spend more time supporting undo than any other feature. NeXT got a bad rap because none of their existing applications support undo, and many early developers did not support undo.

One of the main reasons for the lack of undo was, ironically enough, OPENSTEP's ease of development. Using OPENSTEP, developers were able to get a large number of new features added to an application very quickly. Unfortunately, undo is still difficult. This leads to a developer not wanting to take the extra time to add undo for an action where undo can take longer to implement than the feature the developer is adding.

However, Apple recognizes that undo is very important to Macintosh users. Technology for adding undo has advanced, and adding undo is easier than it was years ago. Today, the undo architecture of Rhapsody allows a quick and easy multiple-level undo, once the developer has written undo actions for everything the user can do. Writing the individual undo actions are going to be as hard as they've always been, but that is true regardless of the platform.

I'll need to learn a new language

OPENSTEP has used Objective-C for many years, and the framework is designed for access from Objective-C. Many years ago, NeXT realized that many programmers needed to use C++, and OPENSTEP had to support C++. Unfortunately, the C++ object model and the Objective-C object model do not mesh very well, and C++ has always been a second class citizen.

The reason C++ had to take a back seat is because Objective-C allows run-time binding, and without it, C++ is just not powerful enough to fully access the AppKit without using Objective-C. NeXT provided a way of using both Objective-C and C++ in the same routines. This allows a developer to do his back end in C++ and his UI in Objective-C. Overall, developers were happy, but many complained about needing to use two different languages.

Then along came Java. Java is like C++ in syntax, but has the run-time binding that Objective-C needs. Apple found that Java's object model is very close to the Objective-C object model, and set up the Java Virtual machine to allow code written in Java to access the Objective-C framework directly. Even though the developer coding in Java is calling Objective-C objects, everything is transparent. For the Java developer, programming the AppKit is done entirely in Java. At least that's the theory, I haven't had a chance to try it myself.

Once the decision was made to allow the Java developer to access the AppKit directly, the next logical step was to make Objective-C more like Java. Having developed in Objective-C for many years, I, personally, do not see why developers would want a Java syntax, but most developers I've talked to have made it clear that they would rather use the Java syntax than the Objective-C syntax. Both are supported, so old time developers can continue to use the old syntax, and new developers only have to know the syntax of Java.

Now, the new Objective-C syntax may have a Java-like syntax, but it isn't Java. It's still Objective-C, which means you still have all the power of C. One advantage is that developers can jump between C++, Java and Objective-C as the need arrives. Taking a C++ library, hooking it up to some Java networking code, and throwing on an Objective-C interface is easy, and each language can directly access any of the others. With the new syntax for Objective-C, everything will have roughly the same look.

I'll need all new drivers for my hardware

Yes and no. One of the goals of Rhapsody is making the drivers more standard. SCSI drivers, for example, have always been a problem on the Macintosh. Personally, I have 3 different drivers for removable media, and none is compatible with any of the others. Under Rhapsody, I don't need special drivers for most SCSI hardware. It would be nice if all drivers worked this way, unfortunately, not all drivers will work and those drivers must be updated.

Because Apple recognizes that their users will need to continue using their existing devices, Rhapsody has a dual boot mechanism. The Macintosh can be booted into Rhapsody and run the Blue Box, but if a device is only going to work under traditional Macintosh, then the machine can be rebooted to run the traditional Macintosh OS. In this mode, Rhapsody won't be running at all - all old drivers should then work.

Fortunately, the new driver kit makes writing drivers easier. Apple knows that Rhapsody will only succeed if users can use their devices, and Apple is working with developers to make sure they are using the new driver kit. Developers should be happy with the new driver kit as it will cut development time dramatically.

Apple's abandoning all these cool technologies

First, Apple has not abandoned the technologies we have come to rely on. They have put some of their technologies in maintenance mode, which means there aren't going to be any wizzy new features added to it. Some bug fixes, and system upgrades will still happen.

One example of an "abandoned" technology is OpenDoc. The rumors are that nobody is working on OpenDoc, and all developers that committed to it are now out of business. The reality is that OpenDoc has been ported to MacOS 8, and is already running on the Blue Box under Rhapsody. All existing OpenDoc parts will run under Rhapsody in the Blue Box.

Furthermore, even though Apple has no announced plans to port OpenDoc to be a native Rhapsody application, Apple is not stupid. If a market appears for OpenDoc parts, Apple still has all the source code, and they still have engineers that know the internals of OpenDoc. If Apple finds out that another technology they created is taking off and becoming an industry standard, I would expect Apple to jump right back in. Developers that have committed to OpenDoc may not have the huge market they were hoping for, but if they can create the market, Apple will be right back on board. Now, that's just my opinion, and it is unlikely that Apple will comment one way or another, but I think it's a safe bet that Apple will do what's in their best interest.

Justification of this opinion, however, can be seen in Game Sprockets. Less than 2 months ago, it was announced that Game Sprockets would be in maintenance mode. By WWDC, Apple was shown that Game Sprockets is an emerging standard, will help sell machines, and is just a generally good idea to have. Game Sprockets are back in development, and are being ported to Rhapsody.

Whatever Apple announces at WWDC is dead in a year

In the past, Apple has shown developers new technologies as early as possible, and the developers helped shape each technology. By the time the technologies were ready for users, the technologies often had very little in common with what Apple first presented. Occasionally, once the technology had been hashed out with developers, Apple realized that it may be cool, but nobody in the market cares. They would then cancel the technology, and the developers that wanted to use the technology were, justifiably, upset.

This year, there is a difference. Apple is not showing us technology in its infancy, but technology that has been ported to several platforms and used for many years. The main thrust of WWDC was Rhapsody and how all the other parts of Apple will fit into Rhapsody. Some of the technologies Apple showed at WWDC are in their infancy, and I would expect changes in those technologies, and I would not be surprised if a few of the things I heard never saw the light of day. Rhapsody, fortunately, is unlikely to be canceled.

Macintosh Developers have abandoned the Mac and are all developing Windows apps

Every year I hear this, and every year I look around and see thousands of Macintosh developers. True, there are many developers that have moved to Windows, and a lot that have moved to Java, but there are also many new Macintosh programmers. WWDC had almost 2000 developers, and that's almost as many as they had last year. Of course, last year, there were additional developers that only attended for one or two days, so it's harder to compare.

Companies, however, have had to make a business decision. Many companies last year announced a wait and see attitude on the Macintosh. Some companies even downsized their Macintosh departments. The good news is that other companies jumped into the market to fill the void created by those companies jumping ship.

Interestingly enough, some of the companies that downsized their Macintosh departments have been struggling to rehire Macintosh programmers, usually at a higher rate than they were paying. It turns out that 27 million Macintosh users world-wide have a large influence on purchasing software. Companies that thought the Mac market was dead have had to get back into the market quickly to meet the demand that Macintosh users are creating.

Apple has lost market share

Yes, Apple has lost market share, but the MacOS has gained market share in the last year. The clone makers have taken over a major chunk of the Macintosh market. Some have worried that the clone makers are cannibalizing Apple's share, and this has happened to some degree, but they have also helped Apple expand the market. In reality, Apple has seen the market share of the MacOS grow by 11%.

Apple engineers are all depressed and looking to quit

When Apple laid off over 4000 employees and contractors, the mood at Apple was less than happy. However, like all good programmers, once they had an objective, their focus and happiness returned. Just about every Apple engineer is excited about their new system, and all of them are happy to spread the word. They are cranking out Rhapsody in record time, and at WWDC, they raced to get their latest creations into the show. Every engineer that talked was excited about both Rhapsody as a whole, and their individual efforts.

Apple always talks Pie in the Sky and promises a lot

Yes, they do. This time, for a change, from the CEO on down, the goal was to under promise and over deliver. On this, they did a great job. Several times, a developer would recommend an improvement, and almost every time the answer was, "That's great, we want to do it, but right now, this is what we have to deliver. Maybe next year." After having gotten used to a company that has, more often than not, bitten off more than it can chew, it was wonderful seeing a team that could stay focused on what they are working on and leave the dream solution for later day.

This is not to say that Apple did not recognize developer concerns, quite the opposite. When a developer brought up a point, the Apple engineers considered it, and where they could, they talked about how a developer would deal with that problem. In some cases, Apple agreed to make changes, in others, Apple explained why they made the decisions they did. They have a lot of bright people working on these problems, and they have a lot of open minds.

The most refreshing part, by far, was the Apple engineers admitting that they can deliver a very good system without it being the end-all system. They admit that there will be problems to be worked out, but that won't stop them from delivering a good system in a reasonable time frame. The best part, most developers understood and respected Apple engineers when they said "Not this year."

I'll admit that I was pretty excited about Apple merging with NeXT before WWDC, but what I got was better than I could have ever hoped. I had been afraid that Apple engineers were dejected, NeXT engineers would gloat, and nobody would know what they were going to deliver. Instead, I saw Apple and NeXT engineers working together, everyone excited, and some pretty cool stuff being developed.

If you weren't there, you wouldn't have seen the glow in the engineer's eyes when they had the MacOS (Blue Box) running on Rhapsody. You wouldn't have known that they feel they are creating something special. Most of all, you wouldn't have seen a management team listening to the developers, and taking notes to suggestions.

Michael Rutman is a software developer with experience developing for several platforms, including Macintosh, NeXTSTEP, Newton, Pilot, and Windows NT. While working at Software Ventures, he lead the development of Snatcher and MicroPhone Pro for NeXTSTEP. He also worked on the MicroPhone Pro for Macintosh product line. He now works as an independent consultant on a variety of projects including encryption, compilers, web based add-rotation software, and ship stevedoring. To contact Michael Rutman send mail to moose@manicmoose.com.