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

Alan Kay always said that any problem in Computer Science could be solved by adding another level of indirection. I thought that if we could refer to the program *data* separately and indirectly -- the strings, bitmaps, window and dialog layouts, and other non-code information -- we could make it possible for this information to be changed by people who would not have access to the source code. These people -- translators, artists, and designers -- would be able to change the text strings (to translate menu items from English to Norwegian, for example), modify the application and document icons, and replace graphical elements in the program, if the program were written such that these items were factored out of the application.

The ability to easily localize applications and the operating system would be novel, especially in the early 1980's. None of the systems that I had used, including Smalltalk, had this ability; it was just assumed that everybody using the system would be English-speaking, and that other countries would be building their own systems. If the Mac were able to be released in other countries, with menus, icons, dialogs, dates, and sorting orders translated to different languages, it would make a big improvement in our potential market share. I can't even remember when I started to recognize that the localization ability was necessary; it was a meme (probably started by Joanna Hoffman) that infected us all in the Mac group.

I figured that the Mac should provide this facility for all developers as a part of the User Interface Toolbox: a way to both provide for factoring out non-program data to make it easy to write modifiable applications, as well as manage memory on a fine-grained basis, object by object. Thus the idea for Resources was born.

Resources

The Resource Manager was a solution to several problems: managing dynamic data for the Finder; factoring out localizable information (strings, icons, and so on) from applications, and finally, managing memory use as frugally as possible. The Mac had relatively little memory, only 128K, for both the system and whatever application was running. The floppy drive was only 400K, and would have to store the system, applications, and documents, so anything that could reduce the amount of space required, by sharing data, would have a big impact. Graphics were notoriously memory-hungry, and the Finder, in particular, would have to juggle icons, swapping their bitmaps in and out of memory as required. The Resource Manager would have to handle each of these small entities separately. Thankfully, I knew of a similar system in Smalltalk, an object-oriented virtual memory called OOZE that was designed by Ted Kaehler, that swapped objects in and out of main memory as required. This was my inspiration for the Resource Manager. Find out more about OOZE
here
.

Like OOZE, the Resource Manager maintained objects in a resident object table, called the resource map. A resource file was the on-disk representation of the resources. Resources would be typed: a menu object would be of type MENU, and a text string would be of type TEXT. Resource types were four bytes, to fit within a single 32-bit word as well as to be somewhat human-readable. All resources would have a resource ID, unique within the type domain of the resource file, and any resource could also be named, for the convenience of the programmer.

As it happened, our memory manager provided a mechanism that the Resource Manager could leverage for in-memory storage of a resource object: the handle. A handle was a relocatable block of memory, referenced by an indirect pointer (a pointer to a pointer). To allow resources to be purged from memory, blocks could be reclaimed, releasing memory for other uses, while maintaining the original indirect pointer which would then point to a nil value, indicating that there is no block of memory reserved. This allowed objects to be referenced by unique handles whether or not they were currently in memory, greatly simplifying the task of managing dynamically-loadable objects.

I wanted to make sure that we could leverage resources throughout the system, but with maximum flexibility. I felt that it was important that there be a mechanism for system resources to be overridden by the application, and for application resources, in turn, to be overridden by the application's open documents. We could then have documents that carried their own fonts, images, and so on; applications with application-specific resources, such as (again) fonts and images; and system resources that would be shared by all applications. So, resource files would be linkable, staging resource lookup: searching first the document, then the application, and finally, the system.

One of my faults as a software designer is that I seem to try to solve the biggest problems, and to do it bottom-up; that is, I end up doing lots and lots of work with no apparent results, as I build the foundation for the rest of the system. I ended up making the Finder dependent on the Resource Manager, which, while logical in fact, unnecessarily made things a bit more exciting than they otherwise would have been in the development of the Mac, as the Finder's development was pushed out later and later in the schedule. And of course, I didn't come up with these ideas all at once, but as I gained experience with the idea of resources, and as others in the group began to use resources in the rest of the system, the features needed became apparent. And the concepts behind the Resource Manager widely influenced the handling of data throughout the Mac in a sort of Grand Unified Model.

When I started talking with the rest of the team, Larry Kenyon and Andy Hertzfeld realized immediately the importance of resources, and realized that they'd have to make changes in the rest of the system to take advantage of the Resource Manager. Larry was writing the memory manager, and Andy was writing much of the rest of the Toolbox; both were rather far along and the Toolbox, in particular, needed significant changes to use resources. We were all in agreement...but I failed to mention this to Bob Belleville, thinking that it wouldn't take that long to finish anyway, so why bother?

I started writing the code. Some weeks later, Bob Belleville asked me what I was doing, and I told him about the Resource Manager and why we needed it. He told me to stop working on it. I was flabbergasted. I tried to explain to him that the Resource Manager was the keystone of the entire data architecture of the Mac--that the Toolbox, Segment Loader, and the Finder were all dependent on it, and I couldn't think of a way to solve all the problems we needed to solve without something like the Resource Manager.

Bob told me to abandon the project, that we didn't need it, and that I should focus on the Finder (see
resource manager countdown
). Of course, the way I planned to fit all the pieces together with the Finder also required the Resource Manager, and I thought it would take much longer to try to code the system without it. I told Bob that I was going to do it anyway. (see
you can't fire bruce!
).

It was quite a job, since we only had 64K bytes of ROM for the entire Toolbox. By writing in assembly code, I was able to implement the complete Resource Manager in only 3K bytes of code, leaving a few bytes left over in the ROM for the inevitable bug fixes and feature additions. But it had taken quite a bit longer than I had hoped it would, and the delay put time pressure on all of us.

We were lucky: it turned out that resources were the answer to quite a few questions we hadn't known to ask. Andy used the Resource Manager to swap code segments dynamically, so that large programs could run in the tiny amount of RAM; he rewrote the Font, Menu, and Control managers to store and retrieve their data from resource files; and more and more shared data in the system ended up being stored as resource objects. Because it was relatively simple to use resources to store text strings and menus in the system and in applications, it became much easier to provide localized systems for different languages and countries. Joanna Hoffman and Alain Rossmann designed a resource-based system for handling special time and date formats for different countries, and the Mac became a truly multilingual system.

Almost every piece of data in the Macintosh ended up being touched by the Grand Unified Model. Even transient data, data being cut and pasted within and between applications, did not escape. The Scrap Manager labeled each piece of data on the clipboard with a resource type. In another Mac innovation, multiple pieces of data, each of a different type, could be stored on the clipboard simultaneously, so that applications could have a choice of representation of the same data (for example, storing both plain and styled text). And since this data could easily be stored on disk in a resource file, we were able to provide cutting and pasting of relatively large chunks of data by writing a temporary file called the Clipboard.

So, in late 1982, with the Resource Manager finished, more or less, I finally turned my attention back to the Finder (see
the grand unified model (2) - the finder
).

Hungarian

by Andy Hertzfeld in January 1982

Charles Simonyi in the early days

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, using the native language of the processor, 68000 assembly language. Even so, we could still use Lisa code by hand translating the Pascal into assembly language.

We directly incorporated Quickdraw, Bill Atkinson's amazing bit-mapped graphics package, since it was already written mostly in assembly language. We also used the Lisa window and menu managers, which we recoded in assembly language from Bill's original Pascal, reducing the code size by a factor of two or so. Bill's lovely Pascal code was a model of clarity, so that was relatively easy to accomplish.

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, accessing memory blocks indirectly through "handles", so 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 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 that he could still do the initial implementation of the memory manager, as we were planning all along, hoping to finish it quickly after he moved back to Seattle, before classes started. He obtained a copy of the memory manager source from Tom Malloy, but he was in for a shock when he began to read the code.

The memory manager source lacked comments, which was disappointing, but the biggest obstacle was the names selected for variables and procedures: all the vowels were gone! Every identifier seemed to be an unpronounceable jumble of consonants, making it much harder to understand the code, since a 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 turns out that Tom Malloy was greatly influenced by his mentor at Xerox, a strong-willed, eccentric programmer named Charles Simonyi. Charles was quite a character, holding many strong opinions about the best way to create software, developing and advocating a number of distinctive coding techniques, which Tom brought to the Lisa team. One of the most controversial techniques was a particular method of naming the identifiers used by a program, mandating that the beginning of each variable name be determined by the type of the variable.

However, most of the compilers in the early eighties restricted the length of variable names, usually to only 8 characters. 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 work-around, which was to leave out all of the vowels out of the name.

The lack of vowels made programs look like 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, with the identifiers looking like they were chosen by Superman's enemy from the 5th dimension, Mr. Mxyzptlk.

Bud decided that it would be too error prone to try to translate the Hungarian memory manager directly into assembly language. First, 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 sub-components.