ミームと宗教。そしてちょっとだけコンピューター
人類は脳を発達させ、言語を発達させ、抽象概念を発明し、文字を発明して記録を残せるようになった。遺伝子的、肉体的に我々ホモ・サピエンスは10万年前とほとんど変わらないはずなのに、生活や文化がまるで違う。これはまぎれもなく進化論的現象であり、この時間ではあまり変化していない遺伝子ではなく、我々人類が次代に伝えてきた情報こそがこの変化の主体となった遺伝子的存在である。そしてそれを担う情報の単位をミームと言う。ミームは脳から脳へと伝わる過程で変異し、淘汰される。
ミームと言う概念は、進化生物学者のリチャード・ドーキンスが「利己的な遺伝子」という著作で提唱した概念なのだが、僕はもっともらしいけど微妙じゃないかなと思ってた。その僕が「うわあ！これミームだ」と思ったのは、SF作家の山本弘先生が見出した「棒の手紙」の変遷だ。元祖チェーンメールともいうべき「不幸の手紙」。それが複製されていくに従って文字の汚さから「不幸」→「棒」と「突然変異」を起こす。不幸の手紙は、不幸になるのを避けるために複製と配布が必要とされており、それが生き残り戦術だったはずなのに、「不幸が訪れます」が「棒が訪れます」に変異しても即座に感染力を失わなかった。確かに棒が訪れたらなんか怖い。肉体の遺伝子にしても、ある環境で役立っていた表現型が変異によって役立たなくなるとして、即座に淘汰されるわけではなく、それはそれで特定の環境において生き残りに繋がったりする。赤血球が棒状になる「鎌状赤血球」という遺伝疾患は酸素運搬の点で不利であり、普通の赤血球をもつ人より生存能力は低いはずだが、マラリアに強い耐性を持つため、熱帯地域では有利だったりする。「棒の手紙」は「不幸の手紙」のわかりやすい恐怖より「わけのわからない恐怖」もしくは「なんだかおもしろくなっちゃった」で感染力を獲得したのだろう。
さて、僕が思うに人類のミームで最も古く、またもっとも強力なものは「神」もしくは「宗教」の概念だと思う。宗教は少なくとも古代都市国家を支配した原理になっていたし、現代でも十分に強い。そして時代の変遷の中で変異し、淘汰されてきている。
ユダヤ教の神はもともと古代オリエントのアブラハムやヤコブ、イサクといった祖先を祀る部族の神だった。古代宗教にありがちな「うちの神」信仰で、おそらく周辺の他の神々と張り合う「一柱」であったろう。その民族をまとめたモーゼが「かつてアブラハムの神、イサクの神、ヤコブの神とよばれた『ありてあるもの（ヤハウエ）』」という名前を与え。「他の神々を崇めるの禁止」戒律を作り、やがてキリスト教の理論武装に従って「他の宗教の神々は嘘、あれ悪魔」って感じに変異していく。
ゴータマ・シッダールタは「不幸の源は生老病死への執着だから、執着を捨てよ」と至極あたりまえのことを語った。死後の事を問われて「死んだ人がなんか言った？そんなこと考えたら苦しいだけじゃね？」と答えなかった。なのにゴータマ死後の仏教は六道輪廻という教義を作り、宗派ごとに「悟りに至るのは難しすぎるから阿弥陀仏にすがって南無阿弥陀仏を称えよ」「今までの教えは方便だった。ゴータマは死ぬ直前、とても死にそうな人が残せないような長大な法華経を言い残した」「ありがたい南無妙法蓮華経の題目を称えよ」ってな具合にいろいろ祭り上げて「これをやっとけば死んでも大丈夫」「葬式で坊さんに大金払えば死んだ家族の成仏が約束され、上流階級みたいな戒名もらえる」という方法を作り出した。これも変異と淘汰に生き残ってきたミームである。
コンピューター業界はそのはじめから膨大な労力と費用を必要としたのだが、低コスト化が進んだ1980年代以降、個人がアイデア次第で起業して大儲けという一括千金型の流れと、「ソフトウェアは本質的に自由であるべき、ハックすることこそ自由である」と主張する流れが発生している。前者は経済原理に基づくミームなのだが、後者は宗教と同様のミームを感じる。ソフトウェアの自然淘汰がどちらかを絶滅に追い込むのか、草食動物と肉食動物の軍拡競争、赤の女王仮設に従って双方発展していくのか、興味深い。
MacOS Xの誕生はわりとゴタゴタしていた。
Appleは、初代Macintosh以来のOSを、極力互換性を損ねないように拡張していた。擬似マルチタスクの導入、仮想記憶のサポートと32ビットアドレスへの対応。このへんはDOSや初期のWindowsに比べても先進的でスマートだったと思う。しかし、Win32アプリがプリエンプティブに動くWindows95が喝采とともに登場した頃、Macはまだ擬似マルチタスクだったし、メモリプロテクションもなく、アプリケーションの不具合で容易にOSを巻き込んで爆弾を出していた。AppleはコードネームCopland、予定ではMacOS 8となるOSにおいて先進的OSへと脱皮することを試みた。マイクロカーネルのもとでメモリは保護され、プリエンプティブ・マルチタスクが実現し、オブジェクト指向の環境が実現するとされていた。UIも大きく発展するはずだった。しかもこれまでのOSと完全な互換性をもつとされていたのだ。
しかしCoplandは遅々として進まず。目標も修正されていった。プリエンプティブ・マルチタスクができるのはUIを持たないバックグラウンドプロセスのみとされた。当たり前だがユーザーが直接触るのはUIを持つ「普通の」アプリケーションであるので、これは結構がっかりする話だった。
このあと、ギル・アメリオCEOの元でCoplandの開発状況が精査され、びっくりするほど「何も出来ていなかった」ことが明らかになり、外部からOSを調達する決断を下したのは有名な話だが、一応Coplandの開発版はデベロッパ向けに配布された事実がある。
まあ、この動画見ても、どうやら使い物にならなそうな段階であるのはわかるけど（笑）。
さて、結局Coplandをキャンセルしてスティーブ・ジョブズのNeXTを買ったAppleだが、当初のプランはその後実現したMacOS Xとはちょっと違っていた。
コードネームRhapsody。NeXTのOS、OPENSTEPを少々手直しし、旧MacOSのソフトを動かすエミュレーション層のBlueBox、OPENSTEPそのもののYellowBoxが同居し、かつインテルx86版も登場する予定だった.（インテル版ではBlueBoxは動かない)。なお、OSとしてのRhapsodyとは別に、YellowBox for MacOS,YellowBox for Windoes95/NTも予定されていた。これらはWindowsやMacOSの上でOPENSTEP系のアプリケーションを動かす機能拡張だ。正直やりすぎである。
Rhapsodyは実際に比較的ちゃんと動作する開発版がデベロッパ向けに二回リリースされたが、DR1はほんとにテーマをMacOS8風に変えただけのOPENSTEPで、一応メニューバーはあるが、Finderの代わりにNeXTのワークスペースが表示されるありさまだった。
DR2はNeXTのアプリケーションパネルが消え、ハードディスクやゴミ箱のアイコンが右に移動した分普通のMacOSに近づいた見た目にはなっていた。
ただ、なまじ似ているがためにかえって慣れ親しんだMacOSとの違いが気になるし、RhapsodyのYellowBox APIはOPENSTEPそのままで、Macとは全く違っていたから、Adobeを始めとするMac用の大手ソフトハウスは否定的だった。Macのソフトがそのまま動くBlueBoxというのは一つのアプリケーションで、その中で従来のMacOSを動かす、現代で言うVirtualBoxとかHyper-Vみたいな仮想環境に近い、BlueBox内で動くMacソフトはRhapsodyのモダンな機能は使えず、今までと同様OS（BlueBox内のMacOS)を巻き込んでクラッシュする。モダンOSの恩恵を受けるにはAPIが全く違うYellowBoxへの移植が必要になる。
結局RhapsodyはMacOS X Server 1.0として販売されることになる。サーバ用なら通常の個人用デスクトップアプリを多用することもないので、とりあえず市場に出すことが出来た。
で、個人用のOSに関しては、ごちゃごちゃしすぎたRhapsody計画を整理し、Intel版とか従来OS用YellowBoxとかは中止。YellowBox APIと、BlueBoxではあまりに断絶していたので、仮想環境ではなくネイティブに動き、モダンOSの恩恵を受けるが、いくらかソースの修正が必要になる Carbon APIを実装することになる。これなら受け入れられると、従来のデベロッパたちも歓迎。ファイルマネージャーもNeXTらしすぎるWorkspace Managerではなく、Carbonで書き直されたFinderに置き換えられた（ただし、便利なカラム表示の機能はFinderにもつけた）。また、OPENSTEPの画面描画を担っていたDisplay Postscriptは、おそらくこの時点でPDFベースの新描画エンジン、Quartzに置き換えられた。Adobeのライセンス料が高額だったことが変更の主な理由とされている。まあOPENSTEPは金融機関とか高等教育機関、研究機関向けに販売されていたもので、個人用ではちょっと価格に転嫁できないようなものが使われていたのだろう。
そして登場するのがMacOS X 10.0である。
いやこれはまいった。画面デザインが大きく変更され、MacOS 8の路線とも、NeXTの路線とも全く違う鮮やかなUIが出現した。はっきりいってこけおどしなんだけど、これにはほんとに「こけおどされ」た。一刻も早く実際に触ってみたいと思わされてしまった。まんまとスティーブ・ジョブズの手のひらで踊ってしまった。まあ楽しかったのでOKだろう。
ただし、当時の多くのMacユーザーは「コマンドラインが根っから存在しないMac」の哲学を愛しており、Terminal.appでUNIXのシェルを触れる事自体を退化だと見なす傾向があった。もっとも、NeXT時代からOPENSTEPを使ってきたユーザーや、簡単に使えるUNIXマシンとしてMacを買った新規ユーザーはそんなMac哲学にこだわらなかったし、旧来のMacユーザーたちもやがて慣れた。
タバコのCMは総じてかっこよかったが、たまに…
タバコのCMが禁止される以前、タバコ会社はなかなかカッコイイCMをよく流していた。まああれは確かに「タバコ＝カッコイイ」のイメージが出来てしまうと思うので、世界的に喫煙が排除される時代に禁止されていったのはしょうがないと思う。
中でもフィリップモリス社の「ラーク」は、スパイ映画をイメージさせるCMで、最後に「Speak Lark」という決め台詞を定着させる一連のシリーズを作成した。俳優は当初ジェームズ・コバーンが努めたが、後にロジャー・ムーアやティモシー・ダルトンといった、007役者が演じているところも見逃せない。ちなみにジェームズ・コバーンは007ではなく、007ブームに便乗して作られた「電撃フリントGO!GO作戦」というスパイ映画の主役をやっていた俳優である。ジェームズ・ボンドとフリントの違いは、007は毎回ボンドガールがだいたい一人なのに対し、フリントはやたら作中で女に囲まれてるというハーレム体質のスパイであるあたりだろう。ラークのCMはどちらかと言うと007風なので、後に007の俳優に交代したのもわかる。
ニコニコ動画にあったラークCM集だが、全体にあとになるほど豪華になっていくような印象はある。実はこれらの前に、妙にダサく感じるCMがあったと記憶しているのだが、これは動画サイトを回っても見つけることができなかった。
内容を思い出して書いてみると、室内セットで撮影されており、ジェームズ・コバーンが一人でゆっくり歩きながら画面に向かってセリフを言う。
「James Coburnデス。マロヤカナ、アジトカオリ、ノ、イイコトバ、ソレハLark。Speak Lark」
日本語である。なぜ吹き替えもしくは字幕にしなかった！非常にたどたどしい日本語で宣伝文句を語るジェームズ・コバーン。なんともかっこ悪かった。キリッとした背広姿で、歩くポーズもカッコイイのに台詞が台無し。
いやBOSSの宇宙人ジョーンズことトミー・リー・ジョーンズもCM中で日本語語ったりしてるけど、あれは日本でいろんな職業を体験する宇宙人を演じているのであって、「この惑星の◯◯は…」っていう心の声は渋くカッコイイ吹き替えが当たってるし。
多分この、ジェームズ・コバーンが日本語で宣伝するCMは、不評だったと思う。まもなくドラマ仕立てで最後に「Speak Lark」って言うだけのシリーズになったから。
角丸長方形はどこにでもある！
Folklore.org: Round Rects Are Everywhere! アンディ・ハーツフェルドの記事の翻訳。Macintosh開発当時の興味深い話です。
角丸長方形はどこにでもある！
著者：アンディ・ハーツフェルド
時期：1981年
登場人物：スティーブ・ジョブズ、ビル・アトキンソン
ビル・アトキンソンは多くの仕事を自宅でこなしていたが、何か重要なことがあれば即座にAppleに駆けつけ、それを理解できる人間に見せていた。今回彼は、ほんとにすごいアルゴリズムを思いつき、それを使った円弧の描画ルーチンを実装したので、テキサコタワーのマッキントッシュオフィスにやってきたのだった。
ビルは、当時まだLisaGrafと呼ばれていたMacintoshの描画ライブラリ、QuickDrawに円と円弧を描く新しいコードを追加した。円の数学が平方根を必要とするが、LisaとMacが使用していた68000CPUは浮動小数点演算を扱えなかったので、これは難しい問題だった。ビルは非常に賢いやりかたで、円の計算を足し算と引き算だけでできるものにしてしまった。68000は掛け算や割り算も使えたのだが、これらは遅かった。
ビルの工夫は、奇数の数列を足したものは常に自乗の数列になるということだった（1 + 3 = 4, 1 + 3 + 5 = 9, 1 + 3 + 5 + 7 = 16）。これを使用することでループ変数の脱出条件を簡単に求めることが出来、QuickDrawは円弧の描画を非常に素早く行うことが出来た。
これを使ったデモは、Lisaの画面をランダムなサイズの楕円が埋め尽くし、しかもはるかに想像をこえた速度だった。だが、スティーブ・ジョブズはこれになにか不満だったようだ。「なるほど、円と楕円はうまくいった。ところで角の丸まった長方形はどうだ？同じようにできるか？」
「いやそれは無理です。角丸長方形を実現するのは遥かに難しい。それにそんなもの必要ですか？」ビルはスティーブが円の高速描画を思ったほど評価せず、より多くを望んだことにムッと来ていたと思う。
スティーブは急に怒り出した。「角の丸まった長方形はどこにでもある！ この部屋の中を見てみるといい！」実際そういう形はそこらじゅうに存在した。ホワイトボードもデスクも角丸長方形だった。次に彼は窓の外を指さした。「外を見てみろ！もっともっとあるだろう」彼はビルを連れ出して、角の丸まった長方形のものを見るたびに説得した。
最終的に角の丸い「駐車禁止標識」を示されたところでビルが折れた。「負けましたよ。どんなに困難でもやります」彼はその作業をやるために家に戻っていった。
何日か後の午後、ビルは満面の笑顔でテキサコタワーに戻ってきた。新しいデモは美しく角の丸まった長方形を猛烈な速度で描画していた。それはただの長方形を描くのと殆ど変わらなかった。このコードをLisaGrafに加える際、彼はこの角丸長方形を「RoundRects」と命名した。その後の何ヶ月かで角丸長方形は多くのユーザーインターフェース部品に取り入れられ、欠かせない要素になったのだった。
初期のMacでDA用ウィンドウや、ボタンの描画に角丸長方形が多用されていたが、Windowsも、X11の各種ウィジェットも、角丸長方形をほとんど使用しない時代が長く続いた。輪郭に明色と暗色を使って立体的にするような発展はあったけど、ボタンは長い間四角いままだった。Windowsをバカにする系の典型的マカーだった僕がWindowsを使用するようになるのは、ボタンの角が丸くなったXPからである。それほど各丸長方形は重要だと思う。なんでWindows10でまたカクカクになるんだよおい（笑）
Radikoolで無劣化録音
インターネットラジオ Radikoの番組を録音するソフトとして、現在も開発が続けられている無料のソフトがRadikoolだ。以前Radikaというもう一つのソフトがあって、そっちが好きだったのだけど、残念ながら開発が中断してしまっており、使い続けるのがいろいろ難しい状況になっている（まだ使えないことはないけど）。
RadikaとRadikoolの最も大きい違いは、Radikaが配信される音声データをそのままコンテナだけ変えて保存するのに対し、Radikoolは一旦デコードされた音声をユーザーの好みのフォーマットで再エンコードして保存するということだろう。Radikoの音声は48kbps、AAC-HE形式なのだが、これをmp3やm4a,aacといったフォーマットに変換するようになっている。ただ、もともとAAC-HEで結構綺麗な音になってるものを、mp3とかに変換すると、ビットレートを大きくしないと音が劣化してしまう。どうせ今時のパソコンではAAC-HEが聞けないってことはないだろうから、再変換なしで保存してしまえば一番じゃないかと思うのだ。なぜか無変換で保存するオプションはデフォルトでは用意されていないのだけど、ちょっと設定すれば可能になる。
「録音形式」の任意の形式を選んで、「簡単設定」は無視。「高度な設定」で「ffmpegの引数を指定する」にチェックを入れ、「録音ファイルの拡張子」に「m4a」を指定。
「ffnpegの引数」に
「-metadata genre="radio" -acodec copy」
と設定する。「 -acodec copy」は、音源のコーデックをそのままコピーし、再エンコードしない指定だ。
そしてこの録音形式を使用するようにすればよい。再エンコードでどれだけビットレートを上げても、元の音より良くなるわけはないので、この形式が最も音がよく、かつファイルサイズが小さくなるはずである。
センサーシフトをしゃぶりつくすPENTAXは面白すぎる
カメラの手ブレ防止機能には、大きく分けてレンズを動かす方式と、イメージセンサーを動かす方式があります。後者の利点はボディ内で手ぶれ補正できるので、レンズの方に複雑な補正機構を入れなくても良いこと。レンズ交換式カメラなら、古い時代のレンズでもある程度補正が効いてしまいます。
PENTAXの一眼レフ等で使用されてるのはもちろんセンサーシフト方式。手ブレを検知してそれにあわせてセンサーを動かすことでブレを相殺します。で、まあそのためにセンサーを縦横に動かす機構を組み込んだわけですけど、「あれ？これ手ぶれ補正以外にも使えるんじゃね？」とばかりに、イメージセンサー表面に付着したホコリを、センサーの高速振動で叩き落とすというおまけ機能をつけます。ここからPENTAXの暴走が始まりました。
アストロトレーサー｜GPS UNIT O-GPS1 | RICOH IMAGING
星空を撮影する際、長時間露光しつつ星を追いかけるのは、専用機材を必要とする高度な撮影技術でした。これをGPSユニットを利用して、カメラのイメージセンサが勝手に星を追いかけることで実現するという、ちょっと頭のおかしい発想に至ります。なんだこれはｗ。
さて、デジカメにおいて、イメージセンサーの前段にローパスフィルタを置くのは常識でした。イメージセンサーの画素は縦横格子状に並んでおり、かつ殆どの場合ベイヤー配列といって、赤、青、緑といった単色のセンサーの並びからできています。これを合成して本当のカラー画像を作成するのですが、もし赤の1画素だけに当たるような細い光があったとすると、周辺の青、緑画素に光が当たらないため、赤成分だけが残ってしまいます。これを混ぜ合わせても正しい色になりません。なのでローパスフィルターで光を少しだけ拡散して、細い光でも周辺の画素にも当たるようにします。要するにせっかくピントが合った画像を少しだけぼかしているわけです。カメラというのはできるだけ解像度の高い映像を作りたいものですから、近年このローパスフィルタをなくして、そのかわり画像処理で工夫して間違った色や、モアレの発生を抑えるような工夫がなされつつあります。しかしソフトウェアによる後処理ではほんとにその画素の色が間違っているのか正確には判断できません。
できるならば、より高解像度で撮りたいときはローパスフィルタを外し、それほど解像度にこだわらないけど安全に撮りたいときはローパスフィルタを使用する、という使い分けが出来たほうが便利です。しかし、機械的にフィルタを着脱するのは構造上難しい。そこでPENTAXはセンサーシフトを利用することにします。それがローパスセレクターです。
ローパスフィルターをなくして、そのかわりイメージセンサを「露光中に」上下左右に1画素分動かして特定の位置の光が必ず周辺画素にも当たるようにしたわけです。もちろんこの機能をOFFにもできます。すげえ。
さて、上に書いたようにデジカメのイメージセンサーは通常は基本三原色それぞれを記録する画素が格子状に並んだ構造をしており、周辺の画素が得た原色情報を混ぜ合わせて色を作っています。従ってたとえば1000万画素のカメラというのが作る画像は実際は300万ピクセルのフルカラー画像を引き伸ばしたようなもので、「画素数」から想像される解像度は得られません。そこでPENTAXはまたまたセンサーシフトを使ったとんでもない工夫をやらかします。リアルレゾリューションシステムの登場です。
上のローパスセレクターと似た方法ですが、今度は一度のシャッターで、センサーを1画素分上下左右にずらしながら4回連続撮影して、4枚の画像を合成するという方法です。これによって特定位置の画素に赤、青、緑三色の情報が集まり、1000万画素が本当の1000万ピクセル画像になります。もちろんこの撮影中、わずかでもカメラ、被写体とも動いてはいけません。なので三脚にがっちり固定して、静物を撮影する状況でしか実際使い物にならないと思います。無茶しやがって。
なお、当然ですがローパスセレクタや、リアルレゾリューションを使った撮影の際、センサーシフトはこの特殊撮影のために使用されるので、手ぶれ補正は効かなくなります。本末転倒感がすごいです。
こういうことをするPENTAX、僕は大好きです。ニコンやキヤノンにくらべてどうしてもマイナーなこともあり、最新高級機以外は投げ売りになることも多く、意外と買いやすかったりするし（笑）。
昔のMacintoshの仕組み3 意外と原始的なイベントドリブンとマルチタスク化
GUIな環境では基本的に上から下への手続き、バッチ処理的なプログラムではなく、マウスクリックやウィンドウの表示、サイズ変更といった各種イベントに従って動作を記述する「イベントドリブン」というプログラミング手法が必要になる。当然初期のMacもイベントドリブンなのだが、そのイベントの扱い方が今想像されるものとは若干異なっていた。
現代的なGUI OSにおいてイベント処理はどうするのが普通だろうか。各種イベントをOS側で監視して、アプリケーションが設定した適切なイベントハンドラを呼び出すのが普通の考え方だろう。それがオブジェクト指向っぽいし。
ところが昔のMacでは、OS側がやってくれるのはイベントをキューに追加するところまでである。アプリケーション側でGetNextEvent()という関数を呼んで、キューからイベントを取り出し、それがどんなイベントであるかイベントマスクで検査し、「あ、マウスクリックだね、じゃあこれ」「ウィンドウ隠れたのね、じゃあこれ」みたいにいちいち自分で分岐処理を書かなければいけなかった。なので一般的なアプリケーションは、初期化処理のあとで無限ループを書いて、その中でGetNextEvent()を呼び、必要な処理を行うということになる。こういう形だとスムーズなタスク切り替え出来ないんじゃないかと思うでしょう。ご安心下さい。Macはもともとシングルタスクでした。Macを起動すると、デスクトップを表示し、アイコンを操作するFinderというアプリケーションが自動的に起動するけど、これは単にディスクのブートブロックに書かれているので優先的に起動するだけの、ただのアプリケーション。Finderの上でアイコンをダブルクリックすると、FInderは終了し、ダブルクリックしたアプリケーションが起動する。アプリケーションはメモリもCPUも、すべての資源を独占して動作するわけで、マルチタスク的な気を使う部分はなかったわけである。Macの前のLisaがマルチタスクだったのに、Macがいろいろ捨ててたのはなんでか。それはやはりメモリが128KBと、とても少なかったことに起因するのだと思う。
Macのメモリが512KBになった頃 Switcherというアプリケーションがリリースされる。これはFInderを作ったアンディ・ハーツフェルドという天才プログラマが作ったもので、複数のアプリケーションを同時に立ち上げて、素早く切り替えられるようにしたものだ。それまでMacの全メモリをアプリケーションに割り当てていたのを、Switcherが適切なメモリを分割して割当てるのだが、もともとマルチタスクに対応していなかったMacで極力互換性の問題が生じないようにしたためだろう。画面には同時に立ちあがっているプログラムの一つだけが表示される仕組みだった。これはシングルタスクのMacの画面そのものである。メニューバーの右端にタスク切り替えボタンが表示され、これをクリックすると、メニューバーを含む画面全体が「ズバッ！」と横にスライドして次の画面が現れるのである。なお、これは正確にはマルチタスクとはいえない。複数のアプリケーションが同時にメモリ上に読み込まれて入るが、バックグランドに行っているアプリケーションは停止状態で待機することになる。しかし、Macの多くのアプリケーションはバックグラウンドで長時間計算し続けるようなたぐいのものではなく、ユーザーがインタラクティブに操作するものであったので、十分実用的だった。
Switcherは大変安定動作したうえ、増えたメモリを有効活用できたため、Appleから商品化されることになり、それなりに普及していた。その後アンディ・ハーツフェルドはさらに考えを進めたServantというソフトを作り上げる。
Switcherの場合、「Switcherというアプリケーションの設定画面」で同時起動するアプリケーションを登録する必要があった。だが、Servantは、Finderを置き換える本格的なGUIシェルであり、かつFinderとほとんど画面も操作も一緒でいわば拡張されたFinderであった。デスクトップから普通に次々アプリケーションを立ち上げ、後ろには他のアプリケーションのウィンドウがそのまま見えていて、クリックすれば前面にきて操作ができる。今のMacやWindowsとほぼ同じである。ただし、やはり後ろに回ったアプリケーションはCPUタイムをもらえず。停止状態であった。まあ、OSそのものに時分割機能もないし、アプリケーションからタスクを他に回すAPIなんかもServantというアプリケーションでは追加しようがなかったし。しょうがない。
Servantではバックに回ったアプリケーションにイベントもいかないし、前面のウィンドウによって隠れたりした部分がどうなるか、白く抜けてしまってウィンドウ動かしたらみっともないことになるんじゃないかと思ったが、そういうことは起きず。前面ウィンドウの移動に従って隠れていた部分がきれいに復帰するのだ。おそらくアプリケーションの前後関係が変更されるタイミングでアプリケーション配下のウィンドウのビットマップを保存していたのだろうと思う。
Switcherでは各アプリケーションが使用するメモリ割り当てはSwitcherが勝手に行っていたが、Servantではユーザーがアプリケーションの情報ウィンドウで最大メモリサイズを設定することができるようになった。
他にもServantは、ファインダー上のアイコンのサイズを手軽に変更できたり、スクロールバー以外の部分をハンドツールでスクロールできるようにしたり、さらにはファイルの中に収められたリソースを覗くことができたりと、ずいぶんラジカルに機能を追加していた。ただ、このソフトはついに正式版になることはなく、β版として流通した後開発は中止される。
Servantがすっかり過去のものになった頃、ついにMacがマルチタスク化されることになった。Finderが MultiFinderになったのだ。これが出た時驚いた。Servantのラジカルすぎる部分をそぎ落として、今までのFinderにマルチタスク機能を足したものにしか見えなかったからだ。起動アプリの一覧表示、「情報を見る」からのメモリ割り当てなど、MultiFinderとServantは驚くほど似ていた。ただし、こんどはバックグラウンドアプリにもタスクが回されるようになって、ほんとに一応マルチタスクになってはいたのだけど。当時のAppleの公式見解として、「Servantとは独立して開発された」というものがあった。逆にそう言わざるをえないほど似ていたという話だ。
「一応マルチタスクになった」と書いたのはわけがある。このときのマルチタスク化は、今のMacOSやWindowsのような、プリエンプティブ・マルチタスクではなく、コオペラティブ・マルチタスクだった。プリエンプティブ・マルチタスクというのは、OSが強制的にアプリケーションのタスクを区切って次次タスクを切り替える方式だが、コオペラティブ・マルチタスクというのは、アプリケーションが「はい一旦スタジオにお返しします」とOSに制御を戻し、OSが次のアプリケーションに仕事を回すという手順が必要な方式だ。協調的マルチタスクとも言う。
さて、もともとシングルタスクだったMacのアプリケーションは、行儀よく協調的に書かれているわけではない。他のアプリケーションが同時に動くことなんかそもそも想定してすらいない。それなのにこの方式で動いたのはなぜか。
どんなMacアプリでもまず確実に、超頻繁に呼び出すAPIがある。GetNextEvent()だ。なので、GetNextEvent()を呼び出されたタイミングでOSが他のアプリに切り替えるようにしたのだ。これでスムーズにタスクスイッチングが可能になった。ただし、もともとGetNextEvent()は、「今最新のイベントを返して」っていうAPIであり、この呼び出しに時間がかかることは想定されていない。アプリケーションとしては即座に返事が帰ると思ってるAPIであまり長々よそ見をしてもらっては困る。なのでOSもこのAPIで呼ばれたときには、タスク切り替え一周したらできるだけ速やかに戻ってくるようにしていた。
ただ、イベント取得は実際には必ずしもすぐに来なくてもいいものだ。「キー入力が来るまで待ちたい」ときに「まだ？まだキー来ない？」となんども呼び出すのは効率が悪い。自分だけがMacを専有していたときはそれでもよかったのだが、複数のアプリが強調するなら、ここは効率を重視したい。
というわけで、MultiFInder導入と同時に、GetNextEvent()の上位版API。WaitNextEvent()が登場する。これはGetNextEvent()とほぼ同じだが、待ち時間の引数が追加されて指定した時間の間待つから帰ってこなくていいよ。というものだ。つまりあるアプリケーションが「100msの間もどってこなくていいよ」といえば他のタスクにその分CPUを割り当てることが可能になる。
なお、これもやはり待ち時間をどうするかなどめんどくさいところが多かったし、プリエンプティブ・マルチタスクのMacOSXが導入されるとプリエンプティブなタスク切り替えとコオペラティブなそれが競合してしまってはなおさら無意味になる、結局昔のMacの互換APIであるCarbonは、Carbon Event Modelという、イベントハンドラをOSが適切に呼び出す形式のAPIを追加することになった。まあ、そんなすったもんだのあげくに互換性を保ちながらモダンになりかけてたCarbonもあっさり64bit非対応で廃止されちゃったんですけどね。
