はい、リソースの概念は ResEdit 以上にすばらしいですが、これを挙げるとすると、Toolbox を挙げることになるでしょう。 Toolbox を挙げるなら System 1.0 自体を挙げることになるわけで……。
リソースの仕組みは、一種の仮想メモリとも捉えることができます。使わなくなったリソースはメモリから解放されますし、必要になれば自動的にディスクからロードされますから。
ということで、きちんとした仮想メモリが実装された Mac OS 7.5 あたりからは、リソースフォークが必要不可欠ではなくなりました。実際、PowerPC 搭載で、CODE リソースが
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)
>実際、PowerPC 搭載で、CODE リソースがなくなってデータフォークに実行バイナリを収めたりしてました。
あれ?そうでしたっけ?
FatBinaryとやらを実現するためには、従来との互換性を取るために、
CODEリソースは68000系CPUのために温存し、
PowerPCのためのコードを別の場所に置く必要があった、
とかと聞いたような記憶があります。誤認でしょうか?
>ResEdit という特別のツールなしに改造ができるようになっています。
てゆーか、ResEditが特別でない当り前のツール、と捉えたら幸せになれるのかなーと。
リソースって、ファイル(やそれをメモリにロードしたもの)の構造化ですよね。
UNIX(やそれを真似たDOS/Win系)はファイルとかメモリとかを
フラットなものとして扱い、その中身をどう区切る(構造化する)かを
もっぱらアプリに任せたけど、Macはメタ構造(?)をOSが規定した、と。
ちなみに、ああいうふうにメタ構造が最初から用意されていると、
OpenSourceというものの(技術的な)有難みが、あんまり無くなってきたりします(^^;
だってソースを見なくても「構造」が掴める(判る&読める&書ける)んだもん。
#OOPなシステム(露骨なところではSmalltalkとか)でも同じことが言えます。
#もちろんソース「も」有るに越した事はないですが。