Carbon is the codename of Apple Computer's APIs for the Macintosh operating system, which permits a good degree of backward compatibility between code written to run on the classic Mac OS, and the newer Mac OS X. The APIs are published and accessed in the form of C header files and a dynamically linkable library. The implementation of the APIs is different in the two systems, but this difference is shielded from the executable. This permits code that conforms to the Carbon APIs to run unchanged and natively on both OSes.
Without Carbon, applications written solely using the older APIs can only be run in the Classic Environment on Mac OS X.
The Carbon APIs have been designed to include as many of the older classic APIs as possible, to permit easy porting of legacy code to Mac OS X. Such porting is known in Mac programming parlance as Carbonising. Carbon also adds new APIs to make up some of the deficiencies in the older APIs. For example, in the classic APIs, many data structures were exposed and code was expected to manipulate or query fields within these structures directly. In Carbon, most such structures are now fully opaque, and so new APIs have been added to allow the same queries and manipulations to be done. Such changes require legacy source code to be slightly modified, but the result is usually cleaner and less error-prone code. Carbon does not include some of the older APIs that deal with now obsolescent technology, for example the Palette Manager. On OS X, it also includes additional APIs for new technologies which were never part of the original Mac OS - applications requiring these cannot run on the older Mac OS.
Carbon is often seen as a transitional or legacy technology, but in fact it is unlikely that large legacy codebases (e.g. Adobe Photoshop, etc) will be completely rewritten for Mac OS X, and so it will necessarily remain a core part of the OS X operating system indefinitely. In addition, Cocoa relies on Carbon for some of its lower level services, and some services that don't fit the Cocoa design approach only have Carbon APIs. What is likely is that software vendors will quickly drop support for running under Mac OS 9.x using Carbon, since that operating system has already been officially retired by Apple. This is already happening - there are numerous applications which, while written using the Carbon APIs, will only run on OS X. Examples include iTunes 3.x and later, and Microsoft Office v.X. Since Carbon is lower level and accessible by a range of programming languages, it is also closer in style to the Win32 APIs of Windows, and therefore may be a better choice for cross-platform development.
Carbon is often confused and/or compared with Cocoa, but the two are complementary and are solving different problems. In general, Carbon is the lower level APIs, whereas Cocoa is a higher level application framework. While a software project may exclusively use one or the other, in practice it is often necessary to use elements of both. Carbon is more versatile in that it may be accessed using C, C++, Pascal, Ada, or any other language with suitable interface headers, whereas Cocoa exclusively uses Objective C and Java. A higher level approach may be taken with Carbon by using an application framework built on it, for example MacApp, Metrowerks Powerplant or MacZoop.
The Carbon APIs are organised along traditional lines, in a flat (as opposed to object oriented) fashion. Functionally related APIs are grouped into managers. Each manager defines sets of data structures and functions which manipulate these. Managers are often interdependent or layered.
Some examples of Carbon managers:
Carbon Architecture
The classic Mac OS adopts a polling model (a.k.a "pull" model) for application design - it polls for events, pulling each off a queue and responding to it, then returning to a loop waiting for another event. Carbon supports this, for backward compatibility, but a polling model is inefficient, especially in a modern preemptive multitasking environment. Instead, Carbon encourages the adoption of a "push" model, in which the application sleeps until an event occurs it needs to respond to, at which point the OS restarts the thread and the application is given the event. It then responds as before, and goes back to sleep. This approach yields greater responsiveness to the user, and permits much smoother multitasking. Converting legacy code to use the modern approach is the work of a few minutes, due to the clever design of the Carbon event manager.
