Extension (Mac OS)
From Wikipedia, the free encyclopedia
On the Apple Macintosh operating system prior to Mac OS X, extensions were small pieces of code that extended the system's functionality. They were run initially at start-up time, and operated by a variety of mechanisms, including trap patching and other code modifying techniques. Initially an Apple developer hack, extensions became the standard way to provide a modular operating system. Large amounts of important system services such as the TCP/IP network stacks (MacTCP and Open Transport) and USB and Firewire support were optional components implemented as extensions. The term "system extension" later came to encompass faceless background applications as well.
Extensions generally filled the same role as DOS's terminate and stay resident programs, or Unix's daemons, although they did have additional functionality to modify existing OS behaviour the other two did not.
Contents |
[edit] 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 file'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, Apple responded by providing a more managed solution. Initially this itself was in the form of an 'INIT' resource placed in the System file, 'INIT 31' that would search for further files of type 'INIT' in the System Folder, and load and run INIT resources inside them. (This is why some veteran Mac programmers still refer to the extensions loading mechanism as the "INIT 31 trick" [1]). INITs could now be installed simply by placing a file in the System Folder, well within the abilities of the average Mac user. Starting with System 7, extensions were relocated to the Extensions folder within the System Folder for convenience.
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 Chooser.
[edit] 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 (origin of this was ShowINIT). The 'parade of 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 amount 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. 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.
The simplest way to clean-boot the operating system was to hold the shift key: loading of extensions would be bypassed. System 7.5 added the Extensions Manager, which allowed the user to quickly enable or disable particular extensions, and also to define sets of them that would work correctly together. Extensions Manager came with two read-only base sets provided: one that contained the subset of extensions needed for basic OS operation, and one that enabled all the official extensions that shipped with the OS but disabled all third-party extensions.
The loading order of extensions was always based on the alphabetical sorting of their filenames, which was an amusing quirk. Thus the simple expedient of renaming an extension was one method by which conflicts that depended on loading order could be resolved.
[edit] 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 System 7, control panels become separate Finder plugins on disc that could be launched by the user. By inserting INIT code into a control panel, it became possible to build extension/control panel hybrids that modified the operating system at boot time and contained their own in-built configuration interface in the same form as any other operating system control panel.
[edit] Faceless background applications
MultiFinder and System 7 and later supported fully-fledged faceless background applications similar to UNIX daemons. Examples included Time Synchronizer (daylight saving time adjustment and remote time synchronisation), Software Update Scheduler, and Folder Actions (folder event handling). Faceless background applications were regular applications with the simple restriction that they did not show up on the application menu. As such, they were prohibited from opening a 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 only technical differences between a faceless background application and a regular application were that the "Only background" flag was set in the 'SIZE' resource.
The Control Strip in Mac OS 8 and 9 was an example of a faceless background application that displayed—in defiance of the term "faceless"—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.
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.
[edit] Viral vectors
INITs and System extensions were the way by which some of the earliest known computer viruses were transmitted - the fact that the system blindly loaded and executed an INIT's code was an obvious security risk, but in the days of limited networking and no Internet connectivity, the globally widespread viruses of today were unknown.
[edit] Other non-INIT extensions
INIT-type extensions were loaded at boot time to update the operating system. Confusingly, various other files were placed into the Extensions folder, 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 are not loaded at boot time.
INIT was not the only type of system extension. Another type is the scri, or WorldScript extension. The BootX Linux bootloader was implemented as a scri simply because they are 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.
