第9回 HFS、HFS Plusの基本的概念【後編】：Undocumented Mac OS X（1/4 ページ）

Mac OS XのデフォルトファイルシステムHFS Plus。前編、中編とHFSおよびHFS Plus共通の機能を解説してきたが、基本的概念の紹介は今回で終わりとなる。今回は、リソースフォークを中心に解説する。

[白山貴之，ITmedia]

HFS Plusの詳細機能

　前回紹介したもの以外にもHFS Plusにはいろいろと興味深い機能や仕様がある。ここでは、そうしたものをトピックごとに説明しよう。

リソースフォーク

　すでに説明したように、リソースフォークはHFS Plusの持つ「もう1つの」コンテンツである。データフォークが特定の構造を前提としない、アプリケーションやユーザーが内容を決められるバイトストリームであるのに対して、リソースフォークはMac OSにより厳密に定められたデータ構造を持つ。この隔離されたソースは、データの「型」を指定する4文字のリソース名と型ごとのID番号により識別される。

　Mac OS X以前のMac OSでは、アプリケーションを構築するのにこのリソースフォークが活用されていた。ウインドウの位置や形といった定義や、メニューの項目、メッセージの文字列などがそれぞれWIND、MENU、STR#といった型を持つリソースとして定義され、アプリケーションそのものの実行コードとは分離して*格納されていた。実行コードとの対応は、その型とID番号で行われている。

　ウインドウの初期位置の変更やメッセージの修正などではいちいち実行コードを直す必要がなく、リソースを書き直せばいいというこの構造は、当時としては画期的であり、MicrosoftのWindowsやSHARPのSX-WINDOWをはじめとして、ほかのウインドウシステムのアプリケーションの構造にも大きな影響を与えた*。

　優れた仕組みではあったが、一方、リソースを区別するのが型とID番号だけのフラットな構造であり、階層構造を持てなかった。分かりやすい名前によるリソース管理ができないため、開発者に対する負担が大きく、また国際化のように、実行時の状況ごとに異なるリソースを適用するという状況には対応できなかったのだ。

　さらに、例えば同じ「音声」というデータであっても、データフォークに格納されたサウンドファイルとリソースフォークに格納されたサウンドリソースでは扱いが異なるなど、ユーザーにとっても分かりにくい面があった。

　Mac OS Xではリソースフォークは使用しない*。アプリケーションは単一のファイルではなく、特定の構造を持つディレクトリで表現されている。リソースフォークという別領域に区画を作り管理するのではなく、通常のファイルとディレクトリという方法で管理を行うのだ。このため、言語ごとに別ディレクトリを用意、階層構造を利用して言語ごとのリソースを別途管理することもでき、さらにそれぞれのリソースは通常のファイルなので、一般的なファイルと同じように扱える。

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

アプリケーションそのものの実行コードとは分離して

PowerPC以前は、アプリケーションの実行コードも「CODE」というリソースであり、リソースフォークに格納されていた。PowerPC対応後はデータフォークにも実行コードを格納可能となり、どこにどういった実行コードがあるかはCREFというリソースで管理され、Code Fragment Manager（CFM）というMac OSのモジュールがCREFを見て必要なコードをロードするようになった。

ほかのウインドウシステムのアプリケーションの構造にも大きな影響を与えた

これらのウインドウシステムのアプリケーションは、実行バイナリそのものをリソースフォークのような構造を持つ形状に分割、アプリケーションと定義を分離格納するという方式を採用している。いってみれば、リソースフォークが優れていたのはそうした構造を持つことであり、積極的にほかのシステムに取り入れられていったが、それをデータフォークと別に格納するというのはやりすぎであり、結局誰も追従しなかったのだ。

Mac OS Xではリソースフォークは使用しない

Carbonでは互換性のためリソースフォークにあるリソースを読み込めるが、これもデータフォークへの格納が推奨されている。