This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (February 2007)

Carbon is one of Apple Inc.'s procedural application programming interfaces (APIs) for the Macintosh operating system. It provides C programming language access to Macintosh system services. Carbon is one of five APIs that may be accessed from a Mac OS X program; the others are Cocoa, POSIX, X11, and Java. These APIs have some overlapping and some exclusive capabilities; as the functionality of Mac OS X changes they have not been kept in sync. Carbon provides a good degree of backward compatibility for programs to run on the now-obsolete Mac OS 8 and 9, however these systems are no longer actively supported since Apple released the final OS 9 update on December, 2001.

The transition to 64-bit Macintosh applications beginning with Mac OS X v10.5 has brought the first major limitations to Carbon. Apple does not provide compatibility between the Macintosh graphical user interface and the C programming language in the 64-bit environment, instead requiring the use of the Objective-C dialect with the Cocoa API.^[1] Although Apple has always claimed that Objective-C is easy to learn, the required transition has slowed development of large Carbon-based applications such as Adobe Photoshop.^[2]

[edit] Overview

"Carbonized" application Adobe Systems ImageReady v.7.0 running directly on Mac OS X version 10.2

Carbon consists of a broad set of functions for managing files, memory, data, the user interface, and other system services. It is implemented as any other API: in Mac OS X, it is spread over several frameworks (each a structure built around a shared library), principally ApplicationServices.framework and CoreServices.framework, and in older Mac OS, it resides in a single shared library named CarbonLib.

As an umbrella term encompassing all C-language API procedures accessing Mac-specific functionality, Carbon is not designed as a discrete system. Rather, it opens nearly all the functionality of Mac OS X to developers who do not know the Objective-C language required for the broadly-equivalent Cocoa API.^[3]

Carbon is compatible with all of the several executable formats available for PowerPC Mac OS. Binary compatibility between Mac OS X and previous versions requires use of a Preferred Executable Format file, however, which Apple never supported in their Xcode IDE.

[edit] Evolution and backward compatibility

Carbon was designed as a cleaner implementation of the preceding Macintosh API. As originally designed, Macintosh applications access data records and global variables within the operating system. These practices make programs more compact for primitive computers with scarce memory, but hinder the addition of features to the operating system. Carbon adds (and requires) more modern methods for manipulating this information, namely by calling accessor subroutines on opaque data types. The process of changing a program's syntax to use these functions is termed Carbonization. This makes the application file incompatible with operating systems prior to Mac OS 8.1 at least, although source compatibility is often possible using C preprocessor macros.

Other changes from the pre-existing API removed features which were conceptually incompatible with Mac OS X, or simply obsolete. For example, applications could no longer install interrupt handlers or device drivers.

Carbon was introduced in incomplete form in 2000, as a shared library backward-compatible with 1997's Mac OS 8.1. However, several versions passed before it was mature enough for general use, and late versions require Mac OS 8.6. It is generally necessary to establish the minimum CarbonLib and Mac OS versions when releasing a backward-compatible Carbon application. Versions of CarbonLib are not tied to particular versions of the operating system.

[edit] Today

The development of Mac OS X APIs reflect that of the underlying operating system. Mac OS X is written mostly in C and Objective-C. In particular, Objective-C is ubiquitous in the human interface systems. With Mac OS X v10.5, after a transition where new elements of the Carbon interface specifically referred to the underlying Cocoa system, Apple identified Objective-C and Cocoa as the preferred interface to human interface services. Carbon access to various human interface services in the 64-bit operating environment is not available, and significant new features will not be added to the 32-bit Carbon interface.^[4] Most other parts of the system, which have less emphasis on Objective-C, are not so affected.

[edit] Architecture

Carbon descends from the Toolbox, and as such, is composed of "Managers". Each Manager is a functionally-related API, defining sets of data structures and functions to manipulate them. Managers are often interdependent or layered.

Newer parts of Carbon tend to be much more object-oriented in their conception, most of them based on Core Foundation. Some Managers, such as the HIView Manager (a superset of the Control Manager), are implemented in C++, but Carbon remains a C API.

Some examples of Carbon Managers:

• File Manager — manages access to the file system, opening closing, reading and writing files.
• Resource Manager — manages access to resources, which are predefined chunks of data a program may require. Calls File Manager to read and write resources from disk files. Examples of resources include icons, sounds, images, templates for widgets, etc.
• Font Manager — manages fonts. Deprecated since Mac OS X v10.4 because it is part of QuickDraw in favor of Apple Type Services (ATS).
• QuickDraw — 2D graphics primitives. Deprecated since Mac OS X v10.4 in favor of Quartz 2D.
• Carbon Event Manager — converts user and system activity into events that code can recognise and respond to.
• HIObject — a completely new object-oriented API which brings to Carbon an OO model for building GUIs. This is available in Mac OS X v10.2 or later, and gives Carbon programmers some of the tools that Cocoa developers have long been familiar with. Starting with Mac OS X v10.2, HIObject is the base class for all GUI elements in Carbon. HIView is supported by Interface Builder, part of Apple's developer tools. Traditionally GUI architectures of this sort have been left to third-party application frameworks to provide. Starting with Mac OS X v10.4, HIObjects are NSObjects and inherit the ability to be serialized into data streams for transport or saving to disk.
• HITheme — uses QuickDraw and Quartz to render graphical user interface (GUI) elements to the screen. HITheme was introduced in Mac OS X v10.3, and Appearance Manager is a compatibility layer on top of HITheme since that version.
• HIView Manager — manages creation, drawing, hit-testing, and manipulation of controls. Since Mac OS X v10.2, all controls are HIViews. In Mac OS X v10.4, the Control Manager was renamed HIView Manager.
• Window Manager — manages creation, positioning, updating, and manipulation of windows. Since Mac OS X v10.2, windows have a root HIView.
• Menu Manager — manages creation, selection, and manipulation of menus. Since Mac OS X v10.2, menus are HIObjects. Since Mac OS X v10.3, menu content may be drawn using HIViews, and all standard menus use HIViews to draw.

[edit] Event handling

The Mac Toolbox's Event Manager originally used a polling model for application design. The application's main event loop asks the Event Manager for an event using GetNextEvent. If there is an event in the queue, the Event Manager passes it back to the application, where it is handled, otherwise it returns immediately. This behavior is called "busy-waiting", running the event loop unnecessarily. Busy-waiting reduces the amount of CPU time available for other applications and decreases battery power on laptops. The classic Event Manager dates from the original Mac OS in 1984, when whatever application was running was guaranteed to be the only application running, and where power management was not a concern.

With the advent of System 7.0 and the ability to run more than one application simultaneously came a new Event Manager call, WaitNextEvent, which allows an application to specify a sleep interval. One easy trick for legacy code to adopt a more efficient model without major changes to its source code is simply to set the sleep parameter passed to WaitNextEvent to a very large value—on OS X, this puts the thread to sleep whenever there is nothing to do, and only returns an event when there is one to process. In this way, the polling model is quickly inverted to become equivalent to the callback model, with the application performing its own event dispatching in the original manner. There are loopholes, though. For one, the legacy toolbox call ModalDialog, for example, calls the older GetNextEvent function internally, resulting in polling in a tight loop without blocking.

Carbon introduces a replacement system, called the Carbon Event Manager. (The original Event Manager still exists for compatibility with legacy applications). Carbon Event Manager provides the event loop for the developer (based on Core Foundation's CFRunLoop in the current implementation); the developer sets up event handlers and enters the event loop in the main function, and waits for Carbon Event Manager to dispatch events to the application.

[edit] Timers

In the classic Mac OS, there was no operating system support for application level timers (the lower level Time Manager was available, but executed timer callbacks at interrupt time, during which you could not safely make calls to most Toolbox routines). Timers were usually left to application developers to implement, and this was usually done by counting elapsed time during the idle event - that is, an event that was returned by WaitNextEvent when any other event wasn't available. In order for such timers to have reasonable resolution, developers could not afford WaitNextEvent to delay too long, and so low "sleep" parameters were usually set. This results in highly inefficient scheduling behavior, since the thread will not sleep for very long, instead repeatedly waking to return these idle events. Apple added timer support to Carbon to address this problem -- the system can schedule timers with great efficiency.

[edit] Notes

[edit] External links

• Apple Developer Connection: Carbon