Revolution in The Valley [Paperback]

by Hertzfeld, Andy

  Tom and Vic proposed hiring me to write Macintosh software for Thunderscan. I knew that a low-cost scanner would be a great product for the image-hungry Macintosh, but only if it had sufficient quality. I told them I’d think it over during the next few days, and, as I did, I grew more excited about the potential of Thunderscan for the Macintosh, realizing the slow speed wouldn’t be an impediment if the quality and resolution were good enough. The low image quality in Tom’s prototype was probably caused more by the Apple II software than by anything inherent in the scanner. The Macintosh was almost 10 times faster than the Apple II, and I figured it should be able to sample the incoming data better to obtain more horizontal resolution. Plus, I knew a much better algorithm for grayscale rendering that would be fun to try out in practice.

  Thunderscan in action.

  My friend and colleague Bill Atkinson was a talented photographer, and one of his hobbies was experimenting to find the best algorithms for rendering digitized pictures. Bill loved to explain his current work to whoever would listen to him, and I had learned a lot about rendering grayscale images simply by being around him. Over the years Bill had progressed from using an “ordered dither” algorithm, which specified varying threshold values in a sliding matrix, to his current favorite, a modified version of what was known as the “Floyd-Steinberg” algorithm, which maintained and distributed an error term proportionally to neighboring pixels.

  I called Thunderware and told them I was interested in working on Macintosh software for Thunderscan in exchange for a per-unit royalty. I drove back up to Orinda, where Tom and Vic gave me lots of documentation about the scanner along with the sample code Tom had written for the Apple II. For the next couple of months, I drove up to Orinda once a week, usually on Thursday, to show Tom and Vic my progress, prioritize development issues, and discuss complications as they arose. We would also discuss business terms, but we didn’t sign a formal contract until the software was almost finished, when we settled on a royalty of $7.50 per unit.

  Tom and Vic had already encountered and surmounted a number of tough problems just to get scanning going at all. For example, the ImageWriter printer was not really designed to be stepped one scanline at a time. If you tried to, the paper would bunch up against the roller and cause distortion. Tom and Vic solved the problem by commanding the printer to move three steps up and then two steps back, instead of a single step up. This held the paper snugly against the roller as required. They’d also created techniques for sensing the beginning and end of the scan line, and some timings that were determined by tedious experimentation for how long it took the printer to respond to a command.

  It took a week or so to get basic scanning working on the Macintosh, and then a few more days to render the grayscale data with Bill’s modified Floyd-Steinberg dithering. After working out a few additional problems, involving synchronization between the printer and the software, I was impressed by the consistent high quality of the results. I went through a brief, elated phase of scanning every image in sight that would fit through the printer, just to see how it would turn out.

  One important design decision that I made early on was to save the grayscale data in a file in order to allow more flexible image processing. Thunderscan documents had 5 bits per pixel before the Macintosh generally supported grayscale, and the user could manipulate the contrast and brightness of selected areas of the image by dodging and burning to reveal detail in the captured image. This also paid off in later versions when we implemented grayscale printing for Postscript printers.

  My favorite feature that I came up with for Thunderscan had to do with two-dimensional scrolling. Thunderscan documents could be quite large and you could only see a portion of them in the image area of the window. You could scroll the image by dragging with a MacPaint-style “hand” scrolling tool, but you had to drag an awful lot to get to the edges of a large image. I decided to add what I called “inertial” scrolling. This allowed you to give the image a push and it kept scrolling at a variable speed in the direction of the push. I had to add some hysteresis (simulated inertia) to keep the image from moving accidentally, but I soon had it working and it felt great to be able to zip around large images by pushing them.

  The hardest feature to perfect was bidirectional scanning. At first, Thunderscan scanned only from left to right, and it wasted time to return the scanner to the left after every scan line. We could almost double the speed if we scanned in both directions, but it was hard to get lines scanned in opposite directions to line up properly. Ultimately, we made bidirectional scanning an optional feature for those willing to trade a little quality for greater speed.

  I finished the software in November 1984, after taking a short break to work on my Switcher project (see “Switcher” on page 243). Thunderscan shipped in December 1984 and did well from the very beginning, with sales gradually rising from around 1,000 units/month to over 7,500 units/month at its peak in 1987. For a while, it was both the least expensive and highest-quality scanning option for the Macintosh, although I’m sure it frustrated a lot of users by being so slow. I did three major revisions of the software over the next few years, improving the scan quality and adding features like grayscale printing and, eventually, grayscale display for the Macintosh II.

  Eventually, the flat bed scanners caught up to Thunderscan and then surpassed it in cost, quality, and convenience. Over its lifetime, Thunderscan sold approximately 100,000 units and improved countless documents by providing users with an inexpensive way to capture high-resolution graphics with their Macintoshes.

  October 1984

  The Macintosh’s first multitasking environment

  The first commercial product I worked on after going on leave of absence from Apple (see “Leave of Absence” on page 229) was a low-cost, high-resolution scanner for the Macintosh called Thunderscan. I created Thunderscan in collaboration with a tiny company named Thunderware. I started working on it in June 1984, and by early October, it was almost complete.

  Tom Petrie, one of the two principals at Thunderware (the other was Victor Bull, who I worked with on my first project for Apple, the Silentype thermal printer), arranged a few demos for various computer magazines in hopes of currying favorable reviews to promote the product. On October 11th, 1984, I drove with Tom to an office in Hillsborough, just south of San Francisco, to demonstrate Thunderscan for Byte magazine.

  The Byte reviewer was John Markoff, a technology scribe for the San Francisco Chronicle and one of the best reporters covering the personal computer industry. Tom described Thunderscan while I set up the demo and started scanning. John asked a few questions, taking notes with his IBM PC, which was running a character-based text editor I viewed with the typical pious disdain of a Macintosh purist. As I was answering one his questions, the phone rang.

  “Excuse me,” he said. He then pressed a key combination on his keyboard and his monitor screen instantly changed to a different program. He talked on the phone for a minute or two, occasionally typing, before he finished the conversation and pressed a key combination to switch back to his Thunderscan notes.

  “What did you just do?” I asked John, curious about the software that he was running. “How did you switch to another application so quickly?”

  “Oh, I’m running Memory Shift. Haven’t you seen it?” John responded. “It’s a DOS utility program that keeps multiple applications resident in memory and allows you to switch between them quickly. I’ve been using it a lot lately.” John typed the switch command a few times in rapid succession in order to show me how fast it could do its thing.

  “You know, I think I could do that for the Macintosh,” I suddenly blurted out, before I even thought about what I was saying.

  The 512K Macintosh, with four times the memory of the original, had just started shipping a few weeks earlier. I had considered trying to run multiple applications simultaneously on the 512K Mac, but I was stymied by low memory conflicts and other potential “gotchas.” But now, as I observed M
emory Shift in action on John’s PC, I suddenly saw a simple way to do it.

  “Yeah, that would be cool,” John agreed. I continued with the Thunderscan demo, but it was hard for me to concentrate because I couldn’t stop thinking about application switching. There were a few intricate problems to solve, but it seemed eminently doable, and I thought it would be incredibly useful if I got it to work.

  Tom Petrie didn’t fail to notice how excited I was about the new idea. As we drove home, he reminded me of my prior commitments and made me promise I would finish the alpha release of Thunderscan before daring to start something new. We agreed on a list of a dozen or so tasks, which I thought I could accomplish within two weeks. Once the alpha release was completed, he assured me, I could take a short hiatus, in order to work on application switching.

  During the next two weeks, I focused on polishing Thunderscan to get it ready for the alpha release, but I also spent idle moments pondering the design of the application switcher. One fundamental decision I had to make was whether or not to load all the applications into a single heap—which would make optimal use of memory by minimizing fragmentation—or to allocate separate “heap zones” for each application. I decided to opt for separate heap zones to better isolate the applications, but I wasn’t sure that was right.

  There were lots of little problems to solve. The most crucial one was that the system software kept lots of application-specific global variables in low memory (see “Mea Culpa” on page 258), which needed to be swapped during context switching so each application could maintain its own set of them. The hard part was coming up with the precise list of exactly what needed to be swapped; many of the variables were obvious, but some were quite subtle and dependent on how applications were using them. I knew that my first cut wouldn’t be perfect, but I was confident that I could debug the inevitable problems once I saw how the applications were actually failing.

  A few days after starting the push to finish Thunderscan, I received an intriguing phone call from Jeff Harbers, the manager of Microsoft’s Macintosh applications team. Jeff told me that Microsoft had a very strategic project they needed for the Macintosh, and they thought I was the ideal person to implement it. He wouldn’t tell me anything else over the phone, but he offered to fly me up to Seattle to discuss it in person. Even though I was right in the middle of trying to complete Thunderscan, I was intrigued enough to accept his offer and arranged to visit with him the following Tuesday.

  Jeff picked me up at the airport and we drove to Microsoft’s main building where Neil Konzen, a talented 23-year-old who was Microsoft’s main systems programmer on the Macintosh, joined us. I knew Neil from his days as an early Apple II hobbyist when he was only 16 years old, when we collaborated on adding features to an assembly language development system.

  Jeff asked me what I was working on and I told him about Thunderscan, which he seemed to be interested in. But when I mentioned I was about to start some experiments with an application-switching utility, his jaw dropped.

  “That’s just what we wanted to talk with you about!” he exclaimed. “It’s great that you’re already working on it.”

  Jeff explained that Microsoft had put a lot of effort into getting their applications to run well in the tiny space available in the 128K Macintosh, which they considered to be a key competitive advantage. But as things stood, the 512K Mac would undermine their efforts because it allowed for much larger applications. Plus, Lotus had recently announced an integrated application suite for the 512K Macintosh called Jazz, which made it easy to switch quickly between different functional areas. But if the Macintosh could run multiple applications simultaneously, the small memory footprint of the Microsoft apps would continue to be advantageous, since their lower memory requirements meant more of them could run concurrently, and users could put together customized application suites on their own. The purpose of the visit was to convince me to write an applications switcher under contract to Microsoft.

  Neil Konzen had contemplated a potential design, which he conveyed to me in front of a whiteboard. He decided to use the single heap approach I had rejected, along with a few interesting twists to minimize memory fragmentation. I told him about the alternate approach of using separate heap zones, and how I thought it was probably worth it to trade some memory fragmentation for greater robustness. I told him I would give his approach some more thought.

  “You’re a really good programmer, right? I think you must be a really good programmer... How long do you think it will take to do this project? A month or two?”

  Finally, my afternoon at Microsoft culminated in a private meeting with Bill Gates. Jeff ushered me into Bill’s office and reviewed the afternoon’s discussions for him, before excusing himself to leave us alone to negotiate a development deal. I had met Bill a few times during the course of Macintosh development, and while I respected his understanding of technology, I was wary of his burgeoning reputation as a conniving businessman.

  After we had exchanged a few pleasantries, and he told me how much the Macintosh mattered to Microsoft, he looked me in the eye and said, “You’re a really good programmer, right? I think you must be a really good programmer.”

  “I guess so,” I responded, not understanding why he was attempting to flatter me.

  “Well, I think you are. How long do you think it will take to do this project? A month or two? I think a really good programmer like you could get it done in less than two months.”

  “I really have no idea,” I replied. “I’m not far enough along to know if it’s even feasible yet.”

  “Well, let’s figure it out,” he said in a slightly condescending tone. “I don’t think it could be more than 10,000 lines of code, and a really good programmer like you should be able to write at least a thousand lines of code per week, so I think it will take you less than 10 weeks to write it, if you’re as good as I think you are.”

  I didn’t know how to respond, so I kept quiet and let him continue.

  “And how much do you think a really good programmer should get paid? Around here we pay our best programmers around $2,000 per week. Do you think you should be paid more than that?”

  “I don’t know,” I replied. I was finally beginning to see where he was coming from. Bill was trying to get me to brag that I could write the application switcher really quickly, so he could justify paying me a lower price for it.

  “Well, I don’t think you could expect to get more than $4,000 per week, tops. Actually, I think that’s too much, but let’s go with it. If it takes ten weeks, and you get paid $4,000 per week, you’d get paid $40,000 for writing it.”

  Forty thousand didn’t sound like very much to me, especially if it was as strategic to Microsoft as it seemed to be. I think Bill was expecting me to make a counteroffer, but I wasn’t very enthusiastic about selling the switcher to Microsoft regardless of compensation, since I thought it should eventually be part of the Mac OS.

  “...A really good programmer like you should be able to write at least a thousand lines of code per week, so I think it will take you less than 10 weeks to write it, if you’re as good as I think you are.”

  “Listen, I really want to write this completely independently from you guys, so you won’t have to pay me anything to do it. I certainly don’t want to negotiate a deal until I see how it turns out; there might be a showstopper and I won’t be able to get it to work at all. And if I pull it off, it really should be bundled with every 512K Macintosh.”

  Bill shifted his tactics. “OK, I don’t really care if Microsoft owns it as long as it’s available to our users. I want you to commit that you’ll apply your best efforts to making sure it runs well with our applications, and that you’ll call Jeff if you run into any snags. We can talk again about publishing it later, if you want to, after you’re further along. How does that sound?”

  I told him it sounded good and promised to do my best to make it work with Microsoft’s applications, which I wanted to do anyway, since the Mic
rosoft apps were important to most users. We shook hands and I departed on a positive note.

  By the time I returned home that evening, I was burning with the desire to see if I could get something going quickly. Even though I still had a few more days of work to complete the Thunderscan alpha release, I decided to see if I could write a proof of concept prototype of the application switcher first.

  I would eventually have to write a user interface for selecting applications, but the proof of concept didn’t have to worry about that; it was hardwired to run MacPaint, MacWrite, MacDraw, and the Finder. I worked for 20 hours straight writing the core of the program, which worked by patching traps to extend a few essential system calls, such as GetNextEvent, Launch, and ExitToShell. The hardest part was going through all of the low memory locations and determining what needed to be swapped. Even though it was crashing all the time, it was incredibly satisfying to see it begin to work and then stabilize as I tracked down various problems.

  I had it working for an hour or so when I saw Bud Tribble, who lived next door to me, return home. Bud had finally finished his M.D./Ph.D. program at the University of Washington, and had even interned for a year, but he decided working on the Macintosh was more fun than being a doctor, and he had returned to Apple in his old job as software manager a few months earlier. Bud was living at Burrell Smith’s house, which was next door to mine.