Carbon (API)

Carbon（カーボン）は、かつてMac OS Xで提供されていた、二つあったC言語ベースの主要なアプリケーションプログラミングインターフェース(API)のうちの一つ。もう一つのAPIであるCocoaがMac OS Xの技術的前身であるNeXTSTEP (OPENSTEP) に由来するのに対し、Carbonは先代OSであるClassic Mac OSのToolbox API (Application Programming Interface) をMac OS X用に整理・移植したものであり、Classic Mac OS用アプリケーションをMac OS X向けに移植しやすくするために開発された。

Carbonは旧来のClassic Mac OS用アプリケーションの迅速な移植を可能にし、初期のMac OS Xの普及を支える重要な役割を果たしたが、後年アプリケーションのCocoaへの移行が進むとCarbonの重要度は低下し、徐々にフェードアウトすることになった。Mac OS Xの64ビット対応が進んでもCarbonは64ビット化から取り残され、OS X Mountain Lionからは使用が非推奨とされ、macOS Catalinaからは完全に廃止された。

概要

QuickTimeチームがAPIをMac OS Xに移植するために互換レイヤーを作成したものが元型となっている。それがスティーブ・ジョブズの目に留まり、汎用の互換フレームワークのアイディアとして採用された。Toolbox APIの中で明らかにレガシーなもの、あまり使われていないものを廃し、また内部構造が32ビットを前提として再設計されている（Toolboxは16ビットコードで、PowerPCの性能の足枷となっていた）。

Carbon APIを利用したアプリケーションのことをCarbonアプリケーションと呼ぶ。Mac OS Xに搭載されているもう一つのAPIであるCocoaがObjective-Cのコードを書かなければならないのに対して、Carbon APIはClassic Mac OS由来のインターフェイスを持っておりC/C++からも使うことができる。基本的にToolboxとソースコード互換を目指しており、単に移植を行なうだけであれば、それほど大きな設計変更は必要なかった。

Carbonアプリケーションには、

一つのバイナリでMac OS XでもClassic Mac OSでも実行できる『PEF Carbon』
Mac OS X専用の『Mach-O Carbon』

の2種類が存在した^[1]。

PEFとはPreferred Executable Formatのことで、CFM（Code Fragment Manager）Carbonともいう。PEFは従来から使用されてきたフォーマットであるため、Classic Mac OSとMac OS X、両方で動作させることができた。ただし、CFM Carbonのアプリケーションでも、実行にはCarbonLibと呼ばれる機能拡張書類が必要であり、これがなければClassic Mac OSでは動作しない。

Mach-O CarbonはMac OS X用に最適化されているのでCFM Carbonより幾分高速に動作する。また、QuartzをはじめとするMac OS X特有のAPIを利用するためには、Mach-O形式が最も適する。このフォーマットはdyldとも呼ばれる。そのままではClassic Mac OSでは動作しないが、Mac OS 9から導入されたアプリケーションパッケージを利用して一つのフォルダの中に CarbonアプリケーションとClassic Mac OS用アプリケーションの二つを同梱し、一つのアプリケーションのように見せかけてClassic Mac OSとMac OS Xの両方で実行できるようにしたものもあった。

Mac OS Xが普及してしばらくはCFM Carbonが大半だったが、開発環境が最適化されていくにつれてMach-O Carbonがほとんどとなってきた。（Xcodeの利用による）Mach-O化はUniversal Binary化には必須である。なお、CocoaはCarbonと必ずしも対立するものではなく、当初はCarbonベースのライブラリをラップしてCocoaアプリケーションとして実装したもの、Cocoaベースのコンポーネントが組み込まれたCarbonアプリケーションなど、様々な実装形態のソフトウェアが存在していた。

実態と終焉

当初のAppleの説明では、Carbonに対応したアプリケーションは、CarbonLibをインストールしたMac OS 9とMac OS Xで（それぞれのOSに特有の機能を除けば）同じように動作可能というものであった。しかし実際にはCarbonLibには問題も多く、デベロッパはMac OS 9とMac OS X用にコードを書き分けねばならない場面も多かった。ユーザーのMac OS Xへの移行も迅速に進んだため、結局両方のOSで動作可能というメリットが活かされることはあまりなかった。

Mac OS X v10.2からMac OS X v10.4にかけて、CarbonはCocoaを模したHIObject(カスタムコントロールを作成するための機能セット)の導入や、Mac OS X全体の共有基盤といえるCore Foundationとの互換性強化など、当初はCocoa同等の開発基盤として徐々に構造の近代化が計られた。

しかしながらMac OS X v10.5での64ビット対応はUI部分が見送られ^[2]、64ビット完全対応にはCocoaへの移行が必須となるなど、AppleはGUIフロントエンドとしてのCarbonを徐々にフェードアウトさせ、Cocoaをメインとする姿勢を強めていった。Mac OS X v10.6では従来CarbonベースだったQuickTimeとFinderがCocoaで作り直されている。

さらにMac OS XはPowerPC CPUのみならず、インテルCPU上へも移植され、Intel MacではCocoaアプリケーションとMach-O Carbonアプリケーションは再コンパイルすることでネイティブに動作するとされていた一方、CFM Carbonのアプリケーションはネイティブ動作せず、Rosetta環境上での動作となった。

Rosetta環境はMac OS X Lionで廃止され、次のOS X Mountain LionではCarbon自体の利用が非推奨となった。macOS Catalinaからは32bitアプリケーションへの対応と共にCarbonも廃止されたため、Cocoaで作り直されていないCarbonアプリケーションは完全に動作しなくなった。

脚注

^ CFMやMach-OはABI (Application Binary Interface) のことで、API (Application Programming Interface) とは無関係。
^ Choosing a Development Path for Your Carbon User Interface

この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

[1] CFMやMach-OはABI (Application Binary Interface) のことで、API (Application Programming Interface) とは無関係。

[2] Choosing a Development Path for Your Carbon User Interface

[1]

[2]