Carbon (API)

From Free net encyclopedia

Carbon is Apple Computer's procedural API for the Macintosh operating system, which permits a good degree of forward and backward compatibility between source code written to run on the outdated Mac OS 9, and the newer Mac OS X. It is one of five major APIs available for Mac OS X; the others are Cocoa, Toolbox (for the Classic environment), POSIX (for the BSD environment), and Java. (Environments such as Perl and Python are considered minor environments because they are not generally used for full-fledged application programming).

The Carbon APIs are published and accessed in the form of C header files and a dynamically linkable library (called CarbonLib on Mac OS). 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 operating systems.

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 Toolbox 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, such as 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 (eg, Adobe Photoshop, etc) ever 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.

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. In fact, the Carbon project at Apple was developed from the Quicktime for Windows codebase which has included a substantial subset of the classic Mac OS APIs since the early 1990s. QuickTime was one of the first Apple software components ported to the Rhapsody operating system as it was designed to be portable. Its Mac OS emulation code was then generalized and expanded to form the first release of Carbon.

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 apps written in Xcode require "more tweaks", and Carbon apps written in CodeWarrior must first be moved to Xcode.

1 Architecture
2 Event handling
3 Timers
4 External links

[edit]

Architecture

Carbon descends from the Toolbox, and as such, is comprised 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.
QuickDraw — 2D graphics primitives. Deprecated since Mac OS X v10.4 in favor of Quartz 2D.
Quartz (OS X only) — 2D graphics.
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. 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.
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 are HIObjects.
Menu Manager — manages creation, selection, and manipulation of menus. Since Mac OS X v10.2, menus are HIObjects. Since Mac OS X v10.3, menus and the menu bar are really windows underneath.

[edit]

Event handling

Toolbox's Event Manager originally used a polling (a.k.a "pull") model for application design. The main event loop, which is in the application, asks the Event Manager for an event. If there was an event in the queue, the Event Manager passes it back to the application, and it is handled; otherwise, either the call "blocks" for a specified interval, or it returns immediately.

The polling mechanism worked well in the original Mac OS, when whatever application was running was guaranteed to be the only application running. In a preemptively-scheduled operating system like Mac OS X, however, this is inefficient; the tight event loop means that the application is "busy-waiting", executing its loop when it shouldn't be executing anything at all.

Carbon introduces a replacement system, called the Carbon Event Manager (the original Event Manager still exists, though it is deprecated). Carbon Event Manager provides the event loop for you (based, in the current implementation, on Core Foundation's CFRunLoop); you set up event handlers and enter the event loop in your main function, and wait for Carbon Event Manager to bring the events to you.

However, one easy trick for legacy code to take advantage of the newer approach 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.

[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 was essentially an interrupt-based service). 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 WNE to delay too long, and so low "sleep" parameters were usually set. On OS X, this results in highly inefficient behaviour, 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 - by implementing timers outside of the application's main loop, much greater efficiency can result. Depending on application design, converting code to use the modern approach can be straightforward.

[edit]