Carbon (API)
|
|
Carbon is the codename of Apple Computer's APIs for the Macintosh operating system, which permits a good degree of backward compatibility between source 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 most legacy code to Mac OS X. Such porting is known in Mac programming parlance as Carbonization. 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.
Following Apple's announcement of a switch to the Intel processor to begin in 2006, the company CEO, Steve Jobs, discussed the projected effort required to port various types of apps to the new architecture. Cocoa apps require 'a few minor tweaks,' Carbon written in Apple's official development framework, XCode, apps require 'more tweaks,' and Carbon apps written in MetroWerks first require a move to XCode.
Look and Feel
It is easy to tell the difference between Carbon apps and others. On both Classic and OS X, Carbon apps are characterized by potentially nonstandard interfaces (granted, this is usually a result of the haphazard programming of Carbon apps as a transition technology), and rendering of fonts that is standard to neither operating system.
Unfortunately, Carbon applications are also characterised by their often slow performance. The most visible example of this is Microsoft's Windows Media Player, an embarassingly slow and unreliable application. Often, in Carbon applications, UI widgets differ slightly from OSX/Classic specific applications.
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.
Carbon includes a low level set of routines and services known as Core Foundation, which is a C API equivalent to the Foundation Kit of Cocoa. These low level services are identical in both programming environments, just differing in their public APIs - there is no translation or duplication of code - indeed, it's possible to pass an object reference to one of these types from Cocoa to Carbon and vice versa quite freely. Apple call this "toll-free bridging".
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 graphical user interface (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 often the work of a few minutes, due to the clever design of the Carbon event manager.
External links
- Apple Developer Connection: Carbon (http://developer.apple.com/carbon/)da:Carbon (programmering)