The Long View
The Long View
Desk Accessories
In its early versions, the Mac had a single job operating system. The designers of the Mac operating system were aiming at simplicity and efficient use of limited resources, and having more than one program loaded in the limited memory of the original Mac seemed unrealistic anyway. Despite this, they included a simple but powerful form of multitasking in the Mac OS right from the first version that shipped with the original Mac 128. The idea was that there would be two classes of programs. Only one standard application could run at a time but all standard programs would be designed to host any number of a second class of program, called a Desk Accessory, that could be run at the same time. The desk accessories that shipped with the operating system were mostly small and unambitious applications, like the desktop clock and calculator. But they were not all simple ornaments. Two essential parts of the operating system, the control panels and the printer chooser, were implemented as desk accessories. The story of the decision to do this is described at folklore.org (see the story entitled Desk Ornaments). From that account it is clear that the Mac team was trying not to call attention to the multitasking capability built into desk accessories, both because they didn’t want to position the Mac in competition with the multitasking Lisa computer, and also because they didn’t view desk accessories as a powerful form of multitasking.
Not Only Ornaments
It’s easy to see why the Mac software team might have thought desk accessories were not a big deal. Desk accessories relied on the host program (the currently running standard program) for memory allocation. In the limited memory of the 128k original Mac, few standard programs had any memory to spare. Many programs would no doubt encounter trouble finding space for desk accessories that needed more than 2-3K of memory. Programs were not required to host desk accessories, and could just decline to launch one if they didn’t have space. So for that and whatever other reasons, Apple did not market desk accessories as an important form of multitasking, and it was generally played down. But when the 512K mac and the Mac Plus became available, the situation changed. A program written carefully to run in a 128K machine might have a lot of available memory on a 512K machine. So consider this. The Finder is a regular program, and one that usually has memory to spare. So why not just run the Finder all the time, and create all other programs in the form of desk accessories. You can have a bunch of desk accessories running, and they each get a time slice every time the Finder executes its event loop, which is at least every 60th of a second. The keyboard focus goes to the frontmost window, whether belonging to the main program or a desk accessory, but the main program and other desk accessories can still run. Sound familiar? It’s multifinder, but done with desk accessories. It was already working long before the multifinder (or switcher) was written, and it didn’t engage any of the problems associated with low memory quickdraw globals that made multitasking difficult on the mac (see story Mea Culpa in folklore.org). The reason it worked is that there was really only one program running, as far as the operating system was concerned. The desk accessories were hosted within it. This way of using the Mac didn’t take off because the important programs that people wanted to use were mostly not desk accessories, but standard programs. Why didn’t programmers write all their programs in the form of desk accessories?
Making Desk Accessories
Desk accessories are not written the same way as regular programs, and they can’t be launched in the usual way. They are implemented as drivers. As such, they are stored as DRVR resources within the System file. Only 15 of them can be put in an individual System file, and they have to be installed with a special resource editor, the Font/DA Mover. Desk accessories appear in the Apple menu, the primary purpose of which is to act as a desk accessory launcher. They don’t register a file type or creator, and so can never be launched by double-clicking a document. They do not have distinctive icons that can arranged in a window. All those things are major deviations from the usual Macintosh model for programs, how they are represented to the user, and the overall user-illusion about what is happening. Their structure in memory is also different. Desk accessories have to be launched by and accommodated in the application heap of the running program. Remember, in the single job version of the Mac OS, the running program is the only law in town, and does everything. If the user selects a desk accessory from the Apple menu, the only process that can detect that is the code of the running program. So, programmers of regular Mac programs were asked to include code to detect the selection of Apple menu items, load the selected Desk Accessory into memory, and launch it using a call to OpenDeskAcc. If the program declines to do so (for example if it can’t find enough free memory to accommodate it), the desk accessory will not start. Opportunity for the desk accessories to execute is also provided by the running program. All Mac programs consist of an event loop, that looks for the occurrence of a user-initiated event that needs service. Every time through it’s event loop, before looking for an event to service, programs are expected to call SystemTask, which gives each desk accessory the opportunity to execute for a little while. How long they run each time is up to them, so desk accessory developers have to be careful not to bog down the rotation with lengthy background activities. Then, if there is an mouse or key event, the program will check to see if the event belongs to a desk accessory, and will pass the event to the desk accessory for service. Desk accessories can insert their own menus into the menu bar, which they share with the running program, and they also can implement them as popups within the accessory window.
Programmers were admonished not to write large desk accessories, and desk accessories are required to fit into a single DRVR resource. Desk accessories are structured like drivers, that is, they provide a set of call-back entry points that are called at appropriate times. Thus, writing and debugging them is a little different. To make that easier, authors of development systems (like Consulair Mac C and Lightspeed Pascal) offered special tools for writing desk accessories. These basically generated code in the form of a single segment (using short branches), limiting the size of the code in desk accessories to 32K. But this was not really necessary. Starting with the Mac Plus and 512ke, DRVR resources aren’t restricted to 32K, and if the desk accessory code can handle long branches without the help of the segment manager and its jump table, it can be as big as it wants to be. Desk accessories run with full privilege to read and write files, and can access data in files stored in the System Folder, or any other location that can be depended on being there when you need it. Once getting its foot in the door, a desk accessory could load some additional code for itself into the host’s application heap without the host even knowing it.
Some Of My Favorite Desk Accessories
Desk Accessories Today
The desk accessory concept is alive and uh, well, I guess, in the form of widgets and gadgets and smidgets and whatnot. The purpose of these is very close to Apple’s original stated purpose for desk accessories. That is, they are really tiny things that tell you the time or the temperature or the current value of the Dow, but don’t actually contribute to the task you are currently performing. As such, they are benign but trivial. Some of them, like a calculator, seem to be offering to do something useful that might contribute to the job you are currently doing. Well, if you are using Apple’s dashboard, then you’re out of luck, because dashboard obscures everything you’re using for any real work and replaces it with a smokey fog. You can use the dashboard calculator, but I hope you can remember the result of your calculation for a few seconds, because to get the fog to go away and get back to work, you have to make the calculator and your answer go away. The smokey gray world that dashboard creates is a mode. You are either in the dashboard mode, or you can be doing your work. Here’s what the Macintosh User Interface Guidelines (Inside Macintosh Vol. 1, 1985) had to say about it.
“A mode is a part of an application that the user has to formally enter and leave, and that restricts the operations that can be performed while it’s in effect. Since people don’t usually operate modally in real life, having to deal with modes in computer software reinforces the idea that computers are unnatural and unfriendly” (p I-28).
Apple designers: For crying out loud, what were you thinking when you made Dashboard? After all the experience Apple has had with desk accessories. You finally made desk accessories equivalent to applications and you unified the user-illusion for applications in System 7. And then in OS X you went back to a second type of app with second-class status that has to be installed into a special launcher using a special installer, and configured by the user using a special configuration thing. Dashboard has all the things you didn’t like about desk accessories and the Font/DA mover and the Apple menu in System 6. Well, not you, I guess, because you were probably just kids playing Grand Theft Auto on the playstation in your parent’s basement when those lessons were being learned. Ask somebody about it. And if you were going to copy Microsoft’s Active Desktop, why couldn’t you do at least as good a job of it as Microsoft did? The desk ornaments they put in Vista/Windows 7 are at least always there in that sidebar thing, and the answer on the calculator doesn’t disappear when you try to use it for something.
-- BG (basalgangster@macGUI.com)
Friday, February 12, 2010