Revolution in the Valley: The Insanely Great Story of How the Mac Was Made (49 page)

I decided to put the bits controlling the "locked" and "purgable" attributes in the high-order bits of the master pointer (a pointer to the current address of a memory block), because they weren't being used for anything else. The 68000 had a 24 bit address bus, allowing 16 megabytes of addressable memory, so the high-order 8 bits of an address were not used by the processor. The high bit of a word is the most efficient one to test, which was another reason that I thought it was efficient to locate the flags there.

Of course, it was foolish to count on unused address bits to stay that way for very long, and it became a problem when the Macintosh transitioned to the 68020 processor in 1987, with the introduction of the Macintosh II. The 68020 had a full thirty-two bit address bus, so the memory manager could no longer get away with using the high-order master pointer bits for flags. It wasn't that hard for Jerome Coonen to convert the memory manager to keep the flags in the block header instead of the master pointer (which was where they should have been in the first place), but the practice of manipulating them directly had crept into third party applications, even though it wasn't supposed to, and it took another year or so to identify and eradicate all the transgressions to upgrade the Macintosh software base to be "32 bit clean", so the full address space could be used.

I paid a more direct price for my second worst mistake, which was to use fixed low memory addresses for toolbox globals. The Apple II kept important system globals in low memory, and the 68000 included a special 'short' addressing mode that made accessing addresses in the first 32K of memory more efficient, which motivated us to use low memory for various globals. While that may have been acceptable for system globals, it was a clearly a mistake for the toolbox, since that precluded us from running more than one application at a time, since each application required its own copy of the toolbox globals.

That didn't matter much at first, because with 128K of RAM, we barely had enough memory to run a single application at a time. But when the 512K Macintosh was released in September 1984, it started to become an issue. In October 1984, after I left Apple to work on my own, I realized that you could solve the problem by swapping all of the application-dependent low memory locations when you performed a context switch. In a few days, I wrote the core of the Mac's first multi-tasking environment called Switcher, using the low memory swapping technique, that kept multiple programs resident in memory at once, and switched between them with a nifty scrolling effect. Using low memory like we did ended up making context switching a few milliseconds slower than it should have been, and made it harder to eventually use a memory management unit, but it didn't turn out to be as devastating as I once thought.

We wanted the Macintosh to have a relatively simple system architecture, so it could perform well with limited hardware resources, but perhaps we went a little too far. We decided that we could live without a memory management unit, which was the right decision because of the expense of the associated hardware. But we also decided to eliminate the distinction between user and system code, by running everything in supervisor mode. This empowered applications and simplified the system, but it was a poor choice in the long run, because it made it harder to control the software base as the system evolved.

Even Bill Atkinson made an occasional error. His worst mistake was using signed 16-bit integers as sizes in various QuickDraw data structures like regions and pictures. This limited the maximum size of a region or picture to 32 kilobytes, which became a significant limitation a few years later as memory sizes grew. Bruce Horn's resource manager suffered a similar problem, using 16 bit offsets, limiting the size of resource files unnecessarily.

The biggest problem with the Macintosh hardware was pretty obvious, which was its limited expandability. But the problem wasn't really technical as much as philosophical, which was that we wanted to eliminate the inevitable complexity that was a consequence of hardware expandability, both for the user and the developer, by having every Macintosh be identical. It was a valid point of view, even somewhat courageous, but not very practical, because things were still changing too fast in the computer industry for it to work, driven by the relentless tides of Moore's Law. Burrell did try to sneak some expandability into the design (see
diagnostic port
), but was only partially successful.

Limited hardware expandability exacerbates other flaws in the design, since you don't have the flexibility for yourself or third-parties to easily correct them. One of the biggest mistakes that we made in the first Mac was not enough support for a hard drive. Our first file system used a simple data structure that didn't scale well to large drives (in fact, it was suggested to us by Bill Gates in July 1981), and we didn't have a way to get bits in and out of the box at the rates that a hard disk required. In our defense, it was hard to for us to consider adding a hard disk to the Macintosh because it was one of the last differentiators from the Lisa, which was more than three times as expensive. But the lack of hardware flexibility made it more difficult for third parties to jump into the breach, although some did anyway.

From a broader perspective, I think that many of our mistakes came from a lack of understanding about exactly what we were doing. We thought that we were making a great product, reincarnating the Apple II for the 1980's, but we were actually creating the first in a long line of compatible computers that would persist for decades, although the latter wouldn't have happened if we didn't succeed at the former. Perhaps our design would have given the future more priority over the present if we had understood how long it would last.

On Xerox, Apple and Progress

by Bruce Horn

This essay was written by Bruce in 1996, and is reprinted here with his permission. Bruce was one of the main designers of the Macintosh software, and he worked at Xerox for years before that, so he's uniquely qualified to discuss their relationship.

Where It All Began

For more than a decade now, I've listened to the debate about where the Macintosh user interface came from. Most people assume it came directly from Xerox, after Steve Jobs went to visit Xerox PARC (Palo Alto Research Center). This "fact" is reported over and over, by people who don't know better (and also by people who should!). Unfortunately, it just isn't true - there are some similarities between the Apple interface and the various interfaces on Xerox systems, but the differences are substantial.

Steve did see Smalltalk when he visited PARC. He saw the Smalltalk integrated programming environment, with the mouse selecting text, pop-up menus, windows, and so on. The Lisa group at Apple built a system based on their own ideas combined with what they could remember from the Smalltalk demo, and the Mac folks built yet another system. There is a significant difference between using the Mac and Smalltalk.

Smalltalk has no Finder, and no need for one, really. Drag-and- drop file manipulation came from the Mac group, along with many other unique concepts: resources and dual-fork files for storing layout and international information apart from code; definition procedures; drag-and-drop system extension and configuration; types and creators for files; direct manipulation editing of document, disk, and application names; redundant typed data for the clipboard; multiple views of the file system; desk accessories; and control panels, among others. The Lisa group invented some fundamental concepts as well: pull down menus, the imaging and windowing models based on QuickDraw, the clipboard, and cleanly internationalizable software.

Smalltalk had a three-button mouse and pop-up menus, in contrast to the Mac's menu bar and one-button mouse. Smalltalk didn't even have self-repairing windows - you had to click in them to get them to repaint, and programs couldn't draw into partially obscured windows. Bill Atkinson did not know this, so he invented regions as the basis of QuickDraw and the Window Manager so that he could quickly draw in covered windows and repaint portions of windows brought to the front. One Macintosh feature identical to a Smalltalk feature is selection-based modeless text editing with cut and paste, which was created by Larry Tesler for his Gypsy editor at PARC.

As you may be gathering, the difference between the Xerox system architectures and Macintosh architecture is huge; much bigger than the difference between the Mac and Windows. It's not surprising, since Microsoft saw quite a bit of the Macintosh design (API's,sample code, etc.) during the Mac's development from 1981 to 1984; the intention was to help them write applications for the Mac, and it also gave their system designers a template from which to design Windows. In contrast, the Mac and Lisa designers had to invent their own architectures. Of course, there were some ex- Xerox people in the Lisa and Mac groups, but the design point for these machines was so different that we didn't leverage our knowledge of the Xerox systems as much as some people think.

The hardware itself was an amazing step forward as well. It offered an all-in-one design, four-voice sound, small footprint, clock, auto-eject floppies, serial ports, and so on. The small, portable, appealing case was a serious departure from the ugly- box-on-an-ugly-box PC world, thanks to Jerry Manock and his crew. Even the packaging showed amazing creativity and passion - do any of you remember unpacking an original 128K Mac? The Mac, the unpacking instructions, the profusely-illustrated and beautifully- written manuals, and the animated practice program with audio cassette were tastefully packaged in a cardboard box with Picasso- style graphics on the side.

Looking Back

In my opinion, the software architectures developed at Xerox for Smalltalk and the Xerox Star were significantly more advanced than either the Mac or Windows. The Star was a tremendous accomplishment, with features that current systems haven't even started to implement, though I see OpenDoc as a strong advance past the Xerox systems. I have great respect for the amazing computer scientists at Xerox PARC, who led the way with innovations we all take for granted now, and from whom I learned a tremendous amount about software design.

Apple could have developed a more complex, sophisticated system rivaling the Xerox architectures. But the Mac had to ship, and it had to be relatively inexpensive - we couldn't afford the time or expense of the "best possible" design. As a "little brother" to the Lisa, the Macintosh didn't have multitasking or protection - we didn't have space for the extra code or stack required. The original Macintosh had extremely tight memory and disk constraints; for example, the Resource Manager took up less than 3,000 bytes of code in the ROM, and the Finder was only 46K on disk. We made _many_ design decisions that we regretted to some extent - even at the time some of us felt disappointed at the compromises we had to make - but if we had done it differently, would we have shipped at all?

The Past and Future

In many ways, the computing world has made remarkably small advances since 1976, and we continually reinvent the wheel. Smalltalk had a nice bytecoded multi-platform virtual machine long before Java. Object oriented programming is the hot thing now, and it's almost 30 years old (see the Simula-67 language). Environments have not progressed much either: I feel the Smalltalk environments from the late 1970's are the most pleasant, cleanest, fastest, and smoothest programming environments I have ever used. Although CodeWarrior is reasonably good for C++ development, I haven't seen anything that compares favorably to the Smalltalk systems I used almost 20 years ago. The Smalltalk systems of today aren't as clean, easy to use, or well- designed as the originals, in my opinion.

We are not even _close_ to the ultimate computing-information- communication device. We have much more work to do on system architectures and user interfaces. In particular, user interface design must be driven by deep architectural issues and not just new graphical appearances; interfaces are structure, not image. Neither Copland nor Windows 95 (nor NT, for that matter) represent the last word on operating systems. Unfortunately, market forces are slowing the development of the next revolution. Still, I think you can count on Apple being the company bringing these improvements to next generation systems.

I'm sure some things I remember as having originated at Apple were independently developed elsewhere. But the Mac brought them to the world.

The Macintosh Spirit

by Andy Hertzfeld