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

"But where do we draw the line?", I asked. "What are the differences between an ornament and a real application?"

"Well, ornaments have to fit into the world of the main application", Bud responded, "but not the other way around. The main application owns the menu bar, for example, but maybe the ornaments can have a menu when they're active. The main application would still run its event loop, but it would occasionally pass events to the little guys. And of course you can cut and paste between them."

That sounded good to me, but we had plenty of other stuff to work on first. Bud left Apple in December 1981 to return to medical school, but I explained his concept to new team members and considered them to be part of our plan. Chris Espinosa liked the idea when we explained it to him, and he worked on a visualization of the calculator as part of learning to program with QuickDraw, culminating in a calculator construction set (see
calculator construction set
). Eventually, after getting the initial implementations of the window, menu and event managers going, by May 1982 we had enough of the rudiments done to give desk ornaments a try.

The nascent Mac operating system already had an implementation of loadable device drivers, where installable code could be loaded from disk to manage optional peripherals. I decided to cast desk ornaments as a special kind of driver, adding a few extra calls so they could maintain a window on the screen, receive events from the host application, and occasionally get some processing time to accomplish something. Applications were required to make a system call periodically to yield some time for ornaments to run, and had to occasionally pass events to them and follow a few other conventions for co-existing. The very first desk ornament was a boring one, called "TestOrn", that displayed a rectangular window with an incrementing counter, showing that it was capable of doing background processing, even when it wasn't the top-most window. It wasn't very impressive, but it became the template from which all the others sprung.

In the fall of 1982, the first pass of the User Interface Toolbox was completed, so I had time to work more on ornaments, which by this time were renamed "desk accessories" by the pubs group who thought that the term "ornament" was too ornamental. I wrote a simple clock, and got the calculator going, modeled after Steve Jobs' design from the calculator construction set. The most interesting one that I wrote in that spurt was a desktop pattern editor, which was a sort of miniature icon editor that let you edit an 8 by 8 pixel pattern by clicking to toggle the dots on and off. When you made a pattern that you liked, you could make it the desktop pattern, filling the background of the screen with your new creation instead of the standard gray.

Within a couple of months, other people wanted to take a crack at writing desk accessories. Someone asked me if they could write one in Pascal, which wasn't easy because you had to pass parameters to the underlying driver in registers, which the Pascal compiler couldn't manipulate directly. I realized that you could write a little bit of standard glue code in assembly language to do the dirty work, and have most of your desk accessory written in Pascal. I wrote a number puzzle in Pascal as a test case, to prove that it could be done (see
the puzzle
).

But once again I had to get back to other things and the desk accessories languished. But by the spring of 1983, the ROM was beginning to stabilize, and we realized that we had to get serious about the desk accessories that would ship with the initial system. Jerome assigned Donn Denman, who was taking a hiatus from working on Basic to help us finish the system, to help with desk accessories. Donn and I collaborated on finishing the calculator, with Donn doing the back-end that interfaced with the floating point routines. Donn was also responsible for the alarm clock and notepad.

Now that we had cut and paste working, I realized that it would be useful to have a desk accessory that could hold commonly used snippets of text and graphics, so they could be pasted into any application. I wrote a desk accessory called the "Gallery" that allowed you to manage a set of clippings using cut and paste, building it on top of the resource manager so it was easy to implement. Everyone seemed to like the functionality but not the name. I was explaining the situation to Larry Kenyon when he suggested that we call it the "Scrapbook", which was perfect, so the Scrapbook joined our growing armada of useful desk accessories.

The Macintosh's character encoding scheme allocated the upper half of the 8-bit character set to occasionally useful but obscure characters that were not portrayed on the keys, accessed with the option key, that were nearly impossible to remember. Steve Capps conceived of a desk accessory called "Key Caps" (named partially after himself?) that displayed a picture of the keyboard, with the keycaps changing depending on the meta-keys that were pressed, which allowed you to hunt for the special characters visually. He coded it up quickly and it became another great addition.

The Control Panel

We needed a way to control various system parameters like the sound volume, or the mouse scaling parameters. We decided that a desk accessory would be perfect for that, since it would be easy to access no matter what application you were in. So the last desk accessory that I worked on before shipping, in November 1983, was the Control Panel. Susan Kare came up with a beautiful, highly graphical design (with no text whatsoever) that I implemented using a separate purgable resource for each section, so they didn't have to be in memory at once. It had a little rabbit and tortoise to represent a range of speeds, and lots of other graphical embellishments; after the Mac was released, one review described it as a crib toy, which I took more or less as a compliment.

The most controversial part of the Control Panel was the desktop pattern editor, which I had rescued from its earlier stand-alone incarnation. Users could select from a couple dozen prefabricated desktop patterns or edit their own in fat bits. It was this latter capability that caused problems, as it was pretty easy to create ugly, abominable patterns.

Bill Atkinson complained to me that it was a mistake to allow users to specify their own desktop patterns, because it was harder to make a nice one than it looked, and led directly to ugly desktops. But I thought that users should be free to do as they pleased, since it was their desktop, and it was easy to revert to one of the built-in patterns. Bill cared most about MacPaint, and didn't want a potentially ugly desktop pattern marring his creation. So he made MacPaint allocate a window that was the size of the screen when it started up, and filled it with the standard 50% gray pattern, making his own desktop covering up the real one, thus protecting the poor users from their rash esthetic blunders, at least within the friendly confines of MacPaint.

I Don't Have a Computer!

by Bruce Horn in December 1981

When I joined the Mac group, we were still very small, working in what we called Texaco Towers--a nondescript office building behind a Texaco station at the corner of De Anza and Stevens Creek, in Cupertino, long since gone (see
texaco towers
).

The software group had offices on one side of the office building, and the hardware group was on the other side. Our offices were quite spare. One room toward the front of the building had a line printer (one of those old, big, noisy impact printers) that was driven by an Apple II. To print out your sources, you had to write them to an Apple II disk, run a program to swap the bytes or do some other manipulation, and then put it in the Apple II which would then run the line printer.

Of course, to print out sources, you had to write some code. I was ready to go, and I had been on the Mac team for several weeks but still hadn't gotten a Lisa, the development machine we used. The Lisa was still under development, and the prototypes were very difficult to obtain. I was starting to get a little frustrated and complained to Andy Hertzfeld at one point that maybe I should go work for a *real* company that could provide the appropriate tools for their software developers.

Andy mentioned this to Steve Jobs. Steve immediately said, "Well, should we fire him?" Andy replied "No, just get him a computer!"

Later that day I received a note from Steve to go to a particular office in another Apple building; there would be a Lisa on the desk, and I could take that one and use it. I went over to the other building and found the office.

The nameplate on the office door said, "John Couch." John was the head of the group developing the Lisa. I wasn't sure that this was really OK, but I had a note from Steve if anybody asked, so I walked into the office, unplugged the computer, and carted it away.

I still don't know to this day whether Steve had arranged this with John, or if John came back to the surprise of an empty desk, but I did get a lot of use out of that machine, maybe more than John ever did.

The Grand Unified Model (1) - Resources

by Bruce Horn in December 1981

Applications contained many resources

Imagine the challenge: designing and implementing a brand new, graphical user interface, operating system, and core applications for a small personal computer to compete with the IBM PC. That's what we were going to do with the Macintosh.

The year was 1981, and I had just graduated from Stanford University. The past eight years I had spent as much time as possible working in the Learning Research Group at the Xerox Palo Alto Research Center. PARC was the place where everybody who was anybody in computer science wanted to go work, or at least visit. And I had just decided to leave PARC to join Apple (see
joining the mac group
).

I was used to working on Altos and Dorados, powerful workstations with bitmapped displays, mice, networking, and the most advanced software development system of the time, Smalltalk. These machines had lots of memory, at least 3MB of fast disk storage (remember, this was 1981), and were very fast. To build one of the Altos cost over $15,000, and Dorados much more. At Apple, the Macintosh was going to be a much more limited machine, with a tiny bitmapped display, no hard disk, and a mere smidgen of memory. It would have to be able to be built for under $1000 if we were to compete with the IBM PC and other personal computers of the time. And we were going to try to build a graphical user interface and operating system that would work acceptably on an 8Mhz 68000 microprocessor.

Fortunately, I had worked on a 8086-based system at PARC, the NoteTaker (see
joining the mac group
), so I knew what the limitations of small systems were. Still, I was used to the Smalltalk user experience, and wanted to do whatever I could with the Finder to approach the friendliness, flexibility, and ease of use that Smalltalk provided.

Smalltalk was an integrated object-oriented language and programming environment, decades ahead of its time. The class library (one of the first of its kind) was extremely sophisticated, with high-level frameworks for interface support, windowing, and graphics. Programming in Smalltalk was (and still is, in many ways) unlike any other system; making changes to code was fast and easy, and the turnaround time was very short, since the system incrementally incorporated changes as you made them. I was spoiled by the availability of well thought-out class library code that could be leveraged, and by the flexibility and ease with which new code could be written and existing code changed.

But now I was facing a new reality. Macintosh programs would be written in assembly code and Pascal, in a traditional edit-compile-link-debug cycle, and the dynamic nature of a system like Smalltalk was nowhere to be found. And my project was to be the Finder, the program that every Macintosh user would interact with to organize and manage their files, folders, and applications, which would be the "face" of the Macintosh.

The rigid nature of traditional programming bothered me. The idea of an application frozen in code, with no way to change anything dynamically, was anathema to my ideals. I wanted to be able to change as much as possible at runtime. Of course, the application code itself couldn't be changed, but what could be changed without having to recompile the code? The Finder, in particular, was going to need to maintain dynamic information about the files on the disk, and their relationships to the programs that created them and some of this information, such as a program's application and document icons, would have to be extracted from the program itself. How would this information be stored?