Carbon (computing)

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.
A higher level approach may be taken with Carbon by using an application
framework built on it, for example MacApp, Metrowerks Powerplant or MacZoop.

Carbon Architecture

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:

   * 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, which are a special form of resource.
   * QuickDraw - 2D graphics primitives
   * Quartz (OS X only) - 2D graphics
   * Appearance Manager - uses Quickdraw and Quartz to define look of GUI
     widgets
   * Event Manager - converts user and system activity into events, which
     code can recognise and respond to.
   * Window Manager - manages creation, drawing, updating, and manipulation
     of windows - uses Appearance Manager to draw window frames.
   * Menu Manager - manages creation, drawing, selection and manipulation of
     menus - uses Appearance Manager to draw menus.

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.