This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Component Manager" – news · newspapers · books · scholar · JSTOR (June 2009) (Learn how and when to remove this message)

In Apple Macintosh computer programming, Component Manager was one of many approaches to sharing code that originated on the pre-PowerPC Macintosh. It was originally introduced as part of QuickTime, which remained the part of the classic Mac OS that used it most heavily.^[1]

A component was a piece of code that provided various functions that may be invoked by clients. Each function was identified by a signed 16-bit integer ID code. Non-positive codes were reserved for predefined functions that should be understood by all components—open/close a component instance, query whether a function was supported, etc. The meanings of positive function codes depended on the type of component.

A component instance was created by opening a component. This called the component's open function to allocate and initialize any necessary storage for the instance. Closing the instance got rid of this storage and invalidated all references to that instance.

Components and component instances were referenced by 32-bit values that were not pointers. Instead, they were interpreted as keys into internal Component Manager tables. These references were generated in such a way that, once they became invalid, those values were unlikely to become valid again for a long time. This minimized the chance of obscure bugs due to dangling references.

Components were identified by OSType codes giving their type, subtype and "manufacturer". For instance, a component type might be "raster image compressor", subtypes of which might exist for JPEG, H.261, Sorenson, and Intel Indeo, among others. It was possible to have multiple components registered with exactly the same identification codes, giving alternative implementations of the same algorithm for example using hardware versus software, trading off speed versus quality, or other criteria. It was possible for the applications to query the existence of such alternatives and make explicit choices between them, or let the system choose a default.

Among the options available, a component could delegate parts of its functions to another component as a form of subclassing for code reuse. It was also possible for one component to capture another, which meant that all accesses to the captured component had to go through the capturing one.

Mac OS accumulated a great variety of component types:

• Within QuickTime, there were image codecs, media handlers, media data handlers, video digitizer drivers, file format importers and exporters, and many others.
• The Sound Manager moved to a predominantly component-based architecture in version 3.0: sound output devices were represented as components, and there were also component types for mixing multiple channels, converting between different sample rates and sample sizes, and encoding and decoding compressed formats.
• AppleScript introduced the concept of scripting languages implemented as components.
• ColorSync implemented different colour-matching methods as components.
• QuickDraw GX "font scalers" were renderers for the different font formats.