Plus共通の機能を解説してきたが、基本的概念の紹介は今回で終わりとなる。今回は、リソースフォークを中心に解説する。Plusにはいろいろと興味深い機能や仕様がある。ここでは、そうしたものをトピックごとに説明しよう。Plusの持つ「もう1つの」コンテンツである。OSにより厳密に定められたデータ構造を持つ。この隔離されたソースは、データの「型」を指定する4文字のリソース名と型ごとのID番号により識別される。OSでは、アプリケーションを構築するのにこのリソースフォークが活用されていた。ウインドウの位置や形といった定義や、メニューの項目、メッセージの文字列などがそれぞれWIND、MENU、STR#といった型を持つリソースとして定義され、アプリケーションそのものの実行コードとは分離して*格納されていた。実行コードとの対応は、その型とID番号で行われている。ウインドウの初期位置の変更やメッセージの修正などではいちいち実行コードを直す必要がなく、リソースを書き直せばいいというこの構造は、当時としては画期的であり、MicrosoftのWindowsやSHARPのSX-WINDOWをはじめとして、ほかのウインドウシステムのアプリケーションの構造にも大きな影響を与えた*。優れた仕組みではあったが、一方、リソースを区別するのが型とID番号だけのフラットな構造であり、階層構造を持てなかった。分かりやすい名前によるリソース管理ができないため、開発者に対する負担が大きく、また国際化のように、実行時の状況ごとに異なるリソースを適用するという状況には対応できなかったのだ。同じ「音声」というデータであっても、データフォークに格納されたサウンドファイルとリソースフォークに格納されたサウンドリソースでは扱いが異なるなど、ユーザーにとっても分かりにくい面があった。Xではリソースフォークは使用しない*。アプリケーションは単一のファイルではなく、特定の構造を持つディレクトリで表現されている。リソースフォークという別領域に区画を作り管理するのではなく、通常のファイルとディレクトリという方法で管理を行うのだ。このため、言語ごとに別ディレクトリを用意、階層構造を利用して言語ごとのリソースを別途管理することもでき、さらにそれぞれのリソースは通常のファイルなので、一般的なファイルと同じように扱える。このページで出てきた専門用語アプリケーションそのものの実行コードとは分離してPowerPC以前は、アプリケーションの実行コードも「CODE」というリソースであり、リソースフォークに格納されていた。OSのモジュールがCREFを見て必要なコードをロードするようになった。ほかのウインドウシステムのアプリケーションの構造にも大きな影響を与えたこれらのウインドウシステムのアプリケーションは、実行バイナリそのものをリソースフォークのような構造を持つ形状に分割、アプリケーションと定義を分離格納するという方式を採用している。いってみれば、リソースフォークが優れていたのはそうした構造を持つことであり、積極的にほかのシステムに取り入れられていったが、それをデータフォークと別に格納するというのはやりすぎであり、結局誰も追従しなかったのだ。Xではリソースフォークは使用しないCarbonでは互換性のためリソースフォークにあるリソースを読み込めるが、これもデータフォークへの格納が推奨されている。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。