In 1994, things were going badly for Apple.  The project to create a new object-oriented operating system cooperatively with IBM was not yielding a product.  None of the other initiatives with IBM were working out. John Sculley’s plan to sell Apple to AT&T, or to somebody (anybody) else had failed, and Sculley had resigned in late 1993.  The suit against Microsoft had failed.  It had been appealed, but the appeal had little hope and when it was denied it would free Microsoft to replace their hobbled Macintosh clone Windows v3 with a feature-for-feature imitation of the Macintosh OS.  Microsoft was preparing that product, which would be called Windows ’95, and was released only 6 months after the final rejection of the appeal.  The newest version of System 7 had a lot of very cool new features, but did not solve any of the old problems that plagued the aging Mac OS.  The switch to the IBM PowerPC processor had not freshened the Macintosh’s image.  Something really new was needed.  So in 1994, Apple began work on a successor to System 7, to be called System 8.  It wasn’t to be just a new set of features, but a complete rewrite of the operating system built around a modern, object-oriented, protected memory, multitasking kernel.  Still, it was supposed to be able to run most or all existing System 7 programs. It was announced at the WWDC in March, 1995, and it’s release date was announced ahead of time.  It was supposed to be released early in 1996. 

How Long Does it Take to Write an Operating System?

   It is usually said that Apple failed in their attempt to create the new operating system they promised.  It is probably more accurate to say that they failed to produce it in the time allotted.  Was it a sensible timeframe in the first place?  The original Macintosh project started in 1979, and was released early in 1984.  Of course that required hardware as well as software design.  System 7, which was far from being a complete rewrite of the Macintosh OS, was begun in 1988, and was released in 1991.  A/UX began with a completely finished and working multitasking protected memory kernel, and Apple was only required to create the Macintosh program environment.  It was first released without the Macintosh environment in 1988, and gradually acquired one over several years.  It’s last release in 1995 had a working Macintosh environment running as a unix task, and was about half-way along in the task of making it possible to run Macintosh programs in a protected memory environment.  I think it is safe to say that Apple had never before produced a new operating system in a year.  Did the Apple leadership really think they could produce a completely new operating system that quickly?  Or were they just trying to offer hope to Macintosh users with the assurance of something wonderful coming soon, if they would just hold on a little longer?

What Did Users Want?

  There was a growing dissatisfaction with the progress of the Mac OS.  Since the beginning, all Macintosh programs running at the same time depended upon each other’s good behavior.  But programs crashed, and when they did, they had a tendency to bring all the other running programs down with them.  Unsaved changes in all the programs were lost, and time was wasted hopelessly rebooting the computer knowing that all the past several minutes (or hours) work would be nowhere to be seen.  Secondly, when the computer was doing some ordinary I/O task, like copying a file, it became unresponsive and made users wait, killing time until it completed.  As files and disks became larger, users were waiting a longer time for some of these things to happen. What was really causing these problems?  The biggest instability problem was caused by having all Macintosh programs share a common logical memory space.  Even the operating system’s private data lived in a single read-write space that it shared with all running programs.  There was nothing to stop an errant program from writing over parts of memory outside of its assigned space, and when that happened it could wreak serious havoc.  There was also no proper scheduler.  Once a program was running, it had unchallenged control over the processor.  Even a relative benign program failure, like getting stuck in an infinite loop, could require a reboot, even though all the other programs and their data were really undamaged.  And a reboot was as bad as a crash.  All the innocent programs were restarted without saving changes to their data, just like the offender who caused the problem.  Programmers running with a low level debugger (like TMON or Macsbug) installed, could often kill an errant program and pass control to a good one and be fine.  But most users didn’t know how to use something like that, and anyway it only worked part of the time and for certain kinds of crashes.  The worst of these crashing program problems would be corrected by a protected memory, multitasking operating system. 

    The other problem, having to wait for the computer to complete housekeeping tasks like reading or copying files, was only indirectly related to multitasking.  It was really a problem with one single program, the Finder.  Normally, we don’t expect programs to let us keep on working while they do things like write files to disk.  Even now, using Mac OS X, I wait a long time for Illustrator to save a large file, or for Photoshop to rasterize a big complicated pdf image.  This is not the fault of the operating system.  Illustrator and Photoshop run those operations in their main thread, and so the user can’t do anything else in the program until that task completes.  It would be great if Photoshop would launch a thread to handle things like that and I could keep working on one document while it is working on importing another.  But I don’t really expect Adobe to do that for me.  The Finder, however, isn’t just any program.  To most users, it is the operating system.  In System 7 the Finder acted like Illustrator does today.  If you asked it to do something, like copy some files from one disk to another, it would refuse to interact with you again (beyond just beeping at you) until that was done.  Solving this problem did not require a new operating system.  Just a new Finder.  Hard to do maybe, but not as hard as making a whole new protected memory program run-time environment. 

   Finally, the latest Macintosh computers ran on the new PowerPC processors that were supposed to be much faster than the Motorola 68k processors they replaced.  They had much higher clock speeds, and Apple said they were much faster.  Yet, they didn’t seem much faster.  It wasn’t just our imagination.  It was well known that System 7 ran slow on those processors because it was not native.  The operating system was almost totally written in 68k assembly language, and Apple was slowly and only partly rewriting the operating system so that it could be compiled for the PowerPC.  Admittedly, it was a huge job.  But no wonder the Macintosh was so slow, it was running in emulation!  Apple had to rewrite the operating system anyway.  Why not make it better and more modern while they were at it?

Roadmap

    The new operating system, Mac OS 8, would offer solutions to all of these problems, but in two stages.  It would be a memory-protected, preemptive multitasking operating system.  It would be written in native PowerPC code.  And it would have a multithreaded Finder that could do a number of things all at once.  It would run existing programs written for System 7.  That was the good news.  The bad news was that in the first stage (code name Copland) the old programs would have to run in a kind of emulated old-fashioned Macintosh environment that didn’t offer much benefit from the new features.  Programs would basically all be packed into a single program, similar to the way the System 7 environment worked in A/UX.  But this would be solved in the second phase of the project, code name Gershwin.   Macintosh programs written for Gershwin would fully benefit from memory protection and multitasking.  Each would live in it’s own independent memory space and be guaranteed their time slice of execution overseen by a pre-emptive scheduler.

    All of the Copland features were demonstrated on television, in an episode of the Computer Chronicles in October, 1995.  Everything worked, and it looked like Copland was basically complete and ready to go out to developers in November, 1995, as originally planned.  Looking back, it seems certain that the stuff that Adam Samuels demonstrated on that show was some kind of mock-up.  I didn’t realize it at the time, but watching the show now, I can see that throughout the ‘demo’ Adam never touched the mouse.  Yet you see the cursor move around on screen.  It was all fake.

The A/UX Legacy-- The Macintosh Application Environment and the Blue Box

  Why did Apple go through this ridiculous exercise?  Why not just use A/UX as their new operating system?  It had everything they were looking for.  It was a solid, highly reliable kernel with a long history of development.  It had a great Macintosh environment that ran as a unix process and would execute practically any System 7 program.  And much progress had been made toward the post-Copland goal of breaking out of the virtualized Macintosh environment and making Macintosh programs full-fledged processes.  Of course there was one problem. The A/UX kernel didn’t belong to Apple.  It was AT&T’s System V Unix.  Even the port of System V to the Macintosh had not been done by Apple, but by another company, Unisoft.  Apple couldn’t have risked its entire product line on an operating system it was renting from AT&T, the infamous telephone monopoly that Steve Jobs and Steve Wozniak started their careers righteously ripping off with their blue boxes (no relation).  And although “Unix-based” sounds like a good thing to us now (Apple uses it as selling point for OS X), it didn’t sound as good back then.  Unix was not the operating system for the rest of us.  It was the geekiest and most difficult to use operating system in the world.  Unix users were actually proud that their operating system was too difficult and arcane for regular people.  Finally, behind the scenes Apple designers were hoping to do something new and better.  The Unix kernel and its programming model seemed a little old-fashioned already. Apple and IBM had been working together on an object-oriented programming framework called the System Object Model.  IBM was using it in their ill-fated OS/2 operating system.  They also were taken with a more flexible memory model based on memory “objects” that could be loaded into arbitrary places in memory.  Much of this was also used by NeXT in their operating system, which had by that time been ported to a wide variety of processors.

    But the one part of A/UX that belonged to Apple was a valuable asset.  It was a portable virtual System 7 environment -- a Unix program that created a virtual Macintosh operating system and could host practically all System 7 programs.  With little more than a recompile, it could be moved to a new platform.  When the decision was made not to port A/UX to PowerPC, the System 7 environment became a stand-alone product, the Macintosh Application Environment for Unix.   It was released in 1993 and versions ran on Sun Solaris 2.x SPARC and Hewlett-Packard HP-UX 9.x (PA-RISC) processors.  These products would look very familiar to a user of today’s Basilisk II Macintosh Emulators. They were a completely portable Macintosh that could be created for any Unix machine.  That part of Copland, at least, would be relatively easy.  If the kernel could be created and made stable, the System 7 environment could just run as a simple program on the new architecture.  This technology, later called the “Blue Box” would never become a part of Copland, but it would prove very valuable a few years later, in the early days of Mac OS X.  The Macintosh Application Environment for Solaris and HP-UX was discontinued in May, 1998. 

New Finder Features

    A cure for what was ailing the old operating system might sound like a big enough job.  But there were a lot of other system software projects underway at Apple, and a lot of improvements in the Macintosh user interface being developed. A bunch of these got incorporated into Copland.   Drag and drop had been a major System 7 innovation.  In Copland, spring loaded folders would open up a Finder folder if you dragged a file over it and then hesitated, holding the file over the folder’s icon for a second or two.  This would let you see inside the folder before dropping your file into it.  Another cool improvement was pop-up windows.  If you dragged a Finder window’s title bar down to the bottom of the screen, the window would be reduced to a tab with the window’s name that hugged the edge of the screen.  Clicking on that tab would cause the window to open up so that it’s bottom hugged the edge of the screen.  It would stay that way till you clicked on the named tab again, at which time it would collapse back to its minimized state. 

    The Multithreaded Finder was not just eye candy, but was a response to one of the major complaints about System 7.  The main benefit came when copying files, one of the most common Finder tasks. Every file copy task was placed in a separate thread, and the progress indicator was put in a modeless dialog box.  While a file copy was underway, users could proceed to do other tasks, including other file copy operations. 

    We know about these features of Copland, because they were incorporated into the version of Mac OS 8 that was released 1997 and enhanced over the following two years.  Many of the other features planned for Mac OS 8 (Copland) can only be  gleaned from Apple’s pre-release documentation.  Wait.  What did I just say?  Pre-release documentation?  That can’t be.  Apple is so secretive.  But yes, in fact, Apple didn’t just demo Copland on Computer Chronicles months before it’s intended release, but released a lot of written documentation, much of it is still around and available on the web.  One of these was a full book on Copland written by an Apple employee, Tony Francis.  This book, Mac OS 8 Revealed (1996), can still be purchased on Amazon (at the time of this writing).  It included a CDROM with screen shots and Macromedia Director movies showing Copland in action.  Those movies look suspiciously like the “demos” shown by Adam Samuels on TV. 

Apple Guide

    The pre-release documentation featured planned enhancements to Apple Guide.  Apple Guide had been introduced in System 7.5.  It was an interactive help system that used AppleEvents to monitor the user’s responses while being instructed.  It was surprisingly interactive, and would walk you through a task, and monitor whether you were doing it right or not.  The first time I saw it (in System 7.5) draw with a virtual red highlighter on the screen, showing me where to click or what menu to use, I couldn’t believe my eyes.  But this next version was going to do even more.  According to the documentation, on line help used to be based on “tell me how”.  Apple Guide changed this to “show me how”. And in Copland, it would be enhanced to “do it for me”.  Computerized assistants would automate tasks the user wanted done.  Because Apple Guide relied on Apple Events to do things, this sounds suspiciously like the Guide was going to help users write AppleScripts.  Maybe this technology developed into Automator.  But Apple Guide, as cool as it was, wasn’t what users wanted, and it never got used much.  It was a hassle to write an Apple Guide unit for your program, and although many people did it, it never seemed worth it, because users didn’t appreciate it.  Why not?  I think it’s because users didn’t want an easy way to learn to use their computers.  They wanted the computers to be so easy that they didn’t have to learn anything.  Apple Guide gradually turned into an html-based help system, much easier to make, nowhere near as capable, but equally appreciated by users (meaning not used at all, except as an angry last resort).  We still have it in OS X, I think.  I never try to use it.  There’s always an easier way.  There isn’t any help at all in iOS.  Not needed.

Open Doc

    OpenDoc was still being actively developed.  It was a natural to try to incorporate it into Copland in some way.  Reading Apple’s documentation, it sounds like OpenDoc and Copland were joined at the hip.  Maybe they should have been, as they both used the System Object Model.  But reading Greg Maletic’s account of it, the relationship between OpenDoc and Copland groups at Apple was built mainly on mutual suspicion.  OpenDoc was a memory hog, and was basically intended to be the only program running.  Copland was built around the idea of having lots of programs running.  OpenDoc probably looked like a formula for thrashing in the virtual memory environment they were planning to have running on machines available at the time, which had only a few MBytes of memory.  Also, OpenDoc was a re-imagining of the Macintosh user interface, and was writing its own rules.  Copland engineers probably wanted that job.  In any case, OpenDoc apparently never ran in Copland, despite what the documentation said. 

    In Guy Kawasaki’s book, The Macintosh Way, he summarizes the strength of the Macintosh Spirit, as the confluence of doing “the right thing”, and doing it “the right way”.  By 1996, I’d say there was nothing left of The Macintosh Way at Apple.

Installing the DDK

   There are two different Copland developer releases that can be found on the web.  These seem to correspond to the various reports that a driver development system was released in November 1995.  I can’t find any reference to a second release, but there must have been one.  The two releases are called D7E1 (scarecrow) and is dated July 1995.  The second one is called D11E4, or Mac OS 8 DDK 0.4, and is dated June 1996 (so far as I can tell).  This later one (especially if you can find the package called Mac OS 8 DDK 0.4) includes sample code, header files and libraries intended to help developers build drivers for the new operating system.  It has complete instructions describing what you have to do to install the operating system on a Power Macintosh 6100, 7100, 8100, 7200, 7500, 8500, or 9500.  The instructions specifically say that the release is not suitable for use by applications programmers, and that turned out to be true. 

   I have a Power Macintosh 8100/80av that has been fixed up with a lot of extra memory and a NewerTech G3 accelerator.  I guessed I had to take out the accelerator, but my machine was on the list that should run the release.  I removed a video card I had installed, and ran the test using on-board video, trying to make the machine as stock as possible. The instructions say that I needed another machine running the PowerMac debugger and set for remote debugging over a serial line.  I looked around and realized that I had given away all my old DIN-8 Macintosh serial cables, but I found one for a dollar at my local Goodwill store (in the bin marked PS-2 keyboard cables).  A particular version of the debugger came in the package.  It was version 2.1d13.  I installed it on a PowerMac 7600/120, that also has a G3 accelerator and is running Mac OS 8.5.  The debugger ran okay with no modification of this arrangement.

    Installing Copland on the 8100 host machine was a little complicated.  A 250 MByte or larger hard disk has to be freshly initialized using Drive Setup v2.0d5c2, which was included.  Because Drive Setup usually doesn’t support non-Apple hard disks, I hunted around a little to find an Apple branded hard disk.  I don’t know if this was necessary.  The instructions say to create a single HFS partition, and install a fresh copy of System 7.5.x using the installer.  I used 7.5.3.  Then, the instructions say, you install Mac OS 8 D11E4 using the installer.  At this point you have both operating systems on your disk.  When you restart, if you have the Caps Lock on, you will boot into Copland.  Otherwise, you start up 7.5.

    The first time I tried it, Copland started to boot, and failed early on with the message “No Kernel Stacks Available”.  It turned out that my 8100 just had too much memory for Copland.  I removed all but 40 MByte, and it started right up.  It starts with an animated Mac OS splash screen, and a console window that gives some running commentary on startup.  You can see that here. After that we get the now-familiar Mac OS 8 Platinum look.  Remember that this look had never been seen before.

The Finder in a Clown Suit

    A new operating system should have a distinctive look, so that people know right away they are working with something new and different.   In previous versions of the Macintosh OS, the look of user interface items was built into the definition functions for the individual items.  These were stored in resources, and the standard ones were in the System file.  But programmers could write their own to customize the user interface.  Window appearances were defined by WDEF resources, menus by MDEFs and controls by CDEFs.  Giving the desktop a new look required rewriting all of those separate pieces of code.   For Copland, the it was decided that the appearance of items should be unified and organized by a new manager, the Appearance Manager.  The standard look, called Platinum, would utilize levels of gray to create a shaped metal look, a little like the one used in NeXTSTEP, but less angular.  But the Appearance Manager also made it feasible to create a variety of different looks, something like the “skins” that were just starting to be seen as features of some programs. Macintosh users had always had a lot of options for customizing their system using resource editors,  and it seemed to be a selling point for Apple, but it was always piecemeal -- one thing at a time.  Maybe opening up the customization of appearance in a big way would be a popular feature.  Apple incorporated the Appearance Manager into the Copland product description, and emphasized this in their promotional material.  To demonstrate it, they created two themes other than Platinum, one called Hi-Tech and one called Gizmo.  Hi-Tech looked like a typical dark over-decorated techno skin that became popular for linux desktops in the 1990s and early 2000s. Gizmo was truly awful.  It was presented as a possible interface for kids to use.  I wouldn’t have ever let my kid use it, in fear it would ruin his sense of good taste forever.  It was like the Finder in a clown suit, with a big red nose and a set of floppy shoes.  Apple showed it off like it was something great.  The reputation for good visual taste that had been one of the Macintosh’s most respected attributes was gone in an instant.  Wisely, these crazy skins were not available in the released version of Mac OS 8, in which the Copland Appearance Manager appeared.

The Copland Legacy

    Famously, the Copland project was terminated by Gil Amelio, partly on the advice of Ellen Hancock, and Amelio went looking for a working operating system that could be configured to run Macintosh software.  And, by good fortune, he chose to buy NeXT, and to build the next version of the operating system on top of their Mach-NeXT kernel.  And when they got NeXT, they also got Steve Jobs back.

    Usually, the story ends here, as if having the NeXT kernel and Steve Jobs just magically resulted in the Macintosh OS we have now.  That would have been enough if the new operating system had just been NeXTSTEP.  Maybe that was what Jobs and the crew of NeXT engineers (including some key Macintosh alumni like Bud Tribble) originally intended.  But if we had wanted to run NeXTSTEP, we would have done that back in the 1980’s and NeXT would have succeeded.  What we wanted was a new Macintosh operating system.  By we, I mean the people who bought Macintosh computers, software, and peripherals, and the people who wrote software for the Macintosh in 1997-2000.  Remember there were no NeXT customers at that time, and people who used Windows were pretty happy with that platform.   If Apple were to survive, they had to convince Macintosh users to purchase the new equipment and use the new software that Steve, Avie, et al. were preparing.  Like it or not, Macintosh users had not moved to NeXT when they had their first chance in the 1980s, and they weren’t going to do it in 1998.  Somehow, NeXTSTEP had to be turned into a Macintosh OS, something it was never meant to be.

    One obvious and relatively easy thing to do was to port the Macintosh Application Environment to NeXTSTEP.  And a second thing was to give NeXTSTEP a Macintosh-like window manager, so that windows and menus and controls had an Apple Platinum look.  The combination of these things produced the basis for the first of the Rhapsody developer’s releases.  The Macintosh Application Environment was called the Blue Box. This was approximately what Copland would have been like (except that it included the NeXTSTEP application environment, which was called Yellow Box, and later named Cocoa) . The problem with this solution was that it wasn’t a solution.  The Blue Box was what we already had.  It put all Macintosh programs into a single memory space and left us with the same problems we had in OS 7 - 9.  Yellow Box was great, but it was totally incompatible with the entire Macintosh code base.  We (and especially the big software houses, Adobe and Microsoft) weren’t ready to give that up. Rhapsody was already being distributed to developers in 1997, but it was going nowhere.

    The thing that worked the trick was Carbon.  Carbon was what Gershwin was supposed to be.  It was a protected memory preemptive multitasking environment for Macintosh programs.  It had a thread-safe version of the Memory Manager.  All the legacy code that plagued the Macintosh OS for 10 years was gone.  How long did it take for Apple to make Carbon?  The NeXT purchase was made in early 1997, and Rhapsody was already ready for the  (unreceptive) developer community at the WWDC in that year.  The first Carbon-compatible version of Mac OS X was version 10.0, introduced in 2000.  Four years.  Copland was a failure because it couldn’t be done in two.  To pull this off in that amount of time, Jobs stripped Apple of a host of other hardware/software projects (like Newton) and pure software projects (like OpenDoc), so that the company could concentrate on saving its center, the operating system.  In the meantime, from 1997 to 2000, what could Apple do?  They released the finished user interface parts of Copland as OS 8 and 9, and they were great.  They didn’t solve the core problem, but they were greatly appreciated, and kept the Macintosh market going.  Mac OS 9, with its multiple-use feature, is feature-for-feature, right out of the Copland documentation.

    How much of Copland made it into Carbon?  How much of the 2 years of work put into Copland went toward shortening the timetable for Carbon’s release?  I have not found a definitive statement of this from people who were there.  But I’d be willing to bet that everything that could be used was used, and that it was a lot. Looking at it today, there is a very strong family resemblance between the Copland and Carbon event managers and Human Interface Toolbox.  Carbon also uses a programming language-agnostic object oriented programming interface similar to the System Object Model.

     After the battle of wills associated with the Rhapsody releases was over, Macintosh users got a new Macintosh operating system and it was close to what the Copland-Gershwin team had envisioned.  Almost all of our existing code base could be used (with some exceptions, most notably Publish and Subscribe).  Even our beloved AppleEvents and AppleScript survived, although I am sure that  was a close-run thing.  And Carbon was great.  Programs could be moved from the old Macintosh OS to Carbon with minimal work, and ran just as designed.  The success of Carbon was so great that Apple was able to kill the Blue Box with almost no controversy, at the time of the Intel transition, because all the important Macintosh code had made the Carbon transition by that time.  Carbon object oriented frameworks, like MacApp and PowerPlant (even the Think Class Library) were carbonized, and continued to be used.  MacApp is still actively supported today.  For a long time, even the Finder was a Carbon program, written using PowerPlant.  Apple did this, even though there was an obvious antipathy to Carbon and the old code base, coming from the highest levels of Apple. Carbon, and Carbon-hatred, continue to live together at Apple.  Carbon programming documentation has been mostly pulled from the developer documentation, and Apple has announced that Carbon 64 bit programming will not be allowed.   Still, Carbon programs continue to run, and Carbon programming is still possible in XCode, to this day.

    Thanks, Copland engineers.  Rhapsody sucked.

-- BG (basalgangster@macGUI.com)