MacOS Support/Universal/Libraries/StubLibraries
Stubフォルダには、CarbonLib以外に「CarbonAccessors.o」と「LiteCarbonLib」の二つのファイルが存在しています。これは何のために存在しているのでしょうか？
最初のCarbonAccessors.oには、Carbonで利用されるアクセッサー関数（accesspr function）が含まれています。Carbon環境では、ToolBoxなどで定義されている構造体のメンバーに直接アクセスすることは許されていません。よって、そのかわりにアクセッサー関数を利用するわけです。例えば、Window Managerの「WindowRecord」構造体には「nextWindow」というメンバーが存在します。これをアクセスする場合には、今までのソースコードなら...
WindowPtr wptr1,wptr2;
wptr1=(WindowPtr)((WindowPeek)wptr2->newtWindow);
と記載するところを、アクセッサー関数を利用すると...
wptr1=GetNextWindow( wptr2 );
となります。
CarbonAccessors.oを、現在のプロジェクト（InterfaceLib使用プロジェクト）に加えて、構造体のメンバーに直接アクセスしている箇所を順次変更していけば、CarbonLibをリンクしなくてもCarbon化への第一歩を開始することができます。ソースの最初には以下の定義（コンデションマクロ）を表記して、アクセッサー関数のプロトタイプを利用可能にしておきます。
#define ACCESSOR_CALLS_ARE_FUNCTIONS 1
また、次の定義をすると、構造体のメンバーに直接アクセスしている箇所があれば、何らかの警告が出るようになります。
#define OPEQUE_TOOLBOX_STRUCTS 1
ちなみに、CarbonAccessors.oに関してはCarbon Porting Guide（4/19版PDF）のChapter 2のp28から、アクセッサー関数の一覧表は、Chapter 3のp59から記載されています。名前の横に黒丸が付いたアクセッサー関数は、Mac OS X DP3から追加された物です。よって、DP4ではもう少し増えているかもしれません。
ただし、最新OS機能を利用するために、プロジェクトにWndoesLibやMenusLibをリンクしていると、CarbonAccessors.oをリンクすることでいくつかのAPI定義が重なるようで、リンク時に以下のような警告が発生します。
まあ、無視してもよいのですが、ちょっと気持ちが悪いですね。何らかのコンデションマクロの定義で避けられるかもしれませんが（深く追求していない）出来上がったアプリに問題はありません。どちらにしろ、CarbonAccessors.oは一時的な物だということを心に留めておきましょう。ひょっとすると、プロジェクト内容によっては、直接CarbonLibをリンクしてアクセッサーに書き換える方が近道（？）かもしれません。
もうひとつのLiteCarbonLibの方は、現状のMac OS XにインプリメントされているCarbon APIのエントリーポイントのみを含んでいます。これをCarbonLibの代わりにリンクしてリンクエラーが発生したら、そのアプリは現状（DP3）のMac OS Xでは利用不可（起動はできるかもしれない）となります。当然、将来的にはLiteCarbonLibは無くなり、CarbonLibのみが提供されるはずです（でないと困る）。しかし現状では、かなりのAPIがインプリメントされていません。ちなみに、私のとあるプロジェクトにLiteCarbonLibをリンクすると、以下のようなエラーメッセージが表示されます。
なんのことはない、QuickTime関係のAPIがほとんどインプリメントされていないようですね。ただしDP4では上記の問題は解決されていると思われます。（多分、きっと、であってほしい）
予定していたCarbon用のPrefix File（MacHeadersファイル）の作り方や、Carbon用リソースの話は次回に回します。