Extension (Mac OS)
This article needs additional citations for verification. (February 2009) |
On the
Extensions generally filled the same role as
The INIT mechanism
The concept of extensions was not present in the original Macintosh system software, but the system nevertheless had a private patching mechanism that developers soon learned to take advantage of - the INIT loader. This code would search for system resources of type 'INIT', and load and run them at boot time. The code resources had to be stored directly in the Mac System suitcase's resource fork, meaning it was only really available to "power users" who would be comfortable using ResEdit or other resource editor.
Since taking advantage of this mechanism was an unsupported hack, and only 32 INITs could be loaded in this manner, Apple responded by providing a more managed solution. Initially this itself was in the form of an 'INIT' resource with ID 31 placed in the System file that would search for further files of type 'INIT' in the
Extensions retained the resource type of 'INIT' throughout their lifetime, and the loader was gradually enhanced to search for these resources in numerous places, including in the resource forks of control panels in a variety of formats and the
Extensions
INITs evolved into system extensions, gaining additional ad hoc protocols along the way, such as supplying an icon to be displayed at boot time (the origin of this was 'ShowINIT'). The 'parade of puzzle pieces and icons' across the screen as each extension loaded became familiar to all Mac users. Apple themselves eventually released major (but optional) pieces of the operating system as extensions, such as QuickTime, QuickDraw 3D and many others. A substantial number of services and drivers in Mac OS—both official and third party—were provided as extensions, allowing for the OS to be trimmed down by disabling them.
System extensions were a common source of instability on the Macintosh, as third-party code was of variable quality and would often patch the system in ways that did not always work correctly. Some extensions didn't work properly together, or worked only when loaded in a particular order. In addition, different extensions might try to patch the same part of the system, which could lead to extension conflicts and other instability. Tracking down these sources of trouble was another task most Mac users encountered at some point. Troubleshooting Mac OS extensions could be a time-consuming process of bisecting and trial and error.
The simplest way to clean-boot the operating system was to hold the shift key: loading of extensions would be bypassed.
The loading order of extensions was a side-effect of the GetFInfo function that was used by the loader to enumerate the files in the Extension folder. While Apple always have said that the order that results from enumeration of files using this function is undefined, on HFS volumes this function enumerated files in the order stored in the HFS catalog. People figured out that changing the first character in the file name could change the extension loading order, which caused trouble when Mac OS 8.1 moved to HFS+. Apple ended up having to change the loader to sort the filenames returned by this function into a table, and provided an interface to allow software to change the table.[2]
Configuration and control panels
System extensions had no user interface: there was no standard mechanism by which the user could configure the services provided by an extension. Extensions were able to alter the graphical interface (such as adding new menus to the menu bar) and thus accept user configuration, or they could be accompanied by an application to provide the configuration interface.
With
Faceless background applications
MultiFinder and System 7 and later supported faceless background applications similar to
SIZE
' resource. They were prohibited from opening a normal application-level window: if they did so, the system would freeze.
They were free to open global floating windows, however, since these could neither gain nor lose focus. The Control Strip in Mac OS 8 and 9 was an example of a faceless background application that displayed a global floating window to provide user interaction. The Application Switcher was another. However, the user was not aware at any time that the Control Strip was a running process; it was simply presented as an extra interface feature. The system simply described faceless background applications as "system applications".[citation needed]
Language features in the Open Scripting Architecture (and thus AppleScript) were initially implemented as dynamically loadable plugins known as "scripting additions" or OSAXes. In Mac OS 8 and 9, these were augmented by faceless background applications that were loaded in the background on demand. Just as with regular applications, these applications were accessed using tell
clauses: the global namespace was not updated as was the case with OSAXes. The operating system did not indicate the launch of such processes nor indicate whether or not they were running.
Other non-INIT extensions
INIT-type extensions were loaded at boot time to update the operating system. Confusingly, various other files could be placed into the Extensions folder as well, many of which were not loaded at boot time. The most notable of these were shared libraries which were commonly put into the Extensions folder for ease of location. Shared libraries were not loaded at boot time.
INIT-type files were not the only type of system extension. Another type was scri, or WorldScript extension. The BootX Linux bootloader was implemented as a scri simply because such files were loaded very early on in the boot process, before all other extensions. BootX could then display a dialog offering to let the user finish booting Mac OS or load Linux instead.