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

"I can't believe Bob gave you that review", Steve started talking even before I stepped into his office. "He showed it to me a week ago, but I refused to approve it, and I told him to write something more positive. Do you have a copy of it?"

I told Steve that he didn't give me a copy, he just delivered it verbally. I told him that I couldn't work for someone who feels that way about me, and that I had no alternative but to quit.

"It's good that you don't have a copy, because that review is rescinded, it doesn't officially exist. I just got done talking with Bob, and after I chewed him out, he also quit, because he said that he can't manage the software team. And Capps came in here and told me that the rest of the software team is so upset that they're thinking about quitting, too. What a mess! You and Bob don't have to love each other to work together. We're going to sit down this afternoon and talk this thing out until it's resolved."

So, at 4pm on Friday afternoon, as soon as Steve was available, the entire software team, plus Burrell, filed into one of the conference rooms. We all sat in a semi-circle of chairs on the right side of the room, waiting apprehensively. Finally, Steve strode in, with his characteristic bouncy stride, trailed by a despondent looking Bob Belleville, who took a seat on the left side of the room, facing the software team.

Steve started talking first, saying that tensions had been building up for a while, and it was time to clear the air, so we could all pull together down the home stretch. All the while, Bob was staring at the floor, unwilling to make eye contact with anyone else, controlling his emotions behind a tight-lipped expression, halfway between grin and grimace.

"OK, who's going to go first? What's the problem, and how do we fix it?", Steve asked.

Capps spoke up, explaining how painful and unmotivating it was to see me broken up about an obviously unjustified review. He wanted to know how things could have gotten so screwed up.

Steve nodded to Bob, encouraging him to speak up. Bob spoke in a monotone. "I didn't give Andy a bad review. I told him that his work was fine."

I was flabbergasted. "You said I was undermining the team, and stifling Larry," I blurted out. "I can't work for you if you think I'm undermining the team."

Bob looked up, looking me in the eye for the first time. He spoke in a mild, low emotionless monotone. "I didn't say any of those things. Why are you claiming that I said that?"

I was shocked. Bob was denying what he told me the day before, and I know that I didn't imagine it. Furthermore, he really seemed to genuinely believe what he was saying, and he looked to be in a kind of trance, both depressed and confused. If he didn't acknowledge what he said to me, there was no way to resolve it. I didn't know how to proceed, so I backed off my accusations.

A few more people spoke up, addressing other grievances, but Bob's trance-like manner persisted and eventually the meeting broke up, without anyone being satisfied. Steve tried to declare victory at the end, but no one was buying it.

I thought about things over the weekend, and realized that I cared too much about the Macintosh to quit before it was finished, managerial adversity notwithstanding. The situation that I feared when Bud left had actually occured, in spades, and I wasn't confident that Steve would live up to his promise to protect me. I wasn't sure what was going to happen, but I knew that my blissful days at Apple were over, and that things were going to be different from now on.

Bouncing Pepsis

by Andy Hertzfeld in March 1983

We added Pepsi Icons for John Sculley's visit

The Window manager was the one of the most important parts of the User Interface toolbox, and the ultimate showcase for Quickdraw's "region clipping" technology. The window manager had to calculate various regions for windows as they were created, moved and resized, and objects drawn inside the windows were automatically clipped as necessary.

The Macintosh window manager was based on the one that Bill Atkinson wrote for Lisa, which was written in Pascal; my job was to rewrite it in 68000 assembly language and adapt it to the Macintosh environment. The first step was to port Bill's Pascal version. I wrote a little program to test the port, which I called "Window Manager Demo", that generated some windows and put the window manager through its paces.

A year earlier, I had written a fast "ball bouncing" routine, using custom, 16x16 pixel graphics routines, that could animate hundreds of balls simultaneously, which was a fun way to show off the Mac's raw graphical horsepower. I decided to animate a few dozen balls in each window in the window manager demo, using Quickdraw, because their continuous movement would eventually cover all the bases inside a window and expose any flaws in the underlying clipping.

After Susan started in January 1983, I asked her to draw some tiny 16 by 16 bitmaps to use in the Window Manager Demo instead of the by now monotonous ball shapes. Soon, we had a variety of little objects bouncing around in the various windows, like tiny little Macintoshes, or apples, insects and alligators. I thought that the Window Manager Demo was finished, but I was wrong.

Steve Jobs came by the software area one evening a couple of months later, excited about someone he had recently met in New York City. "Hey, I want you to do a demo next week for this guy I met yesterday, John Sculley, he's the president of Pepsi. He's really smart - you wouldn't believe how smart he is. If we impress him, we can get Pepsi to buy thousands of Macs. Maybe even five thousand. Why don't you try to come up with something special to show him?".

It sounded a little bit fishy to me, since we hardly ever demoed to potential customers at that point. But I asked Susan to draw some Pepsi imagery, and she came up with tiny little Pepsi caps, as well as Pespi cans, in his honor, so I put them into the Window Manager demo.

The next week, Mike Murray led John Sculley around the engineering area, since Steve was out of town. He brought him by my cubicle to see the modified Window Manager demo. I opened the windows one at a time, saving the Pepsi caps and cans for last. He seemed genuinely excited to see the Pepsi stuff, but oddly cold for most of the demo. He asked a few questions, but he didn't seem all that interested in the answers.

A few weeks later, we found out the real story - the purpose of John's visit was to interview for CEO of Apple, and he got the job, being convinced by Steve's famous line "Would you rather sell sugar water to kids for the rest of your life, or would you like a chance to change the world?".

RMaker

by Andy Hertzfeld in March 1983

The resource manager became stable enough for other parts of the Toolbox to use in the fall of 1982. At first, only the dialog manager (which was also written by Bruce Horn) used resources, but soon they began to spread inexorably throughout the system. By early 1983, we were using resources to define windows, menus and controls, but we didn't have a decent way for developers to specify them.

Bruce had written a "dialog compiler" that read in a terse text-based description of a dialog and created the corresponding dialog resources. In February 1983, I expanded it into a general resource building tool that I called "RMaker", which ran on a Lisa and built a resource file from a text-based description. RMaker allowed arbitrary resources of any type to be specified in hexadecimal, and provided some specialized formats for specific types like windows or menus. For an example of an RMaker source file, click
here
to see MacPaint's resource definition file.

The Macintosh was built around the Motorola 68000 microprocessor, which was an amazing chip for its day, but it did have a few problematic limitations. The instruction set was missing a way to specify a long relative branch, and absolute branches were forbidden since we needed our code to be position independent. This meant that the maximum size of a hunk of code was limited to the range of a relative branch, which was 32K bytes.

That wasn't nearly enough big enough for Lisa applications, so the Lisa development system supported multiple code "segments", stitched together with a jump table for inter-segment references. Since the Macintosh had much less memory than the Lisa, I thought that we could forgo more complicated machinery and get away with supporting only a single code segment per application, and that's what we did at first. But of course I was wrong.

In March 1983, Jerome Coonen came to me with a worried look on his face. Apparently, three different developers started running up against the 32K code size limitation all at once, and he didn't know what we could do about it. The schedule was already barely achievable, and it didn't seem possible to implement a multi-segment loader in the required time frame. He asked me what I thought we should do.

Even though I hadn't thought much about it before, it seemed clear to me that we should keep the code segments in resources, since that's what we were doing with just about everything else these days. We'd have to write a little bit of tricky code to create, load and maintain the jump table, but that didn't seem so bad. I told Jerome that I thought I could have a resource-based multi-segment loader going in less than a week.

Jerome was surprised, thinking that it would take at least a month and asked me to get going on it right away. I was a little hesitant, since my bad review from Bob Belleville a week or two ago was still fresh in my mind (see
too big for my britches
), which made me less inclined to put in another heroic effort, but as usual I got excited about the new approach and dove in to try to accomplish it.

The hardest part of the job was writing a tool to extract the code from the output of the Lisa linker and turn it into code resources. I was still working on polishing RMaker, and I realized that it was the perfect place to do the job. I added some code to RMaker to build code resources and the jump table from object files, and was able to get a proof of concept multi-segment loader working in just a few days.

The Lisa linker supported two different sizes of jump table entries. There was a 6 byte version, that just consisted of a single long jump instruction, to an absolute but virtual memory address, which relied on the memory management of the underlying OS to load the appropriate code. The Macintosh didn't have any memory management hardware, so that wasn't possible for us. Luckily, the linker also supported a 10 byte version, which didn't rely on virtual memory and made an explicit OS call to load the segment, which is what I used for my initial version.

It took four bytes to invoke a Lisa system call, but the Macintosh could do it in 2 bytes using a 'trap' instruction, so we really only needed 8 bytes per jump table entry. 8 bytes was a lot better than 10, since not only did it save precious memory, but it would keep everything aligned to 32-bit boundaries, which would eventually be important. I thought it would be simple to modify the Lisa linker to support an 8 byte/entry jump table variant, but I didn't have the source code, so I requested that the Lisa group make the change for us.

But the engineer on the Lisa team that was responsible for the linker, who will rename nameless in this account, wasn't a fan of the Mac project and claimed that he had other, higher priority tasks to accomplish before he could get around to it. He also refused to give me the source code, so I couldn't simply do it myself. After a week or so, I grew tired of waiting, and thought of a wild hack that would let me move forward without him.

The problem was that the linker generated jump table offsets for every inter-segment procedure invocation. Since it thought that the jump table had 10 bytes/entry, I had to find and correct every jump table reference, multiplying it by 8/10 to adjust it for the 8 byte/entry jump table. The jump table was only referenced by a few, specific op-codes, so I added a routine to RMaker to scan through the object code, identifying jump table references and patching them. This wasn't bullet-proof, since the patch routine couldn't tell code from in-line data, so it might inadvertently patch something it shouldn't, despite the extra sanity checks that I threw in. But I thought I could get away with it for the short while before a modified linker became available.

Even though I made repeated requests, the Lisa linker engineer didn't implement the 8 byte version of the jump table for more than nine months. In fact, he never did, but in early 1984, he transferred to another project, and Barry Haynes, the engineer who replaced him, was able to accomplish it a few days after taking over the job, just as I was going on my leave of absence in March 1984, so we were finally able to eliminate RMaker's ugly hack. It was a miracle that no one ever stumbled over it, at least as far as I know.

I went on leave of absence from Apple in March 1984 (see
leave of absence
), but I still was excited about writing software for Macintosh as an independent developer, and was full of ideas about different programs to write. But I wasn't happy about the fact that you still needed a Lisa to write software for the Mac; among other things, the recent linker problem had left a bad taste in my mouth regarding the Lisa development system. I had a Lisa at my house, but it really belonged to Apple, and I didn't want to have to buy one. I decided to try to cobble together an entirely Mac-based development system.