「Appleのトップ10」記事へのコメント

Finder, HyperCard, ResEdit こそ Mac の真髄

[targz (14071)]

ClarisWorks よりも、Finder, HyperCard, ResEdit のがはるかに革新的だと思います。Finder は、グラフィカルなシェルをパソコンとして初めて実装したし、HyperCard は、カード型データベース、オブジェクト指向言語、ハイパーテキストを見事に融合させているし

Re:Finder, HyperCard, ResEdit こそ Mac の真髄

[__hage (7886)]

ResEditを挙げるならリソースの概念を挙げたいと思いました。
リソースを参照するときって確かタイプとIDで参照しましたよね。
で、ファイル→アプリケーション→システムの順番で辿っていって
最初に見つかったものを使うというルールだったと思います。
これ、オブジェクト指向で言う多態なんですよね。
階層は固定されていましたけど。

んで、WDEF(だったと思う)というタイプのリソースがありまして、
こいつはウィンドウの形状を定義するコードだったんですが、
ResEditでこいつ

Re:Finder, HyperCard, ResEdit こそ Mac の真髄

[targz (14071)]

はい、リソースの概念は ResEdit 以上にすばらしいですが、これを挙げるとすると、Toolbox を挙げることになるでしょう。
Toolbox を挙げるなら System 1.0 自体を挙げることになるわけで……。

リソースの仕組みは、一種の仮想メモリとも捉えることができます。使わなくなったリソースはメモリから解放されますし、必要になれば自動的にディスクからロードされますから。
ということで、きちんとした仮想メモリが実装された Mac OS 7.5 あたりからは、リソースフォークが必要不可欠ではなくなりました。実際、PowerPC 搭載で、CODE リソースがなくなってデータフォークに実行バイナリを収めたりしてました。

Mac OS X ではファイルパッケージが登場しましたけど、これはリソースフォークの「部品」という概念を踏襲したと思います。パッケージの中身をいじればメニューやアイコンをいじれるわけで、ResEdit という特別のツールなしに改造ができるようになっています。ですので、リソースの概念は、捨てたというより「パッケージ」という形に昇華したと考えればいいと思います。

Re:Finder, HyperCard, ResEdit こそ Mac の真髄

[__hage (7886)]

ああ、なるほど仮想メモリですか。
確かにハンドル(ポインタのポインタ)を介したオブジェクトの参照をしていたのは、
オブジェクトの移動やメモリからなくなった場合に備えるための機構でした。
ハードウェアの支援なしのソフトウェアだけで実現した仮想記憶と呼べますね。
少なくともやってることは似ています。

OSXについてはあまり知らないんですが、形を変えて概念が踏襲されてるようですね。
面白そうです。やっぱ今度はMacを買おうかなあ。

Re:Finder, HyperCard, ResEdit こそ Mac の真髄

[G7 (3009)]

Macのプログラミングは、友人から話に聞いていただけです。

＞実際、PowerPC 搭載で、CODE リソースがなくなってデータフォークに実行バイナリを収めたりしてました。

あれ？そうでしたっけ？
FatBinaryとやらを実現するためには、従来との互換性を取るために、
CODEリソースは68000系CPUのために温存し、
PowerPCのためのコードを別の場所に置く必要があった、
とかと聞いたような記憶があります。誤認でしょうか？

＞ResEdit という特別のツールなしに改造ができるようになっています。

てゆーか、ResEditが特別でない当り前のツール、と捉えたら幸せになれるのかなーと。

リソースって、ファイル(やそれをメモリにロードしたもの)の構造化ですよね。
UNIX(やそれを真似たDOS/Win系)はファイルとかメモリとかを
フラットなものとして扱い、その中身をどう区切る(構造化する)かを
もっぱらアプリに任せたけど、Macはメタ構造(？)をOSが規定した、と。

ちなみに、ああいうふうにメタ構造が最初から用意されていると、
OpenSourceというものの(技術的な)有難みが、あんまり無くなってきたりします(^^;
だってソースを見なくても「構造」が掴める(判る＆読める＆書ける)んだもん。
＃OOPなシステム(露骨なところではSmalltalkとか)でも同じことが言えます。
＃もちろんソース「も」有るに越した事はないですが。

Re:Finder, HyperCard, ResEdit こそ Mac の真髄

[juan (3871)]

＞リソースの仕組みは、一種の仮想メモリとも捉えることができます。

うーむ、確かにリソースは自動的にパージされて、自動的に読み込まれる、というようにできるので、便利でしたが、それが仮想メモリかと言われると…
リソースに限らず、任意のデータをHandleに収め、テンポラリファイルにしまっておくとかして、パージ可能にするというテクニックは使ってましたし、どっちかというと、メモリが足りなくなったら自動的に移動され、さらに足りなければパージされるHandleという仕組み自体が仮想メモリの代替手段だったと思います。

リソースはコード、アイコン、画像といったデータを、先頭からのオフセットとかではなく、独立したデータ群として扱えるようにしたというところがミソだと思います。

＞ということで、きちんとした仮想メモリが実装された Mac OS 7.5 あたりからは、リソースフォークが必要不可欠ではなくなりました。

MacOS 9まではバージョン表示、アプリケーションアイコン、書類のアイコン、関連付けなどのために相変わらずリソースフォークは必要です。PowerPCになってプログラムコードはデータフォークに置かれるようになったとはいっても、ファットバイナリのために、また、Photoshopプラグインのような、PPCコードリソースを使う場合などもあり、コードは必ずデータフォークというわけでもありませんでした。

リソース

[targz (14071)]

確かに、ハンドルの方が仮想メモリらしい実装ではありますが、リソースも仮想メモリっぽいことを実現しようとした、と捉えることもできると思います。なんせ初代 Mac は 128KB しかメモリがありませんでしたから、それを有効に使うためには、いろいろ工夫が必要だったわけで。

もちろん、

＞リソースはコード、アイコン、画像といったデータを、先頭からのオフセットとかではなく、独立したデータ群として扱えるようにしたというところがミソだと思います。

という点はリソースの最大の特徴ですが、それは言うまでもないことだと思って書きませんでした。
1984年当時では、先進的なアイディアだったですが、2005年の現在では、アイコンや画像などのデータは独立したファイルとして持たせる方が自然で扱いやすいと思います。実際、OS X では、パッケージの中身はふつーのファイルですし。

＞MacOS 9まではバージョン表示、アプリケーションアイコン、書類のアイコン、関連付けなどのために相変わらずリソースフォークは必要です。

ああ、VERS,BNDL リソースは忘れていました。アイコン関連のリソースはともかく、アプリケーションがアプリケーションとして動作するためには、リソースがまったくなしという訳にはいかないですね。ちょっと口、もとい指が滑りました。
PPC 専用ソフトなら CODE リソースは不要ですが、バイナリがどこにあるかを示す cfrg リソースが必要だったのも忘れていました。
そもそも、MBAR, MENU リソースがないとメニューが出ない!!