はい、リソースの概念は ResEdit 以上にすばらしいですが、これを挙げるとすると、Toolbox を挙げることになるでしょう。 Toolbox を挙げるなら System 1.0 自体を挙げることになるわけで……。
リソースの仕組みは、一種の仮想メモリとも捉えることができます。使わなくなったリソースはメモリから解放されますし、必要になれば自動的にディスクからロードされますから。
ということで、きちんとした仮想メモリが実装された Mac OS 7.5 あたりからは、リソースフォークが必要不可欠ではなくなりました。実際、PowerPC 搭載で、CODE リソースが
という点はリソースの最大の特徴ですが、それは言うまでもないことだと思って書きませんでした。
1984年当時では、先進的なアイディアだったですが、2005年の現在では、アイコンや画像などのデータは独立したファイルとして持たせる方が自然で扱いやすいと思います。実際、OS X では、パッケージの中身はふつーのファイルですし。
Finder, HyperCard, ResEdit こそ Mac の真髄 (スコア:3, すばらしい洞察)
Re:Finder, HyperCard, ResEdit こそ Mac の真髄 (スコア:2, すばらしい洞察)
リソースを参照するときって確かタイプとIDで参照しましたよね。
で、ファイル→アプリケーション→システムの順番で辿っていって
最初に見つかったものを使うというルールだったと思います。
これ、オブジェクト指向で言う多態なんですよね。
階層は固定されていましたけど。
んで、WDEF(だったと思う)というタイプのリソースがありまして、
こいつはウィンドウの形状を定義するコードだったんですが、
ResEditでこいつ
Re:Finder, HyperCard, ResEdit こそ Mac の真髄 (スコア:1)
Toolbox を挙げるなら System 1.0 自体を挙げることになるわけで……。
リソースの仕組みは、一種の仮想メモリとも捉えることができます。使わなくなったリソースはメモリから解放されますし、必要になれば自動的にディスクからロードされますから。
ということで、きちんとした仮想メモリが実装された Mac OS 7.5 あたりからは、リソースフォークが必要不可欠ではなくなりました。実際、PowerPC 搭載で、CODE リソースが
Re:Finder, HyperCard, ResEdit こそ Mac の真髄 (スコア:1)
うーむ、確かにリソースは自動的にパージされて、自動的に読み込まれる、というようにできるので、便利でしたが、それが仮想メモリかと言われると…
リソースに限らず、任意のデータをHandleに収め、テンポラリファイルにしまっておくとかして、パージ可能にするというテクニックは使ってましたし、どっちかというと、メモリが足りなくなったら自動的に移動され、さらに足りなければパージされるHandleという仕組み自体が仮想メモリの代替手段だったと思います。
リソースはコード、アイコン、画
リソース (スコア:1)
もちろん、
>リソースはコード、アイコン、画像といったデータを、先頭からのオフセットとかではなく、独立したデータ群として扱えるようにしたというところがミソだと思います。
という点はリソースの最大の特徴ですが、それは言うまでもないことだと思って書きませんでした。
1984年当時では、先進的なアイディアだったですが、2005年の現在では、アイコンや画像などのデータは独立したファイルとして持たせる方が自然で扱いやすいと思います。実際、OS X では、パッケージの中身はふつーのファイルですし。
>MacOS 9まではバージョン表示、アプリケーションアイコン、書類のアイコン、関連付けなどのために相変わらずリソースフォークは必要です。
ああ、VERS,BNDL リソースは忘れていました。アイコン関連のリソースはともかく、アプリケーションがアプリケーションとして動作するためには、リソースがまったくなしという訳にはいかないですね。ちょっと口、もとい指が滑りました。
PPC 専用ソフトなら CODE リソースは不要ですが、バイナリがどこにあるかを示す cfrg リソースが必要だったのも忘れていました。
そもそも、MBAR, MENU リソースがないとメニューが出ない!!