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

NeXTのMulti Architecture Binaryそのものと言える技術「Universal Binary」。今回から、Universal Binaryの詳細を解説していこう。

[白山貴之，ITmedia]

Universal Binary

　2005年6月のWWDC 2005にて、MacのCPUを従来のPowerPCを用いたものからIntelのx86ベースに移行させると発表された（コラム1）。当初2006年6月ごろに出荷されるとアナウンスされていたIntel CPU搭載Macは、6カ月前倒しの2006年1月に発表、出荷され、実際にIntel CPUへの移行が進んでいる。

　CPUのアーキテクチャが変わってしまうとソフトウェアは当然動かなくなる。多数のアーキテクチャに移植されているNetBSDであっても基本はソースレベルの互換性のみ、異なるアーキテクチャに移行すればソースからの再コンパイルを必要とする。もちろんMacでもそれには変わりない。PowerPCならPowerPC、x86ならx86のコードを必要とする*。ただしCPUごとに個別のアプリケーション*を用意する必要はない。Mac OS XにはUniversal Binaryという仕組みが用意されており、1つの実行ファイルで複数のCPUに対応できるからだ。

Universal Binaryの概要

　Universal Binaryは、簡単に言ってしまえば複数のアーキテクチャの実行バイナリ（コード）を貼り合わせて1つのファイルの中に収めたものだ。exec（2）システムコールはUniversal Binaryから自身のアーキテクチャに適したコードを選択、実行する。このため、あらかじめPowerPCとIntelの2つのアーキテクチャに対応したUniversal Binaryを用意しておけば、たった1つのパッケージでどちらのCPUを搭載したMacであっても適切に動作するのだ（図1）。

図1　 Universal Binaryは、複数のCPUアーキテクチャのコードを1つの実行ファイルに収める技術だ。Mac OS Xのカーネルは、FATヘッダとそれに続くfat_arch構造体の情報を見て、適切なコードを選び、実行する

コラム1　WWDCに参加しよう

　WWDCとは、World Wide Developer Conferenceの略で、Appleが開催している大規模な開発者向けカンファレンスだ。1週間にわたるこのカンファレンスでは、Appleの持つテクノロジーやそれを用いたソフトウェアの開発についての解説を受けられる。Mac OS XやDarwinを実際に開発しているApple社員など関係者によって解説されるため、核心となるポイントを抑えたものが多く、聞くだけでも参考になる。もちろん英語でという条件は付くが、講義中に質問をしたり講義後に講演者を捕まえてサシで聞き出すこともでき、Feedback session（別名、袋だたきセッション）という質疑応答専用セッションすら組まれており、実際の開発者に声を伝える最も手っ取り早い方法でもあるのだ。

　会期中、会場では朝食と夕食が用意されており、世界各地の、あるいは日本に散らばっておりなかなか会えないMac向けの開発を行っている開発者との親交を深める場となっている。圧巻は木曜日に行われるCampus Bushで、クパチーノにあるApple本社の中庭で飲めや歌えやの大宴会が開かれる。WWDC参加者はもちろん、Apple社員も大勢参加するため、日ごろの不満をぶつける、もとい親交を深めるのには絶好の場である。

　2007年のWWDCは7月11〜15日にかけて例年どおりサンフランシスコで開催された。NDAにかかわる話が中心となるためADC（Apple Developer Connection）への登録が必須、参加費は約1600ドル（通常価格。交通費および宿泊費別）とやや値が張るのが難点だが、Appleの革新的な技術に関しての知識を深める場として、また開発者同士の情報交換や親交を深める場としても、それだけのコストを払う価値があるといえるだろう。

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

x86ならx86のコードを必要とする

IntelベースのMac OS XにはRosettaと呼ばれるトランスレータが搭載されており、PowerPCのコードをメモリへロードするときにx86のコードに変換、実行することで、旧来のアプリケーションを動作させられるようになっている。

CPUごとに個別のアプリケーション

オープンソースの開発者や利用者の中には、個別にアプリケーションが用意されていても困らない、個別なのか単一のなのかはさしたる問題ではないと思っている人もいるかもしれない。しかし、例えばソフトウェアを製品として販売する立場だとそれぞれのアーキテクチャごとに製品のバリエーションを用意するのは在庫管理の手間がかさむのだ。オープンソースソフトウェアで配布を行う側としても、複数のバイナリパッケージを並行して用意するのは手間が掛かることには変わりがない。手間がかさむとメジャーなアーキテクチャ以外の製品やパッケージは用意されなくなる恐れがある。実際に、Windows NT 3.51および4ではx86版だけではなくMIPS版やAlpha版、PowerPC版が存在したが、x86以外のアーキテクチャではほとんどソフトウェアが出荷されず、フリーソフトウェアでもx86以外のアーキテクチャ向けバイナリを用意する例はまれであった。x86版よりAlpha版の方が性能が良かったにもかかわらず、Alpha版Windows NTが広まらなかった原因には、アプリケーションがないので利用者が増えない、利用者が増えないからアプリケーションが用意されないという悪循環があったからだ。