Loading article…
Carbonは、 AppleがMac OS X向けに開発した、現在は開発が終了しているC言語ベースのアプリケーションプログラミングインターフェース（API）です。Mac OS 8とMac OS 9からの移行を容易にするために導入され、開発者は既存のアプリケーションをMac OS Xに移植（「カーボン化」）しながら、従来のMac OSとの互換性を維持することができました。Carbonは、 NeXTSTEPから継承されたオブジェクト指向APIであるCocoaを補完するものであり、CocoaはAppleの主要なアプリケーションフレームワークとなりました。
開発者がCocoaを採用するようになるにつれ、特にiOSの登場以降、Carbonの役割は縮小していきました。AppleはほとんどのCarbon APIの64ビット版をリリースせず、 2012年のOS X 10.8 Mountain Lionでフレームワークを非推奨とし、 2019年のmacOS 10.15 Catalinaで完全に削除したため、Macアプリケーション開発における主要なネイティブAPIはCocoaとなりました。
初代Mac OSは、主要な開発プラットフォームとしてPascalを使用しており、APIはPascalの呼び出しセマンティクスに大きく依存していた。Macintosh Toolboxの大部分はプロシージャ呼び出しで構成されており、Pascalのバリアントレコードの概念に基づいた様々なデータ構造を使用して、APIとプログラム間で情報をやり取りしていた。
時が経つにつれ、 Mac 上では多くのオブジェクト ライブラリが進化し、特にObject PascalライブラリのMacAppやTHINK C Think Class Library、そして MacApp の後のバージョンやCodeWarriorの PowerPlant ( C++版) などが挙げられます。
1996年後半にNeXTを買収したAppleは、既存のOPENSTEP for Machプラットフォームを基盤とした新しいオペレーティングシステム戦略を策定しました。新しいRhapsody OSの戦略は比較的シンプルで、OpenStepの既存のオブジェクトライブラリのほとんどを「Yellow Box」という名前で保持し、OPENSTEP for Machの既存のGUIを移植してMacらしい外観にし、Mac OSからいくつかの主要なAPI （特にQuickTimeとAppleSearch ）をRhapsodyの基盤となるUnixライクなシステムに移植し、既存のMac OSソフトウェアを実行する「Blue Box」と呼ばれるエミュレータを追加しました。
1997年の世界開発者会議（WWDC）でこの計画が発表された際、既存のMac OS開発者からは反発があった。彼らは、自分たちのコードベースが事実上、今後アップデートされる可能性の低いエミュレータに縛られることに憤慨したのだ。彼らはブルーボックスを「ペナルティボックス」と呼ぶようになった。マイクロソフトやアドビといった大手開発企業は真っ向から反対し、既存のMac OSとは大きく異なるため互換性がほとんどないOpenStepへの移植を検討することを拒否した。
Appleはこうした懸念を真摯に受け止めた。 1998年の次回のWWDCでスティーブ・ジョブズがAppleの方向転換を発表した際、彼は「開発者が本当に求めていたのはMac OSの最新版であり、Appleはそれを提供するつもりだ」と述べた。
既存のMac OSソフトウェアを実行するためのBlue Boxのみを搭載した、当初のRhapsodyのコンセプトは、最終的に1999年にMac OS X Server 1.0としてリリースされた。これは、当初のRhapsodyのコンセプトに基づいた唯一のリリースであった。
既存の Mac OS コード ベースに対して、真にサポートされたアップグレード パスを提供するために、Apple は Carbon システムを導入しました。Carbon は、Mac のような API を提供する多くのライブラリと関数で構成されていますが、エミュレーションで実行される Mac OS のコピーではなく、基盤となる Unix ライクな OS 上で動作します。Carbon ライブラリは、徹底的にクリーンアップされ、最新化され、より「保護」されています。Mac OS では、メモリを共有してデータを渡す API が多数ありましたが、Carbon では、そのようなアクセスはすべて、不透明なデータ型のアクセササブルーチンを使用して再実装されました。これにより、Carbon は、Mac 開発者が 10 年間要求していた真のマルチタスクとメモリ保護をサポートできるようになりました。既存の API からのその他の変更では、概念的に Mac OS X と互換性がない、または単に時代遅れの機能が削除されました。たとえば、アプリケーションは割り込みハンドラやデバイス ドライバをインストールできなくなりました。
Carbonをサポートするために、Rhapsodyモデル全体が変更されました。Rhapsodyは実質的にエミュレータを備えたOpenStepでしたが、新しいシステムでは、OpenStepとCarbon APIの両方が可能な限り共通のコードを共有することになりました。これを行うために、OpenStepシステムの下位レベルからObjective-Cで記述されFoundationとして知られる多くの有用なコードが、純粋なCで再実装されました。このコードはCore Foundation、略してCFとして知られるようになりました。CFを呼び出すように移植されたYellow Boxのバージョンが新しいCocoa APIとなり、CarbonのMacライクな呼び出しも同じ関数を呼び出しました。新しいシステムでは、CarbonとCocoaは同等でした。この変換は通常、オブジェクトメソッドが基盤となるCライブラリを呼び出すためCocoaのパフォーマンスを低下させますが、Appleはtoll-free bridgingと呼ばれる技術を使用してこの影響を軽減しました。[ 1 ]
この移行の一環として、Apple はライセンスに制約のあるDisplay PostScript を置き換えるために、新しいウィンドウ サーバーとグラフィック エンジンをゼロから作成しました。それがQuartz (「Display PDF」とも呼ばれています) です。[ 2 ] Quartz は Carbon または Cocoa のどちらからでも使用できる C API コールを提供しました。基盤となるオペレーティングシステム自体はさらに分離され、Darwinとしてリリースされました。
Carbon は 2000 年に、1997 年の Mac OS 8.1 と後方互換性のある共有ライブラリとして、不完全な形で導入されました。このバージョンにより、開発者は既存の Mac OS マシンでプログラムを実行する機能を失うことなく、コードを Carbon に移植することができました。Carbon への移植は「Carbonization」として知られるようになりました。Mac OS X の公式サポートは、新しい OS の最初の公開バージョンであるMac OS X v10.0のリリースとともに 2001 年に登場しました。Carbon は、Apple を含むほぼすべての主要なソフトウェア会社によって、Mac OS X の初期バージョンで非常に広く使用されました。たとえば、 Finder は長年にわたって Carbon アプリケーションのままであり、2009 年に Mac OS X 10.6 がリリースされたときに初めて Cocoa に移植されました。[ 3 ]
2007 年 10 月 26 日にリリースされたMac OS X v10.5から始まった64 ビットMacintosh アプリケーションへの移行により、Carbon に最初の大きな制限が生じました。Apple は 64 ビット環境で Macintosh のグラフィカル ユーザー インターフェイスと C プログラミング言語との互換性を提供しておらず、代わりにCocoa API を使用したObjective-C方言の使用を要求しています。 [ 4 ]多くの論評では、これが Carbon が最終的に消滅する最初の兆候であると捉えられ、Apple が Carbon システムに新たな大きな追加は行わないと発表したことでその見解が強化され、[ 5 ] [ 6 ] 2012 年に Carbon が非推奨になったことでさらに強化されました。
Cocoaの利点とされるものにもかかわらず、大量の既存コードを書き直す必要があったため、Carbonベースのアプリケーションの移行は遅れました。有名な例としてAdobe Photoshop [ 7 ]があり、最終的に2010年4月にCocoaにアップデートされました。これはAppleの主力ソフトウェアパッケージにも及び、iTunes [ 8 ]、Finderアプリケーション、Final Cut Pro（およびそれを動かすQuickTimeエンジンの機能[ 9 ]）は長年Carbonで記述されたままでした。iTunes、Finder、Final Cut Proはその後Cocoaバージョンでリリースされました。
2012年にOS X 10.8 Mountain Lionがリリースされたことで、ほとんどのCarbon APIは非推奨とみなされました。APIは開発者が引き続きアクセスでき、すべてのCarbonアプリケーションは引き続き実行されましたが、APIは更新されなくなりました。2017年6月28日、AppleはmacOS 10.13 High Sierra以降のmacOSバージョンでは、すべてのCarbonアプリケーションなどのmacOS用32ビットソフトウェアが「妥協なしに」サポートされなくなると発表しました。[ 10 ] macOS 10.15 Catalinaでは、すべてのCarbonアプリケーションを含む32ビットアプリケーションのサポートが正式に削除されました。[ 11 ]
Carbon はToolboxから派生しており、そのため「マネージャ」で構成されています。各マネージャは機能的に関連する API であり、一連のデータ構造と、それらを操作するための関数を定義します。マネージャは相互依存または階層化されていることがよくあります。Carbon は、ファイル、メモリ、データ、ユーザー インターフェイス、およびその他のシステム サービスを管理するための幅広い関数セットで構成されています。他の API と同様に実装されており、macOS では、主に、、、および、の複数のフレームワーク (それぞれが共有ライブラリを中心に構築された構造)に分散しており、従来の Mac OS では、という名前の単一の共有ライブラリに存在します。Carbon.frameworkApplicationServices.frameworkCoreServices.frameworkCarbonLib
Carbonは互換性ボックスではなく、Mac OS XのネイティブAPIです。アーキテクチャ図で言えば、Cocoaとほぼ同等の位置づけです。CarbonアプリはMac OS Xのネイティブ機能をすべて利用でき、同じプロセス内でCarbonウィンドウとCocoaウィンドウを混在させることも可能です。
Carbonは、 PowerPC Mac OSで利用可能な複数の実行可能ファイル形式すべてに対応しています。Mac OS Xと以前のバージョンとのバイナリ互換性を確保するには、推奨実行可能ファイル形式を使用する必要がありますが、AppleはXcode IDEでこれをサポートしたことがありません。
Carbonの新しい部分は、その設計においてオブジェクト指向性がより強くなっており、そのほとんどはCore Foundationに基づいています。HIView Manager（Control Managerの上位互換）などの一部のマネージャはC++で実装されていますが、Carbonは依然としてC言語のAPIです。
カーボンマネージャーの例をいくつか挙げます。
Mac Toolbox のイベントマネージャは、当初、アプリケーション設計にポーリングモデルを採用していました。アプリケーションのメインイベントループは、 GetNextEvent を使用してイベントマネージャにイベントを要求します。キューにイベントがあれば、イベントマネージャはそれをアプリケーションに返し、アプリケーションで処理されます。そうでなければ、イベントマネージャはすぐに戻ります。この動作は「ビジーウェイト」と呼ばれ、イベントループを不必要に実行します。ビジーウェイトは、他のアプリケーションで使用できる CPU 時間を減少させ、ノートパソコンのバッテリー消費量も減少させます。従来のイベントマネージャは、1984 年の初代 Mac OS に由来します。当時は、実行中のアプリケーションが必ず唯一のアプリケーションであることが保証されており、電力管理は問題視されていませんでした。
MultiFinder の登場と、複数のアプリケーションを同時に実行できるようになったことで、アプリケーションがスリープ間隔を指定できる新しいイベントマネージャ呼び出しWaitNextEvent が登場しました。レガシーコードがソースコードに大きな変更を加えることなく、より効率的なモデルを採用するための簡単な方法は、 WaitNextEventに渡されるスリープパラメータを非常に大きな値に設定することです。macOS では、これにより、何もすることがない場合はスレッドがスリープ状態になり、処理するイベントがある場合にのみイベントが返されます。このようにして、ポーリングモデルはすぐに反転し、コールバックモデルと同等になり、アプリケーションは元の方法で独自のイベントディスパッチを実行します。ただし、抜け穴もあります。たとえば、レガシーツールボックス呼び出しModalDialog は、内部で古いGetNextEvent関数を呼び出すため、ブロッキングなしでタイトなループでポーリングが行われます。
Carbon では、Carbon Event Manager と呼ばれる代替システムが導入されました。（従来の Event Manager は、既存アプリケーションとの互換性のために引き続き存在します。）Carbon Event Manager は、開発者向けにイベント ループを提供します（CFRunLoop現在の実装では Core Foundation のイベント ループに基づいています）。開発者は、メイン関数内でイベント ハンドラを設定してイベント ループに入り、Carbon Event Manager がアプリケーションにイベントをディスパッチするのを待ちます。
従来の Mac OS では、アプリケーションレベルのタイマーに対するオペレーティングシステムのサポートはありませんでした (下位レベルの Time Manager は利用可能でしたが、タイマーのコールバックは割り込み時に実行され、その間はほとんどの Toolbox ルーチンを安全に呼び出すことができませんでした)。タイマーの実装は通常、アプリケーション開発者に委ねられており、通常はアイドルイベント(他のイベントが利用できない場合にWaitNextEventによって返されるイベント)の経過時間をカウントすることで行われていました。このようなタイマーが適切な解像度を持つためには、開発者はWaitNextEvent の遅延時間を長く許容できなかったため、通常は低い「スリープ」パラメータが設定されていました。このため、スレッドは長時間スリープせず、アイドル イベントを返すために繰り返しウェイクアップするため、スケジューリング動作が非常に非効率になります。Apple はこの問題を解決するために Carbon にタイマーのサポートを追加しました。このシステムでは、タイマーを非常に効率的にスケジュールできます。
GNUstepには、Boron と呼ばれる Carbon API の実装が含まれています。これは ApplicationServices および CoreServices の非推奨ではない部分との互換性を目指しています。この名前は、元素の周期表でホウ素が炭素より前に来るという事実に由来しています。[ 12 ] Darling にも Carbon の実装が含まれています。どちらの実装も非常に不完全で、ほとんどがスタブ関数で構成されています。