Расширения Mac OS: История и эволюция

On the classic Mac OS (the original Apple Macintosh operating system), 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 phrase "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 by patching the underlying OS code, they had the capability to modify existing OS behaviour, the other two did not.

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 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". INITs could now be installed simply by placing a file in the System Folder, well within the abilities of the average user. Starting with System 7, extensions were relocated to the Extensions folder within the System Folder for convenience, and an auto routing mechanism was implemented so that placing an extension into the System Folder through drag and drop would actually place the file in the appropriate subfolder. 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.

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. 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 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.

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.

MultiFinder and System 7 and later supported faceless background applications similar to UNIX daemons or Windows Services, though using cooperative multitasking. Examples included Time Synchronizer (daylight saving time adjustment and remote time synchronization), Software Update Scheduler, and Folder Actions (folder event handling). Faceless background applications were regular applications with the restriction that they did not show up on the application menu. 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. 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". 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.

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.