第12回 Universal Binary【前編】：Undocumented Mac OS X（5/5 ページ）

[白山貴之，ITmedia]

コラム3　Code Fragment Managerともう1つのFATバイナリ

　本文中、「MABでは、複数のCPUに対応するコードを格納した実行ファイルをFATバイナリという」とあるが、FATバイナリという言葉は、MABやUniversal Binary特有のものではなく、こうした複数のコードを貼り合わせたもの一般に用いられている。Macとしてかかわり合いが深いのは、旧Mac OSの時代に行われたモトローラの680*0からPowerPCへの移行時に存在したFATバイナリだろう。

　現在のPowerPCと同じく、当時の680*0というCPUの性能が頭打ちとなり有望な後継製品の出荷のめどは立たず、現在のIBMがゲーム業界への進出に熱心なように当時のモトローラもPC以外の異業種への進出に熱心な状態であった。CISCの680*0に見切りをつけ、当時流行であったRISCの新たなCPUとして開発されたのがPowerPCであった。

　680*0を開発したモトローラがかかわっているがPowerPCはIBMのPOWERをベースにしており、680*0と直接の互換性はない。現在のMac OS Xがそうであるように、当時のAppleも、移行先のプロセッサでエミュレータを用意し旧来のソフトウェア資産を継承しつつ、旧来CPUと移行先のCPUのどちらのコードも併せ持てる実行ファイル形式を用意し、双方で動作するアプリケーションを構築できるようにしたのだ。

　このために用意されたのがCode Fragment Manager（CFM）だ。CFMはMac OSのカーネル内部に存在し、実行すべきコードの読み込みを担当した。

　それ以前のMac OSでは、実行コードもCODEリソースという1つのリソースであった。CFMを搭載したMac OSからは、実行ファイルのcfrgリソースを基に必要なモジュールをメモリ上にロードするようになり、リソースフォークだけではなくデータフォークにコードを置くことも可能になった。fat_arch構造体と同じく、cfrgリソースにもそれぞれのコードが対応するCPUの形式が記載されており、ネイティブコードがある場合はネイティブコードを実行し、ネイティブコードがない場合はエミュレータを介して680*0向けコードを実行していた（図A）。なお、CFMが規定するのはコードの配置のみであり、実行されるコードはPEF形式やXCOFF形式が利用されていた。

図A　Mach-O形式ではデータフォークの先頭に各セグメントを配置するLoad Commandsがある。CFM形式バイナリの場合、リソースフォークにあるcrefリソースに格納されている

　Rosettaと異なりネイティブコードを実行するかエミュレータを用いるかは、このコード単位で決定される。速度が必要な部分だけをPowerPCのコードに再構築し、あまり使われない部分を680*0のコードをエミュレーションで利用することで開発効率を上げられたのだが、一方でPowerPCネイティブとエミュレーションの間の切り替え処理は非常にコストが掛かるため性能上のボトルネックとなり、せっかくのPowerPCの性能が発揮されない、遅いマシンという印象を与える*原因となってしまった。

　CFMは、PowerPC向けMac OSだけではなく680*0向けMac OSにも用意された（CFM-68k）。しかし、CFM-68kを使用する例は極めて少なく、Cyberdogなど、CFMベースでないと実行できないOpenDocを用いたアプリケーション程度しか存在しなかった。

　CFMによって、リソースフォーク、データフォークにかかわらず任意の場所に実行コードを置くことが可能になった。これを用いたトリックとして、データフォークの先頭に通常のテキストを置き、EOFマークの後ろに実行ファイルを置くといったことも行われた。すると、テキストエディタで読むと説明を書いたテキストだが、ダブルクリックするとアプリケーションとして実行されるのだ。この仕組みは後にMac OS X上のウイルスvirus.mp3によって悪用される。

　Mac OS XのカーネルにはCFMは実装されておらず、またPEFやXCOFFを実行する機能もないため、直接的にはCFMベースの実行ファイルを扱うことはできない。このため、CFMベースのバイナリをダブルクリックしたとき、LaunchServicesはそのファイルを直接exec（2）システムコールに渡すのではなく、LaunchCFMAppsという実行ファイルを起動、その引数としてダブルクリックされた実行ファイルを渡す。LaunchCFMAppsはユーザーランドで実装されたCode Fragment Managerであり、cfrgリソースに従ってコードをメモリ上にロード、実行する。

　LaunchCFMAppsの存在によって、1つのPowerPC向けCFM形式のバイナリを、Mac OS 9とMac OS Xの双方で実行でき、Mac OS 9からのアプリケーションの移行を支える一助となった。

　680*0からPowerPC、Mac OS 9からMac OS Xという2つの移行に深くかかわったCFMだが、Intelベースの移行に伴い、とうとうその役目を終え、x86ネイティブコードではもはやサポートされなくなる。

このページで出てきた専門用語

遅いマシンという印象を与える

現在からは信じられないかもしれないが、少なくとも90年代中盤までMacといえば遅いマシン、Mac OSといえば遅くメモリ食いなOSの代名詞であったのだ。Mac OSが軽いOSといわれるようになったのはここ数年のことで、ありあまるマシンパワーによってソフトウェアを強烈に後押ししているにすぎない。

本記事は、オープンソースマガジン2006年5月号「Undocumented Mac OS X」を再構成したものです。