Revolution in The Valley [Paperback] Read online

The first version of the IBM PC was introduced in August 1981. Apple responded by running an ad in the Wall Street Journal with the headline “Welcome, IBM. Seriously.” Even though he was usually tight with money, Steve Jobs allowed the Mac team to buy an early IBM machine to dissect and evaluate. The day it became available, we ran to the store and purchased one to take back to the lab.

  Needless to say, we were not very impressed. From the perspective of the Macintosh that we were already in the midst of bringing to life, it seemed like ancient history the day it came out. There was little, if any, Woz-like cleverness in the hardware design. The IBM used dozens of extraneous chips without having any cool features. The 8088 was a decent processor compared to the 6502, but it paled next to the 68000 we were using in the Mac.

  But the clunkiest part of the system was the software. MS-DOS seemed like a clone of an earlier system, CP/M, and even the demo programs lacked flair. It came with some games written in BASIC that were especially embarrassing.

  The most embarrassing game was a driving game called Donkey that used low-resolution graphics. The player was supposed to drive a car down a slowly scrolling, poorly rendered “road,” and had the ability to hit the space bar to toggle the jerky motion. Every once in a while a brown blob filled the screen, which was supposed to be a donkey manifesting in the middle of the road. If you didn’t hit the space bar in time, you crashed into the donkey and lost the game.

  We thought the concept of the game was as bad as the crude graphics it used. Since the game was written in BASIC, you could list it out and see how it was written. We were surprised to see that the comments at the top of the game proudly proclaimed the authors: Bill Gates and Neil Konzen. Neil was a bright teenage hacker who I knew from his work on the Apple II (and who would later become Microsoft’s technical lead on the Mac project), but we were amazed such a thoroughly bad game could be co-authored by Microsoft’s co-founder, and that he would actually want to take credit for it in the comments.

  Desk Ornaments

  A brief history of desk accessories

  One of the first architectural decisions Bud and I made for the Macintosh system software in the spring of 1981 was that it would run only one application at a time. We barely had enough RAM or screen space to do even that, and we thought we’d benefit from the resultant simplifications. Besides, multitasking was supposed to be Lisa’s forte, and we didn’t want to usurp all of the reasons for buying a Lisa.

  Bud Tribble was usually on an even keel, but one afternoon in the fall of 1981 he came into my office, unusually excited. “You know, I’ve been thinking about it. Even if we can only run one major application at a time, there’s no reason we can’t also have some little applications running in their own windows at the same time.”

  That sounded intriguing to me. “What kind of little programs? How are they different?” I asked.

  Bud smiled. “You’d want tiny apps that were good at a specific, limited function that complements the main application. Like a little calculator, for example, that looked like a real calculator. Or maybe an alarm clock, or a notepad for jotting down text. Since the entire screen is supposed to be a metaphorical desktop, the little programs would be like desk ornaments, adorning the desktop with useful features.”

  “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” on page 63). After getting the initial implementations of the window, menu, and event managers going, we eventually had enough of the rudiments done to give desk ornaments a try by May of 1982.

  The control panel was compared to a “crib toy” by an early reviewer

  The nascent Mac operating system already had an implementation of loadable device drivers, which allowed code to 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 coexisting. The very first desk ornament was a boring example program called “TestOrn.” It displayed a rectangular window with an incrementing counter, showing that it was capable of doing background processing, even when it wasn’t the topmost window. It wasn’t very impressive, but it became the template from which all the others sprang.

  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 had been renamed “desk accessories” by the pubs group—they thought the term “ornament” was, well, too ornamental. I wrote a simple clock and got the calculator going, modeled after Steve Jobs’s design from the calculator construction set. The most interesting accessory I wrote in that spurt was a desktop pattern editor, which was a sort of miniature icon editor that let you edit an 8 × 8 pixel pattern by clicking to toggle the dots on and off. When you made a pattern 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. This 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 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 it could be done (see “The Puzzle” on page 186).

  But once again I had to get back to other things, and the desk accessories languished. By the spring of 1983, the ROM was beginning to stabilize, and we realized 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 backend 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 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 we call it the “Scrapbook,” which was perfect. And 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 rare characters, such as vowels with diacritical marks, that were not portrayed on the keyboard and 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 k
eyboard, with the keycaps changing depending on which meta-keys were pressed, and that allowed you to hunt for the special characters visually. He coded it up quickly and it became another great addition.

  We needed a way to control various system parameters such as the sound volume and the mouse-scaling parameters. We decided a desk accessory would be perfect for this since it would be easy to access no matter what application a user was in. The last desk accessory 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), which I implemented using a separate purgeable 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 standalone incarnation. Users could select from a couple dozen prefabricated desktop patterns or edit their own. It was this latter capability that caused problems, as it was pretty easy to create abominably ugly patterns.

  Bill Atkinson, the creator of MacPaint, 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. He couldn’t bear the thought of people creating ugly desktops. But I thought users should be free to do as they pleased because it was their desktop, plus they could always revert to one of the built-in patterns. In order to avoid having a potentially ugly desktop pattern mar MacPaint, he arranged it so MacPaint would allocate a window the size of the screen when it started up, and then fill it with the standard 50% gray pattern. This made his own desktop cover up the real one, and thus protected the poor users from their rash esthetic blunders, at least within the friendly confines of MacPaint.

  I Don’t Have a Computer!

  December 1981

  Bruce needs to find a computer, and fast

  contributed by Bruce Horn

  The Mac group was still very small when I joined it. We worked 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 on page 26”).

  The software group had offices on one side of the office building and the hardware group was on the other. Our offices were quite spare. One room toward the front of the building had a line printer (one of those big, noisy impact printers) that was driven by an Apple II. To print out your source code, 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 the disk in the Apple II which would then run the line printer.

  The Apple Lisa, which was the Macintosh’s predecessor

  Of course, to print out sources, you had to write some code. 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 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.

  Hungarian

  January 1982

  A curious style of programming

  The Macintosh used the same Motorola 68000 microprocessor as its predecessor, the Lisa, and we wanted to leverage as much code written for Lisa as we could. But most of the Lisa code was written in the Pascal programming language. Since the Macintosh had much tighter memory constraints, we needed to write most of our system-oriented code in the most efficient way possible. We did this using the native language of the processor: 68000 assembly language. Even so, we could still use Lisa code by manually translating it from the Pascal into assembly language.

  We directly incorporated QuickDraw, Bill Atkinson’s amazing bitmapped graphics package, since it was written in assembly language. We also used the Lisa window and menu managers, which we recoded in assembly language from Bill’s original Pascal, thereby reducing the code size by a factor of 2 or so. Bill’s lovely Pascal code was a model of clarity, so it was relatively easy to incorporate his programs.

  The Mac lacked the memory-mapping hardware prevalent in larger systems, so we needed a way to relocate memory in software to minimize fragmentation as blocks got allocated and freed. The Lisa word-processor team had developed a memory manager with relocatable blocks that accessed memory blocks indirectly through “handles.” The blocks could be moved as necessary to reduce fragmentation. We decided to use it for the Macintosh, again by recoding it from Pascal to assembly language.

  The primary author of the Lisa word processor and its memory manager was Tom Malloy, an original member of the Lisa team and Apple’s first recruit from Xerox PARC. Tom had worked on the Bravo word processor at PARC under the leadership of Charles Simonyi and had used many of the techniques that he learned there in his Lisa code.

  Even though Bud Tribble had to leave the Mac team in December 1981 in order to retain his standing in the M.D./Ph.D. program at the University of Washington, he decided he could still do the initial implementation of the memory manager and was hoping to finish it quickly before classes started. He obtained a copy of the memory manager source from Tom Malloy, but he had a shock when he began to read the code.

  Disappointingly, the memory manager source lacked comments. But the biggest obstacle was that the names selected for variables and procedures didn’t include vowels! Every identifier was an unpronounceable jumble of consonants, making it much harder to understand the code because each variable’s meaning was far from obvious. We wondered why the code was written in such an odd fashion. What happened to all of the vowels?

  It turned out that Tom Malloy was greatly influenced by his mentor at Xerox, a strong-willed, eccentric programmer named Charles Simonyi. Charles held many strong opinions about the best way to create software, and developed and advocated a number of distinctive coding techniques that Tom brought to the Lisa team. One of the most controversial techniques was a particular method of naming the identifiers used by a program that mandated the beginning of each variable name be determined by the type of the variable.

  However, most of the compilers in the early 80s restricted the length of variable names, usually to eight characters only. Since the beginning of each name had to include the type, there weren’t enough characters left over to use a meaningful name describing the purpose of the variable. But Charles had a sort of workaround, which was to leave out all of the vowels out of the name.

  The lack of vowels made programs look as though they were written in some inscrutable foreign language. Since Charles Simonyi was born and raised in Hungary (defecting to the west at age 17), his coding style came to be known as “Hungarian.” Tom Malloy’s memory manager was an outstanding specimen of Hungarian Pascal code in which the identifiers looked as though they were chosen by Superman’s enemy from the 5th dimension, Mr. Mxyzptlk. Bud decided it would be too error prone to translate the Hungarian memory manager directly into assembly language. To ge
t around this, he made a pass through it to strip the type prefixes and restore the vowels to all the identifier names (so you could read the code without getting a headache) before adding lots of block comments to explain the purpose of various subcomponents.

  A few weeks later, when Bud came back to attend one of our first retreats, he brought with him a nicely coded, efficient assembly language version of the memory manager, complete with easy-to-read variable names. These immediately became a cornerstone of our rapidly evolving Macintosh operating system.

  Calculator Construction Set

  February 1982

  Chris makes a Steve-approved calculator

  Chris Espinosa was one of Apple’s earliest and youngest employees, who started work for the company at the ripe age of 14. He left Apple in 1978 to go to college at UC Berkeley, but continued to do freelance work for them during the school year. This work included writing the official Apple II Reference Manual, the replacement for the legendary Red Book.

  In the summer of 1981, Steve Jobs convinced Chris to drop out of school to come work on the Mac team full time, arguing that he could go back to school anytime, but there would be only one chance to help shape the Macintosh. Chris did so to become the manager of documentation for the Macintosh, starting in August 1981.

  We needed technical documentation right away because we planned to seed third-party developers with prototype units in only a few months. Since the most important part of the Macintosh software was the QuickDraw graphics package, Chris decided to start documenting it.

  In order to better understand QuickDraw, Chris wanted to write a demo program using it. He got excited about little utilities programs that we called “desk ornaments,” which at that point were not yet implemented. He decided to work on a QuickDraw program to draw the calculator.