








Macintosh Toolbox
Macintosh OS ルーチンの一つ、もしくは、総称。
当初は、MacintoshのROMに書き込まれたサブルーチン郡であり、厳密にはOSの一部というよりはBIOSの一部と言う方が近いかもしれない。
GUI関連のルーチンの多くがROMに書き込まれていた事と、呼び出しに68000の未実装命令例外を使用していた事で、少ないメモリー、小さなOSコードでも、充分な速さのGUIアプリケーションを作成できるメリットがあった。
--CUE
このToolboxにはいくつか欠点がある:この欠点のいくつかは誤った形で理解されて広まり、Macintoshプログラミングに明るくない人々に幾ばくかの誤解を与える結果となったように思われる。
欠点の一つは、Handleの扱いである。
Handleは、現在のメモリ管理の考え方で言えばガベージコレクションの一手法として理解されるが、逆にその事が、Handleを古くて遅い駄目なメモリ管理手法のように言われる原因となっているように思われる。
Handleそのものは、あくまでも連続した有限長のメモリ領域を、一意なポインタで参照する手段でしかない。それがたまたまOS側から見るとガベージコレクションのように見えるというだけの事である。
ToolboxにおけるHandleの最大の欠点は、パージされたHandleが参照された際に、内容を復帰させるタイミングを知るエレガントな方法が提供されていない事である。同様に、Handleがパージされるタイミングをエレガントに知る手段も提供されていない。この二つ、少なくとも前者だけでも存在すれば、Handleを動的なオブジェクトとして強力に使用する事ができたはずだ。
別の欠点は、イベントの扱いである。
CarbonEventManagerが出現する以前は、イベントを受け取ったアプリケーションは、それがGUI上のどのオブジェクトのためのイベントなのかを自分でディスパッチする義務があった。
この点では、Windowsのウインドウクラスの考え方の方がまだはるかに合理的だった。
三つ目の欠点は、割り込み処理とスタック(ローカル変数)の扱いである。
Macintoshはディスクドライブの読み書き制御(!)をはじめ、割り込みに依存した処理が多かった。
(余談だが、Macintosh SE以降のマシンでディスクドライブをインテリジェント化しなかったのは、Appleの最大の失敗であると思う。)
その割り込み処理において、ローカル変数を固定されたメモリ領域として割り込み処理内で使用しても良いとした点が、逆にスタック領域の移動を制限してしまうため、その後のマルチタスク化におけるネックとなってしまった。
--CUE
よく槍玉にあげられるMutiFinderの欠点が、実はかつてMicrosoftExcelバージョン2に付属していた(確か、Microsoft製の)Switcherというユーティリティが発端だという事(私はそう理解している)はなぜかあまり知られていないようだ。
SwitcherはMultiFinder同様に同時に複数のアプリケーションをオンメモリで起動できるようにするユーティリティである。MultiFinderとの違いは、アプリケーションを紙芝居のように画面ごと切り替えている点である。
このSwitcherに対応した製品がその後作られ、販売されたことから、この時のメモリレイアウトの仕組みや、クリップボードの変換やマウスカーソル形状変更のタイミングを知らせるイベントなどがそのままMultiFinderでも採用される結果となってしまった。
このSwitcherのメモリレイアウトの仕組みから来るアプリケーションごとのヒープサイズの設定という制約や、ToolboxのHandleに対する誤解から、周囲からバーチャルメモリもまともに使えない駄目OSという烙印を押される結果となったわけである。
しかしもとをただせば、それは必ずしもAppleだけの責任ではないのである。少なくとも、私はそう考えている。
--CUE
>(確か、Microsoft製の)Switcherというユーティリティ
Switcher はアンディ・ハーツフェルドの手による Apple 社製ユーティリティです。
--sumim
>Apple 社〜
うむむ、そうすると、私がAboutダイアログで見たと思った“(c)Microsoft”の文字は、私の記憶違いだったようです…(アイコンが違ってる理由はわかりませんが)。--CUE
>〜製ユーティリティです。
読んでみたところでは、Apple社内で開発されたものではなく、Appleが件の人から買ったもののようですが…。--CUE
>Appleが件の人から買ったもの
そうですね。買い取ってラベルを付けかえて自社“製”品としてリリースする例は Apple に限らずたくさんがありますが…。余談ですが参考までに、ハーツフェルドは 1984 年まで Apple で働いていて、Macintosh OS の主要開発メンバーのひとりでもありました。--sumim
このページを編集 (3873 bytes)
 |
このページは Swiki ブック内で孤立しています。 |
This page has been visited 2839 times.