Misplaced Pages

Carbon (API): Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 21:13, 15 July 2005 edit63.227.67.1 (talk) Architecture← Previous edit Revision as of 05:47, 16 July 2005 edit undoBoredzo (talk | contribs)Extended confirmed users1,433 editsm Removed _ from C link. There is no full stop in 'toll free bridging'. Space after *. — and rearranged in HIView list item.Next edit →
Line 7: Line 7:
Carbon is often seen as a transitional or legacy technology, but in fact it is unlikely that large legacy codebases (eg, Adobe ], 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, ] 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 ].''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 ] 3.''x'' and later, and ] Office v.X. Since Carbon is lower level and accessible by a range of ]s, it is also closer in style to the ] APIs of ], and therefore may be a better choice for ] development. Carbon is often seen as a transitional or legacy technology, but in fact it is unlikely that large legacy codebases (eg, Adobe ], 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, ] 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 ].''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 ] 3.''x'' and later, and ] Office v.X. Since Carbon is lower level and accessible by a range of ]s, it is also closer in style to the ] APIs of ], and therefore may be a better choice for ] development.


Carbon is often confused and/or compared with ], but the two are complementary and are solving different problems. In general, Carbon is the lower level APIs, whereas Cocoa is a higher level ]. 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 ], ], ], ], or any other language with suitable interface headers, whereas Cocoa exclusively uses ] and ]. A higher level approach may be taken with Carbon by using an application framework built on it, for example ], ] or ]. Carbon is often confused and/or compared with ], but the two are complementary and are solving different problems. In general, Carbon is the lower level APIs, whereas Cocoa is a higher level ]. 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 ], ], ], ], or any other language with suitable interface headers, whereas Cocoa exclusively uses ] and ]. A higher level approach may be taken with Carbon by using an application framework built on it, for example ], ] or ].


Following Apple's announcement of a switch to the ] processor to begin in ], the company ], ], 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 ] require "more tweaks", and Carbon apps written in ] must be moved to Xcode. Following Apple's announcement of a switch to the ] processor to begin in ], the company ], ], 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 ] require "more tweaks", and Carbon apps written in ] must be moved to Xcode.
Line 15: Line 15:
The Carbon APIs are organised along traditional lines, in a flat (as opposed to ]) 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. Newer parts of Carbon tend to be much more object-oriented in their conception, though of course are necessarily implemented in a "flat" API accessible by a variety of programming languages. This manifests itself as the large number of callback functions present within the API compared with the original Mac toolbox APIs. The Carbon APIs are organised along traditional lines, in a flat (as opposed to ]) 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. Newer parts of Carbon tend to be much more object-oriented in their conception, though of course are necessarily implemented in a "flat" API accessible by a variety of programming languages. This manifests itself as the large number of callback functions present within the API compared with the original Mac toolbox APIs.


Carbon includes a low level set of routines and services known as ], which is a C API equivalent to much of the ] of ]. These low level services are identical in both programming environments, differing only 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 calls this "toll-free bridging." Carbon includes a low level set of routines and services known as ], which is a C API equivalent to much of the ] of ]. These low level services are identical in both programming environments, differing only 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 calls this "toll-free bridging".


Some examples of Carbon managers: Some examples of Carbon managers:
Line 28: Line 28:
* Window Manager — manages creation, drawing, updating, and manipulation of windows; uses Appearance Manager to draw window frames. * 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. As of ], menus are really windows underneath. * Menu Manager — manages creation, drawing, selection and manipulation of menus. As of ], menus are really windows underneath.
* HIView - a completely new object-oriented API which brings an OO model for building GUIs to Carbon. This is available in Mac OS X 10.2 or later, and gives Carbon programmers some of the tools that Cocoa developers have long been familiar with. HIView is supported by ], part of Apple's developer tools. Traditionally GUI architectures of this sort have been left to third-party application frameworks to provide. * HIView — a completely new object-oriented API which brings to Carbon an OO model for building GUIs. This is available in Mac OS X 10.2 or later, and gives Carbon programmers some of the tools that Cocoa developers have long been familiar with. HIView is supported by ], part of Apple's developer tools. Traditionally GUI architectures of this sort have been left to third-party application frameworks to provide.


The classic Mac OS adopts a ] model (a.k.a "pull" model) for application design — the application polls for events, pulling each off a ] and responding to it, then returning to a loop waiting for another event. This is provided by the Event Manager, which is supported by Carbon for backward compatibility. But a polling model is inefficient, especially in a modern ] 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, provided by the Carbon Event Manager, yields greater responsiveness to the user and permits much smoother multitasking. At its simplest, this change simply requires the programmer to adjust the "sleep" parameter in legacy code from a small value to a very large one, but an additional layer of event handling is provided that goes well beyond this, relieving the application of the task of decoding events of differing types and passing them to the various routines expected to deal with them. Instead, the modern Carbon developer can simply register handlers for specific event types which will then be called automatically at the appropriate times. The classic Mac OS adopts a ] model (a.k.a "pull" model) for application design — the application polls for events, pulling each off a ] and responding to it, then returning to a loop waiting for another event. This is provided by the Event Manager, which is supported by Carbon for backward compatibility. But a polling model is inefficient, especially in a modern ] 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, provided by the Carbon Event Manager, yields greater responsiveness to the user and permits much smoother multitasking. At its simplest, this change simply requires the programmer to adjust the "sleep" parameter in legacy code from a small value to a very large one, but an additional layer of event handling is provided that goes well beyond this, relieving the application of the task of decoding events of differing types and passing them to the various routines expected to deal with them. Instead, the modern Carbon developer can simply register handlers for specific event types which will then be called automatically at the appropriate times.


==External links== ==External links==
* *


] ]

Revision as of 05:47, 16 July 2005

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

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. Newer parts of Carbon tend to be much more object-oriented in their conception, though of course are necessarily implemented in a "flat" API accessible by a variety of programming languages. This manifests itself as the large number of callback functions present within the API compared with the original Mac toolbox APIs.

Carbon includes a low level set of routines and services known as Core Foundation, which is a C API equivalent to much of the Foundation Kit of Cocoa. These low level services are identical in both programming environments, differing only 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 calls 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
  • 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
  • Carbon 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. As of Mac OS X v10.3, menus are really windows underneath.
  • HIView — a completely new object-oriented API which brings to Carbon an OO model for building GUIs. This is available in Mac OS X 10.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.

The classic Mac OS adopts a polling model (a.k.a "pull" model) for application design — the application polls for events, pulling each off a queue and responding to it, then returning to a loop waiting for another event. This is provided by the Event Manager, which is supported by Carbon 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, provided by the Carbon Event Manager, yields greater responsiveness to the user and permits much smoother multitasking. At its simplest, this change simply requires the programmer to adjust the "sleep" parameter in legacy code from a small value to a very large one, but an additional layer of event handling is provided that goes well beyond this, relieving the application of the task of decoding events of differing types and passing them to the various routines expected to deal with them. Instead, the modern Carbon developer can simply register handlers for specific event types which will then be called automatically at the appropriate times.

External links

Categories: