Mac OS is focusing on Carbon for its future development, for a solid, modern operating system, and good news also for the developers who want to preserve their investment in many years of development, as almost all-professional Mac design software is Carbon.

It looks also like Apple should freeware Carbon API’s and stuff it on top of Linux and make it the free User Interface STANDARD for all Unicies (Unixxen)! This will be, finally, a UNIX interface.

Carbon is the set of programming interfaces derived from earlier Mac OS APIs that can run on Mac OS X. Some of these APIs have been modified or extended to take advantage of Mac OS X features such as preemptive multitasking and protected memory.

In addition to being able to run on Mac OS X, Carbon applications built for Mac OS X can also run on Mac OS 8 and 9 when the CarbonLib system extension is installed. (As always, you should test for the existence of specific features before using them.)

Carbon includes about 70 percent of the existing Mac OS APIs, covering about 95 percent of the functions used by applications. Because it includes most of the functions you rely on today, converting to Carbon is a straightforward process. Apple provides tools and documentation to help you determine the changes you will need to make in your source code, as well as the header files and libraries necessary to build a Carbon application.

Mac OS X brings important new features and enhancements that developers have asked for, and Carbon allows you to take advantage of them while preserving your investment in Mac OS source code. As Apple moves the Mac OS forward, Carbon ensures you won’t be left behind.

Carbon applications gain these benefits when running under Mac OS X:

• Greater stability. Protected addresses spaces help prevent errant applications from crashing the system or other applications.
• Improved responsiveness. Each application is guaranteed processing time through preemptive multitasking, resulting in a more responsive user experience.
• Dynamic resource allocation. More efficient use of system resources, including the elimination of fixed size heaps, means your application can allocate memory and other shared resources based on actual needs rather than predetermined values. Each application can access up to 4GB of potential addressable memory.
• Aqua look and feel. Apple’s newest user interface is available only to applications that run natively on Mac OS X.

The Carbon programming interface consists of the following types of APIs:

Classic Mac OS APIs that can run unchanged on Mac OS X. These comprise the majority of the APIs in your current application.

Classic Mac OS APIs that have been modified to work on Mac OS X. For example, to operate properly in a preemptively scheduled environment, a function may now require an additional parameter to specify the context (or process) to which it belongs.

New APIs that can run on both Mac OS X and Mac OS 8 and 9.

For example, Core Foundation and the Carbon Event Manager provide additional benefits for Carbon applications but are not required for porting. New APIs those are available only on Mac OS X.

Currently, the Classic Mac OS APIs makes up the largest proportion of Carbon APIs. However, as Carbon evolves to take advantage of new features in Mac OS X, new Mac OS X-specific APIs will be added that enhance its capabilities.

Carbon does not support a Classic Mac OS function; it is generally for one of the following reasons:

• The function performs actions that are illegal or make no sense in Mac OS X. For example, functions that are 68K-specific, or functions that allocate memory in the system heap (Mac OS X has no concept of a system heap).
• The function directly accesses hardware. The Carbon environment was designed to be fully abstracted from hardware, so such functions are not allowed.
• The function was there for legacy purposes only, and has more modern replacements (for example, File Manager functions that use working directories).

In addition, certain Classic Mac OS programming practices are no longer allowed:

• No 68K code allowed. All Carbon code must be PowerPC-based.
• No trap table access. The trap table and Patch Manager are 68K-specific.
• Limited access to data structure fields. See “Data Structure Access”.
• Carbon lets you create one executable file that can run on both Mac OS X and Mac OS 8 and 9. You accomplish this by linking your application with a single stub library, CarbonLibStub, at build time. At runtime your application links with the appropriate Carbon implementation stored as shared libraries (sometimes referred to as DLLs).

On Mac OS X, your application links dynamically to the Carbon framework, which is a hierarchy of libraries and resources that contains the implementation of Carbon.

On Mac OS 8 and 9, the Carbon implementation is stored as a system extension named CarbonLib. This library contains two types of elements:

• Implementations of all functions specific to Carbon.

Exports of functions currently available in system software. For example, calls to a Menu Manager function available in both Carbon and Mac OS 8 and 9 will merely call through to the implementation in InterfaceLib.