The Original Macintosh:    57 of 122 
The Grand Unified Model (2) - The Finder
Author: Bruce Horn
Date: January 1983
Characters: Bruce Horn, Larry Kenyon, Steve Jobs, Frank Ludolph, Steve Capps, Dan Smith, Bill Atkinson, Andy Hertzfeld
Topics: Software Design
Summary: The evolution of the Finder
The Finder

One of the first things I did when I joined the Mac group was to begin working on the Finder. The first Finder, written in early 1982 with Andy's help, was a simple diskette image with tabs that represented the files on the disk. (see Early Demos). This Finder was the first to begin to take advantage of the idea of spatial organization: you could drag the tabs around and place them wherever you wanted on the floppy image. Also, my experience with Smalltalk showed through: the big "Do It" button was named after the Do It menu item in Smalltalk, which evaluated a selected expression. This Finder was actually usable, and served as a placeholder until the real Finder was available.

Immediately after the first Finder prototype, I wrote a second which was much more recognizable as the ancestor to the Finder that shipped. This prototype was a nonfunctional prototype that did not actually read the disk, but instead, read a text file that described a hierarchy of files within folders that would be displayed in windows. Our filesystem at the time did not have the concept of directories, so I had to fake it with the proof-of-concept prototype. This was the first Finder that provided double-clicking to open folders, documents, and applications; drag-and-drop to move files between folders; icon and list views; and persistent spatial locations of icons within windows. Of course, it was all window-dressing and none of it was functional, but it did give a good idea of what we would eventually want to implement. Unfortunately, it also made it look like the actual Finder implementation would be easy, which it most definitely was not.

Bill Atkinson came by and I gave him a demo. He had been thinking about the Lisa Filer, which was being written by Dan Smith and Frank Ludolph, and was dissatisfied with its design. When he saw in our Finder mockup some of the ideas that he had also seen in a MIT project called Dataland, he was convinced, and the IF (Icon Filer) project was born (see Rosing's Rascals). Bill, Dan and Frank put together a new Filer based on these concepts in time to ship with the first Lisa in 1983. In the meantime, I was working on the Resource Manager until later that year.

But I still couldn't get started on the Finder until I figured out how to handle files and applications. We were trying to make the Macintosh a very friendly computer, an information appliance, something that everyone could use. For example, one of the things that I felt could stand improvement in the current computing experience was the problem of filenames. In the Finder, I wanted to make it as easy as possible to give meaningful names to files without excessive restrictions placed on them.

At the time (and still, in some cases, now) filenames were very restricted, both in length and in format. Filenames had to have a three character suffix, with a dot, to denote their file types: text files were named "myfile.txt" and executable applications were named "word.exe". Filenames were also typically limited to eight characters, not including the suffix; this led to very cryptic naming on other computers, which we definitely wanted to avoid.

We decided that we needed to allow users to name their files whatever they wanted, with any characters, including spaces. Because the Finder would allow the user to simply click on a particular file to choose it, special characters like spaces would be no problem; in command-line systems, parsing filenames with special characters could be problematic.

The Grand Unified Model provided a framework for solving this problem too. Since resource objects were typed, indicating their internal data format, and had ID's or names, it seemed that files should be able to be typed in the same way. There should be no difference between the formats of an independent TEXT file, stored as a standalone file, and a TEXT resource, stored with other objects in a resource file. So I decided we should give files the same four-byte type as resources, known as the type code. Of course, the user should not have to know anything about the file's type; that was the computer's job. So Larry Kenyon made space in the directory entry for each file for the type code, and the Mac would maintain the name as a completely independent piece of information.

Simply storing the file type in the directory was not enough, however. There might be many different applications that could open files of a given type (say, a text file); how would the Mac know that a text file called "My Resume" needed to be opened in MacWrite, and another text file called "Marketing Plan" needed to be opened in WriteNow? Just knowing the file's type wasn't enough; the Finder also had to know which program created the file, and thus would be the best choice to open it. Thus another four-byte "creator code" would also be maintained, which would tell the Finder which program needed to be launched to open a particular document. For convenience, the user could also easily override this default, by dragging the document to whichever application he would like.

Finally, we also wanted to have useful and meaningful icons for programs and documents on the Mac. Using the type and creator mechanism, this was easy; we would just associate a specific icon for each file type that is handled by a particular application. Given a (type, creator) pair, it would be easy to look up the appropriate icon to draw for the file.

But where would these icons come from, and where would they be stored? It seemed clear that each program would be responsible for defining icons for the application and its documents, and that this information should be stored in the application itself; but if we simply opened the application's file each time we needed to draw an icon, the Finder would be terribly slow. I decided that the Finder needed to cache these icons and associations in a resource file. This was the Desktop Database.

The Desktop Database

Programmers reading Macintosh technotes on the Resource Manager would run across the statement that "The Resource Manager Is Not A Database!" This is ironic, because one of the very first uses of the Resource Manager was in fact for a database: the Desktop Database, which stored and maintained information relating to applications, documents, and their respective icons.

Applications would include a set of resources with known ID's in their resource map; this group of resources would collectively be called the application's Bundle, and it would have the type BNDL. In the bundle were special FREF resources (file references) that would map a document or application type to an icon ID.

When the Finder would encounter an application on a disk, it would look into the Desktop Database to detemine whether it had already seen this application and copied its bundle. If not, it would copy the bundle and associated icon and FREF resources, and reassign the ID's of the icons so that they would be unique within the database. The FREF resource provided an indirect ID mapping to make this possible. In this way, all bundles could be readdressed within the database and there would be no conflict between the different resources pulled in from a variety of applications.

Drawing the image of a particular document was then a simple matter of looking up the appropriate icon by type and creator in the Desktop Database, and loading the resource. On the 400K disk, this worked very well--the Resource Manager was up to the task, and it wouldn't show its limitations for several years--an eternity in the software world.

The Final Push

By late 1982, the Lisa Filer was nearly finished. At 360K, it was a significant application--much too large for us to use, and it wasn't based on the Grand Unified Model of types, creators, and resources. Although Bill offered us the code to the Filer, we always knew that we'd be writing our Finder from scratch.

The Mac was to ship in January, 1984, our final drop dead date. In late 1983 it became clear that I needed help to finish it in time, and Steve Capps was recruited to work with me on the Finder (see Steve Capps Day). Also by this time, reporters, writers, and associated VIPs were being escorted through the Mac Group to see our new machine, and to talk with Andy, Steve Jobs, and some of the other folks on the team. Capps and I had too much work to do to be distracted by the reporters, so we moved to a separate office in a different building.

Writing the Finder was not easy. Because of the tight memory requirements, most of the code was 68K assembly, like the ROM Toolbox. Capps took on some of the more difficult tasks, including file copying (see Disk Swapper's Elbow). We worked late into the night, listening to Violent Femmes and Capps' other punk rock recordings. The clock was ticking.

Capps and I ended up finishing version 1.0 of the Finder in time for the Mac to be introduced on January 24 (see Real Artists Ship). It weighed in at 46K bytes, approximately 1/8th the size of the Lisa Filer. The small size of the Finder made it possible to have the entire System and Finder, plus an application, plus a few documents, on a single 400K floppy...just barely. We were overjoyed, but exhausted. The Grand Unified Model --resources, types and creators, the Desktop Database, and the Finder-- was finally done.

What's A Megaflop?
Back to The Original Macintosh
Credit Where Due

Account Name:


Create new account
Overall Rating: 4.58

Your rating:





Great read! Pretty strange that more than 20 years later, Windows and *nix desktop environments are still behind on the concept of types and creators. Even Mac OS X feels like a step backwards...
And the current OS X 10.3 Finder weighs in at 6.5 megabytes and still can't do differential copies. Sigh.
It's interesting to see that even in OSX they are having to relearn some of these issues. Even though they seem to have thrown out type/creator, they still have to have a sort of creator code for each document. I expect to see Apple with a full metadata file system, which will finally provide a good foundation for solving this, and other problems.
I'm amazed about the quality of the original Macintosh Finder and the concept and implementation of the resource manager. Abandoing it for the inferior "bundle" folders and the DOS-like file name extension, is the worst step back in OS X.
"and still can't do differential copies" What are differential copies (google didn't seem to help)? Did the Finder ever do them?
A differential copy, IIRC, is a system where copying a file doesn't actually duplicate all the disk blocks. It just creates a new file-system directory entry, with all the disk blocks marked "copy on write". If you make a differential copy, the amount of disk space consumed doesn't change. As you write to one or the other copy, the disk blocks written to are duplicated (the copy-on-write semantics) so that disk blocks that are identical in the two files are never duplicated. Differential copy is very nice for making "snapshots" of directories for automatic backups. For files that are never written, the snapshot doesn't consume any extra space. In the worst case, where the file is completely overwritten after duplication, the disk space consumed is equal to what it would be with a normal copy. (At the cost of extra processing in the file system to implement the copy-on-write semantics at a disk-block level.) (The name "differential copy" is intended to get across the fact that the only disk blocks allocated by the copy are those that differ from the original file.) I've seen this used in high-end file servers (Network Appliance, for example, uses it for efficiently implementing snapshot-type automatic backups), but I've never seen it in a consumer product.
Ah!!! Keith Bostic added that to FFS (aka UFS) maybe 5 (or 8) years or so ago as part of the "carefully ordered writes" changes that let you safely use a FFS filesystem without a fsck. The snapshots were added more so you could do a fsck after you went multi user (you make a snapshot on boot, fsck it after you go multiuser, and in theory the only things it can find are blocks and inodes marked as in use that aren't, so they can be deallocated via a special syscall). BSD/OS had it, which one might argue is a consumer product. Sun bought the rights to use it, but I don't know if they actually ship systems with it. FreeBSD has had it for a while as well. I have seen it called snapshots (NetApp, FFS), and checkpoints (I think Plan 9), and I seem to recall "save sets" being a term someone else used (IBM, some mainframe product?)...I just never ran across the term differential copy. Thank you for the definition.
How neat to read all this about "differential copy". About a year ago, I invented the same wheel yet again for Linux, giving it the name "cowlink". As one of the young hotshots that try to create some "cool stuff" today, it is great to read about the old days. Todays legends used to be in the same situation, although they may have been a little more brilliant.
Amazing people can get so worked up over an "appliance" with only two fucking programs. FOLKLORE.ORG? WHO'S KIDDING WHOM?
Amazing people can get so worked up over an anecdote and vent so much vitriol, the odd TABOO word & SO MANY CAPITALS! I note everyone else's tone has been fairly laid back. FOLKLORE.ORG? yes that's the site WHO'S KIDDING WHOM? I don't know. Who do you think is kidding who else about what exactly? I thought it was an interesting story about the development of a novel and sophisticated (at the time) user interface for a machine that was within reach of many. It was VERY different from the prevalent CP/M & PC-DOS interfaces at the time and IMO (since I had the opportunity to use both at the time) easily as effective and more productive than its counterparts. I also note that MS delivered the first WIMP versions of WORD and MULTIPLAN/EXCEL on this platform and for ease of use borrowed the key combinations for cut/paste/etc from those applications for their later (& until Win95 IMO inferior) OS product.
There are mismatches between the Resource Manager and the Finder and the File Manager. For example, the version number of a file have to be 0 for the Resource Manager to load a resource from it, and the Finder ignores version numbers and limits file name length to 63 characters, while the MFS file system limited file length to 255 characters. Why?
Hi, Bruce (and all). Fascinating stories here. I have a non-technical question about the origin of the name "Finder". Any special meaning to it (apart from the obvious!) or story behind it? I performed a cursory search on the site on this subject but couldn't find anything.