数日前にアップルでiBookの説明会があったことを紹介した。その後、MacWIREの松尾編集長と会話をしていたとき、松尾編集長から「CarbonのアプリケーションはそのままMac OS Xで動くのでしょ？」と聞かれたが、私は「そんなことはないのでは…」などと話してしまった（理由は後で…）。だけど、実はそんなことなくはないのであった。Carbonアプリケーションは、Mac OS、Mac OS Xの間でバイナリ互換なのであった。だけど、互換だからと言�辰討修里泙淨阿�すのがいいのか悪いのかという点も考えてみた。
Carbonは、Mac OSとMac OS Xの両方で利用できるアプリケーションフレームワークであり、C++はもちろん、C言語ででも開発ができる。従来のMac OSのToolboxとの互換性が高く、Toolbox向けに作られているアプリケーションであれば、ある程度の修正でMac OS Xの本来の機能を使って動かすことができるというのが大きな売り文句となっている。従来のMac OSのアプリケーションは、Classic環境で全くの変更なく動作する上に、Carbon対応することでMac OS Xのマルチタスク環境下で稼動するのである。こうした特徴で、Appleは開発者をMacintoshプラットフォームに留まらせることに成功したのだ。従来のアプリケーションは、まずはCarbon化を図ることになるわけだ。 さて、CarbonはMac OS 9とともに出荷され、対応アプリケーションもそろそろ出てきている。有名なところではAppleWorks 6がそうだ。そのAppleWorks 6のアプリケーションをMac OS Xにファイルコピーして実行してみた（仕様許諾上若干問題があるが、テストと言うことで大目に見てもらいたい）。何と、起動する！ メニューも日本語だし、日本語表示に関してはまったく問題がなかった。表計算書類を新しく用意できなかったけども、ワープロは用意できた。ではかな漢字変換！ うーん、残念、ここでドスンと落ちてしまった。ことえりをアクティブにして、少しでもキータイプすると落ちる。落ちても安心なのはMac OS Xのいいところ…などと納得してはいけないのだが、いずれにしても日本語入力はまったくできなかった。ここで分かったことは、Mac OS 9のCarbonで動くアプリケーションのファイルは、そのままMac OS Xにコピーした場合Mac OS XのCarbonで動くということだ。Mac OS XのClassic環境で動くのではない。AppleからはCarbon対応のサンプルソースがいくつかすでに公開されており、それらはCodeWarriorでビルドされたものである。これらも同様にファイルコピーをしてMac OS Xの上で稼動したのである。 ここで、Process ViewerでMac OS Xでの実行プロセスを見てみた。すると、実行するCarbonアプリケーションの数だけ、LaunchCFMAppというプロセスが立ち上がるようだ。つまり、OSレベルでのプロセスでは、「AppleWorks 6」ではなく、Carbonアプリケーションは一律に「LaunchCFMApp」と認識されるようだ。これがCarbonアプリケーションを起動させる受け皿のようなものと考えていいだろう。しかしながら、それぞれ別のプロセスになっているため、メモリ上の保護は受けられると考えていいと思う。マルチタスクの効率的な稼動は、プロセスレベルでは可能だろうけどアプリケーション側にイベントループが残っていれば、いくらかは足枷になるのではないかなとも思われるが、その場合でも他のプロセスにはイベントループのオーバーヘッドは影響は薄いだろう。 いずれにしても、CFMつまり、Code Fragment ManagerベースのPowerPCバイナリが、アプリケーションの実体なのである。PowerPC対応とともに導入されたCFMであり、Inside Macintoshなどで詳しい資料がある。もちろん、プログラマは知っておくべき知識なのだが、実はアプリケーションを作るくらいだと、面倒なことは全部開発ツールがやってくれるので、CFMうんぬんはほとんど気にしなくてもよかったのである。だが、Mac OS X時代になり、また少し露になったのだ。Carbon以前からPowerPC対応のアプリケーションはCFMをベースにして実行するPowerPCのマシン語バイナリの固まりであり、それをファイルのデータフォークに収めているのである。ちなみにデータフォークにあるという情報がリソースフォークに納められる。Mac OS Xでアプリケーションをダブルクリックしたとき、それにCFMがあった場合、おそらくCarbon対応となっているかをなんらかの方法で突き止め、対応であればLaunchCFMAppによってネイティブに起動し、対応していないCFMであればClassic環境で起動するということを行うのではないかと考えられる。
なぜ、最初に、Mac OSとMac OS XでのそれぞれのCarbonで別々のバイナリが必要になると思ったかと言うと、Inside Mac OS X: System Overviewの深読みし過ぎが原因だった。この書籍では、「バンドル」という実行に必要なファイルを集める手法が掲載されている。おそらくバンドル化したアプリケーションを「パッケージ」と呼ぶようになるのだと思われる。そこの説明で、バンドル化したディレクトリのサンプルに、Mac OS向けのアプリケーションとMac OS X向けのアプリケーションを別々に用意するものがあったのだ。だけど、これは、おそらく、Carbon非対応のものとCarbon対応のものという意味のようだった。ちょっと先走った理解だった点を反省。
では、Carbon対応のアプリケーションは、Mac OSとMac OS Xに共通のバイナリとして作るのだろうか？ 小池さんの連載にもあったように、それをすると、メニューを切り替えるなど、動作環境に応じた条件分岐をしなければならなくなる。それをダイナミックにやるよりも、コンパイラの機能を使ってそれぞれ生成する方が何となく安心という気もする。また、インストーラの問題もある。実は、AppleWorks 6を、Mac OS Xのシステムに対してCD-ROMからインストールしようとしたのだが、インストーラが起動しなかった。どうやらインストーラ系はMac OSとMac OS Xでは異なるものを採用することになりそうなのである。結果的に、インストーラはそれぞれのOSで作ることになるのなら、最初から別物として作っておく理由ともなる。このあたりは実際に開発者がどう行動し、ユーザが何を望むのかと言うことを逐一チェックをしながらすすめていくしかないところだろう。 同じCarbonでも、Quitメニューの位置が違うし、Mac OS XならアプリケーションメニューにPreferencesが欲しいところだ。Mac OSだけを考慮したCarbonアプリケーションは、FileメニューにQuitがあり、Preferencesはグレーのままで選択ができない。ただしアプリケーション名のメニューにも、自動的にQuitは追加される（ちなみに、Mac OS X Public BetaにあるApple System Profilesは、Mac OS 9のものをそのまま持ってきたのだろう。FileメニューにQuitがあるが、一部に参照できない情報もあり、やはりそのままで必ずしも動かないことを示唆している）。Mac OS向けに作ったCarbonアプリケーションもまったく使えないわけではないが、やはりMac OS Xに向けた最適化は必要になるし、動作上の修正も必要になるだろう。そういうところとの折り合いは必要である。 「Mac OS Xで動かすことしか考えていないCarbonアプリケーション」というものも出てくるだろう。というのは、Carbonのバージョンの経緯を考えれば、そうせざるを得ないことも考えられる。類推だがMac OS X Public BetaのCarbonは1.1なのであり、REALbasic 3.0のα版のように、Carbon版はMac OS Xでのみ機能するような注釈をしないといけなくなる。そうしたアプリケーションは、せめてMac OSで起動したときにはダイアログボックスを出して、Mac OS Xでしか動かないことを示したいということになるだろうか。なんだか、PowerPCが出た時のことのような話題になりそうだ。しかしながら、Carbonはプラットフォームに合わせた動作の違いがあるため、FATバイナリとはちょっと違う。とにかく、ユーザ動向を見ながら開発者は適切な“ファイル”を供給する必要があるというのがさしあたっての結論だが、ちょっと月並みだっただろうか。