| Developer(s) | Apple Inc. |
|---|---|
| Operating system | Classic Mac OS,macOS |
| License | Proprietary |
Carbon is one of two primaryC-basedapplication programming interfaces (APIs) that were developed byApple for theMac OS Xoperating system. Carbon provided a good degree ofbackward compatibility forprograms that ran onMac OS 8 and9. Developers could use the Carbon APIs to port (“carbonize”) their“classic” Mac applications and software to the Mac OS X platform with little effort, compared toporting the app to the entirely differentCocoa system, which originated inOPENSTEP. With the release of the Macintosh's10.15 (Catalina) update, the Carbon API was officially discontinued and removed, leaving Cocoa as the sole primary API for developing modern Mac applications.
Carbon was an important part of Apple's strategy for bringing Mac OS X to market, offering a path for quick porting of existing software applications, as well as a means of shipping applications that would run on either Mac OS X or the classic Mac OS. As the market has increasingly moved to the Cocoa-based frameworks, especially after the release ofiOS, the need for a porting library was reduced. Apple did not create a64-bit version of Carbon while updating their other frameworks in the 2007 time-frame, and eventuallydeprecated the entire API inOS X 10.8 Mountain Lion, which was released on July 24, 2012.
Theoriginal Mac OS usedPascal as its primary development platform, and the APIs were heavily based on Pascal'scall semantics. Much of theMacintosh Toolbox consisted ofprocedure calls, passing information back and forth between the API and program using a variety ofdata structures based on Pascal'svariant record concept.
Over time, a number ofobject libraries evolved on the Mac, notably theObject Pascal libraryMacApp and theTHINK C Think Class Library, and later versions of MacApp andCodeWarrior's PowerPlant inC++.
With the purchase ofNeXT in late 1996, Apple developed a new operating system strategy based largely on the existingOPENSTEP for Mach platform. The newRhapsody OS strategy was relatively simple; it retained most of OpenStep's existing object libraries under the name "Yellow Box", ported the existingGUI in OPENSTEP for Mach and made it look more Mac-like, ported several majorAPIs from the Mac OS to Rhapsody's underlyingUnix-like system (notablyQuickTime andAppleSearch), and added an emulator known as the "Blue Box" that ran existing Mac OS software.
When this plan was revealed at theWorldwide Developers Conference (WWDC) in 1997 there was some push-back from existing Mac OS developers who were upset that their code bases would be effectively locked into an emulator that was unlikely to ever be updated. They took to calling the Blue Box the "penalty box".[citation needed] Larger developers likeMicrosoft andAdobe balked outright, and refused to consider porting to OpenStep, which was so different from the existing Mac OS that there was little or no compatibility.
Apple took these concerns to heart. WhenSteve Jobs announced Apple's change in direction at the next WWDC in 1998, he stated that "what developers really wanted was a modern version of the Mac OS, and Apple [was] going to deliver it".
The original Rhapsody concept, with only the Blue Box for running existing Mac OS software, was eventually released in 1999 asMac OS X Server 1.0. This was the only release based on the original Rhapsody concept.
In order to offer a real and well supported upgrade path for existing Mac OS code bases, Apple introduced the Carbon system. Carbon consists of many libraries and functions that offer a Mac-like API, but running on top of the underlying Unix-like OS, rather than a copy of the Mac OS running in emulation. The Carbon libraries are extensively cleaned up, modernized and better "protected". While the Mac OS was filled with APIs that shared memory to pass data, under Carbon all such access was re-implemented usingaccessorsubroutines onopaque data types. This allowed Carbon to support truemultitasking andmemory protection, features Mac developers had been requesting for a decade. Other changes from the pre-existing API removed features which were conceptually incompatible with Mac OS X, or simply obsolete. For example, applications could no longer installinterrupt handlers ordevice drivers.
In order to support Carbon, the entire Rhapsody model changed. Whereas Rhapsody would effectively be OpenStep with an emulator, under the new system both the OpenStep and Carbon API would, where possible, share common code. To do this, many of the useful bits of code from the lower-levels of the OpenStep system, written in Objective-C and known as Foundation, were re-implemented in pure C. This code became known asCore Foundation, or CF for short. A version of the Yellow Box ported to call CF became the newCocoa API, and the Mac-like calls of Carbon also called the same functions. Under the new system, Carbon and Cocoa were peers. This conversion would normally have slowed the performance of Cocoa as the object methods called into the underlying C libraries, but Apple used a technique they calledtoll-freebridging to reduce this impact.[1]
As part of this conversion, Apple wrote a new window server andgraphics engine from scratch to replace the licence-encumberedDisplay PostScript: theQuartz (which has been called "Display PDF").[2] Quartz provided a C API calls that could be used from any process. The underlying operating system itself was further isolated and released asDarwin.
Carbon was introduced in incomplete form in 2000, as a shared library backward-compatible with 1997's Mac OS 8.1. This version allowed developers to port their code to Carbon without losing the ability for those programs to run on existing Mac OS machines. Porting to Carbon became known as "Carbonization". Official Mac OS X support arrived in 2001 with the release ofMac OS X v10.0, the first public version of the new OS. Carbon was very widely used in early versions of Mac OS X by almost all major software houses, even by Apple. TheFinder, for instance, remained a Carbon application for many years, only being ported to Cocoa with the release of Mac OS X 10.6 in 2009.[3]
The transition to64-bit Macintosh applications beginning withMac OS X v10.5, released October 26, 2007, brought the first major limitations to Carbon. Apple does not provide compatibility between the Macintoshgraphical user interface and the C programming language in the 64-bit environment, instead requiring the use of theObjective-C dialect with the Cocoa API.[4] Many commentaries took this to be the first sign of Carbon's eventual disappearance, a position that was re-enforced when Apple stated no new major additions would be added to the Carbon system,[5][6] and further reinforced with its deprecation in 2012.
Despite the purported advantages of Cocoa, the need to rewrite large amounts of legacy code slowed the transition of Carbon-based applications, famously withAdobe Photoshop,[7] which was eventually updated to Cocoa in April 2010. This also extended to Apple's own flagship software packages, asiTunes[8] andFinal Cut Pro (as well as the features in theQuickTime engine that powers it[9]) remained written in Carbon for many years. Both iTunes and Final Cut Pro X have since been released in Cocoa versions.
In 2012, with the release of OS X 10.8 Mountain Lion, most Carbon APIs were considered deprecated. The APIs were still accessible to developers and all Carbon applications still ran, but the APIs would no longer be updated. On June 28, 2017, Apple announced that 32-bit software for macOS, such as all Carbon applications, would no longer be supported “without compromise” on versions of macOS aftermacOS 10.13 High Sierra.[10]macOS 10.15 Catalina officially removed support for 32-bit applications, including all Carbon applications.[11]
Carbon descends from theToolbox, and as such, is composed 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. Carbon consists of a broad set of functions for managing files, memory, data, the user interface, and other system services. It is implemented as any other API: in macOS, it is spread over several frameworks (each a structure built around ashared library), principallyCarbon.framework,ApplicationServices.framework, andCoreServices.framework, and in classic Mac OS, it resides in a single shared library namedCarbonLib.
Carbon is not a compatibility box; it's a native API for Mac OS X. It sits roughly alongside Cocoa in an architectural diagram. Carbon apps can use all of the native functionality of Mac OS X, and you can mix Carbon and Cocoa windows in the same process.
Carbon is compatible with all of the severalexecutable formats available for PowerPC Mac OS. Binary compatibility between Mac OS X and previous versions requires use of aPreferred Executable Format file, which Apple never supported in theirXcodeIDE.
Newer parts of Carbon tend to be much more object-oriented in their conception, most of them based onCore Foundation. Some Managers, such as the HIView Manager (a superset of the Control Manager), are implemented inC++, but Carbon remains aC API.
Some examples of Carbon Managers:
The Mac Toolbox's Event Manager originally used apolling model for application design. The application's mainevent loop asks the Event Manager for an event using GetNextEvent. If there is an event in the queue, the Event Manager passes it back to the application, where it is handled, otherwise it returns immediately. This behavior is called "busy-waiting", running the event loop unnecessarily. Busy-waiting reduces the amount of CPU time available for other applications and decreases battery power on laptops. The classic Event Manager dates from the original Mac OS in 1984, when whatever application was running was guaranteed to be theonly application running, and where power management was not a concern.
With the advent of MultiFinder and the ability to run more than one application simultaneously came a new Event Manager call,WaitNextEvent, which allows an application to specify a sleep interval. One easy trick for legacy code to adopt a more efficient model without major changes to its source code is simply to set the sleep parameter passed toWaitNextEvent to a very large value—on macOS, 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. There are loopholes, though. For one, the legacy toolbox callModalDialog, for example, calls the olderGetNextEvent function internally, resulting in polling in a tight loop without blocking.
Carbon introduces a replacement system, called the Carbon Event Manager. (The original Event Manager still exists for compatibility with legacy applications). Carbon Event Manager provides the event loop for the developer (based on Core Foundation'sCFRunLoop in the current implementation); the developer sets up event handlers and enters the event loop in the main function, and waits for Carbon Event Manager to dispatch events to the application.
In the classic Mac OS, there was no operating system support for application level timers (the lower level Time Manager was available, but it executed timer callbacks at interrupt time, during which calls could not be safely made to most Toolbox routines). Timers were usually left to application developers to implement, and this was usually done by counting elapsed time during theidle event - that is, an event that was returned byWaitNextEvent when any other event wasn't available. In order for such timers to have reasonable resolution, developers could not affordWaitNextEvent to delay too long, and so low "sleep" parameters were usually set. This results in highly inefficient scheduling behavior, 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—the system can schedule timers with great efficiency.
GNUstep contains an implementation of the Carbon API called Boron. It aims to be compatible with non-deprecated parts of ApplicationServices and CoreServices. The name derives the fact thatBoron comes before Carbon on theperiodic table of elements.[12]Darling also contains a Carbon implementation. Both implementations are highly incomplete and consist mostly of stub functions.
