A desk accessory (DA) in computing is a small transient or auxiliary application that can be run concurrently in a desktop environment with any other application on the system. Early examples, such as Sidekick and Macintosh desk accessories, used special programming models to provide a small degree of multitasking on a system that initially did not have any other multitasking ability.
Personal information managers
Early personal information managers, such as Norton Desktop and Borland's Sidekick, provided pop-up calculator, alarm, calendar and other functions for single-tasking operating systems like MS-DOS using terminate and stay resident techniques.
Introduced in 1984, as part of the operating system for the Apple Macintosh computer, a Desk Accessory (DA) was a piece of software written as a device driver, conforming to a particular programming model. The purpose of this model was to permit very small helper-type applications to be run concurrently with any other application on the system. This provided a small degree of multitasking on a system that initially did not have any other multitasking ability.
DAs were implemented as a special class of driver. It was installed in the driver queue, and given time periodically and co-operatively as a result of the host application calling SystemTask() within its main loop. A DA was permitted to have a user interface as long as it was confined to one main window. A special window frame with black title bar and rounded corners was reserved for the use of DAs so that the user could distinguish it from the windows of the hosting application.
Typical early DAs included the Calculator and Alarm Clock. The Control panel, Chooser, and Scrapbook were initially implemented as DAs. Third-party DAs such as spelling checkers could be purchased. It was considered hard to write a DA, especially early on when there was little in the way of developer tools. However, since on the early Mac OS drivers did not have any special privileges, writing a DA was, with practice, no more difficult than any other application.
A special Font/DA Mover utility was used to change the configuration of DAs. Because DAs were not installed or launched in the same way that applications were, the user could not drag and drop DAs into or out of the system. They resided in the System file's 'DRVR' resources, like actual drivers, though they could be installed in any file whose resources were loaded into the memory, and were stored in "suitcases" when not installed in the system file. If installed within a separate application, such as MacWrite, their functionality would be accessible only when that application was running. That is, a desk accessory installed as a resource within an application would appear on the Apple menu as a desk accessory only when that application was active. It could then be activated while the application was run and would then disappear when the application was terminated through the Quit function. (Similarly, the FKEY resources could be installed either within the System so as to be universally available, or within an application so as to be available only when that application was active). As a resource numbering scheme was implemented for marking resources as belonging to another resource of some particular type and number in the same file, such as a DA ('DRVR'), it was possible for desk accessories to have a limited "resource fork" of their own within the file they were contained in; the mover utility recognised such resources and moved them along with the actual DA code resource they were associated with.
With the advent of System 7, which included a standard co-operative multitasking feature, the need for DAs diminished greatly, and developers were encouraged to develop small applications instead. The system continued to run DAs (and still does up to Mac OS 9.x) for backward compatibility. Under System 7 and later, DAs could be moved and renamed using the Finder like normal applications, removing the need for Font/DA Mover and confining suitcases to font management. When a DA was run under System 7, it always executed in the Finder's address space. The icon for a desk accessory program under System 7 and later is roughly a reversed version of the application icon, with the writing hand on the left side instead of the right.
GEM resembled the Macintosh closely in many respects, and one of them was the presence of desk accessories, for the same reason: to allow multiple programs to be used in a system that only supported one full application at a time.
From a programming point of view, desk accessories were implemented, like other GEM applications, as DOS .EXE files, with names ending with .ACC (Accessory) rather than .APP (Application). Each .ACC file could support multiple accessories; all three of the standard GEM accessories (Calculator, Clock and Print Spooler) were provided by
CALCLOCK.ACC. Installation was simply a matter of placing the .ACC in the correct directory -
\GEMBOOT in earlier versions, and
\GEMAPPS\GEMSYS in GEM/3 and later.
Since each desk accessory loaded reduced the amount of memory available for programs, one technique for temporarily increasing available space was to rename one or more .ACC files to have a different suffix (usually .ACX) and restart GEM. On the Amstrad PC-1512, for example, the Snapshot accessory was shipped as
SNAPSHOT.ACX and had to be renamed to .ACC if required.
For much the same reason as desk accessories were used in Mac OS and in GEM, namely to allow more than one simultaneous program on a system which did not support multitasking, the concept of desk accessories was extended to Palm OS by third-party developers. DA are applets launched by an application or hack serving as a DA launcher. The DA launcher may watch for keystrokes or other system events and pop up a pre-defined desk accessory. Many general purpose Palm OS launcher applications are capable of launching DAs as well.
A desk accessory program is a Palm resource database of type 'DAcc', specified to include a single 'code' #1000 resource that contains the binary code implementing the desk accessory. Global or static variables are not available, but a DA can call user interface APIs. It is possible for a DA to have user interface resources in its database. The desk accessory launcher transfers execution to the first byte of the 'code' #1000 resource.
DAs provide a modicum of multitasking. However, unlike in Mac OS and GEM, after the user is done working with the DA, it must be closed to return to the underlying application. It is possible to pop a DA up over another DA, though this might deplete stack space.
- "Desk accessories are hard to write because they're constructed so differently from the host programs they depend on. They're written as device drivers - which means, among other things, that they are table-driven, that they have to be small (about 8K bytes at the most), and that they have to be very careful not to alter the environment they work in." Byte Sept 1986
- Andy Hertzfeld. Desk Ornaments. folklore.org. URL accessed May 20, 2006.
- Helper application, for web browser accessories