週刊 Life is Beautiful ２０２１年５月１１日号

今週のざっくばらん Practical Solution 先日、Twitter を見ていたら、とても懐かしい話が出てきたので、今日はこれに関して少し解説します。 OLE（Object Linking and Embedding）は、Microsoft のアプリケーショングループが開発した、オブジェクト指向のテクノロジーです。主たる目的は、Excel から Word のドキュメントに Copy & Paste した表やグラフが、単なる文字や画像ではなく、「Excel の一部」であるという属性を保持したインテリジェントなオブジェクトであり、Word ドキュメント上で Excel の機能を使ってデータを変更することが可能という、当時（１９９年台前半）としては、画期的なテクノロジーでした。 OLEが特に画期的だったのは、メモリ上の全てのオブジェクトにIUnknownというインターフェイスを持たせ、これを使って、オブジェクトがどんなインターフェイスをサポートするのかをランタイムに調べることが出来るという、COM （Component Object Model）のコンセプトにあります。 Windows 3.1 までは、OLE は、Microsoft Office アプリケーションの一部であり、オペレーティング・システムの一部ではありませんでした。 私はオペレーティング・システム側のエンジニアとして OLE の存在は知っていましたが、その中に COM という素晴らしいテクノロジーがあることを認識したは、Windows 95 を開発していた Chicago チームに移籍してからのことです。当時、OLE チームのアーキテクトだった Tony Willias のオフィスまで直接行き、説明を丁寧に受けて感動したことを、今でも良く覚えています。 私は当時、Windows の Explorer にエクステンションという機能を導入し、サードパーティがさまざまな機能を Windows Explorer に加えられる仕組みを作る必要に迫られていました。Exchange サーバーのクライアントである Capone、MSN オンラインサービスのビューアーである Marvel などが対象です。 エクステンションを実装するには、サードパーティのコードを Windows Explorer の一部として実行する必要があり、そこで私が目を付けたのが OLE の COM だったのです。 しかし、実際に OLE の COM を使ってサードパーティのコードを読み込もうとすると、遅くて使い物になりませんでした。一番の原因は、そのモジュールの大きさにあり、OLE の一部でも使おうとすると、大量のコードがメモリに展開されることになり、それが当時対象としていたマシンの性能を大幅に上回っていたのです。 Windows 95 の重要なミッションの一つは、「市場に数多く出回っているパソコンでそのまま動くこと」であり、そのミッションがあるかぎり、OLE は使えないことが判明しました。 しかし、エクステンションを実装するには、COM 相当の機能が絶対に必要でした。COM のエレガントさに惚れ込んでしまった私に COM 以外のアーキテクチャを選択することは、もはや不可能でしたが、OLEは大きすぎて使えない、というジレンマに陥ってしまったのです。 そこで、私が作ったのは「light-weight COM」というモジュールです。OLEの中で、私が必要としているCOMの、それもごく一部の機能（サードパーティのDLLを必要に応じてメモリー空間に読み込む機能）だけを、OLEの仕様書を見ながら再実装したのです。それも、C++を使わず、全てCでです。１バイトでも小さく・高速に実装するため、Cで直接C++のバーチャルインターフェイスを参照するという荒技に出たのです。 結果として Capone、Marvel などが Windows Explorer 内で順調に動くようになりましたが、私が COM を再実装したことに懸念を表明する人たちが出てきました。二つの実装を持つことは、将来、互換性の問題が生じる可能性があるからです。 そこで、実装を少し変更し、最初は light-weight COMを使いながら、OLE がメモリー内に読み込まれた後は、OLEのCOMを使う様に切り替えるようにしました。こうしておけば、メモリーを十分に搭載したパソコンでOLEのフルの機能を使う場合には、私のコードは実行されないので、互換性の問題は生じません。 アーキテクチャとしては、美しくもエレガントでもありませんが、与えられた条件の中で問題を解決するという意味では、とても実用的な解決方法（Practical Solution）だったと思います。 Windows 95 は、「既存のパソコンで動かなければならない」「Windows 3.1 向けに作られた１６ビットのアプリケーションやドライバーはそのまま動かなければならない」などの厳しい制限の元で、「３２ビットのアプリケーション」「新しいユーザーインターフェイス」「プラグ＆プレイ」という３つのイノベーションを起こす必要があったため、システムの各所で、さまざまな問題解決をする必要がありました。 そのため、「次世代OSをエレガントなアーキテクチャで作る」などの格好の良い仕事が好きな人には全く向いていませんでしたが、私の様に「とにかく Practical Solution を素早く見つけ出す」ことに喜びを感じるエンジニアには、最高の職場でした。 ちなみに、後から知ったのですが、Chicago グループと並行して「次世代OS」を開発していた Cairo グループのところには、「OLE を採用するように」というリクエストが Bill Gates から直接来ていたそうでです。 Cairoチームも私と同じように「OLE はメモリを食いすぎる」とは認識していたようですが、彼らが対象としていたのは、より多くのメモリを搭載した次世代のパソコンだっので、それで良しとしていたそうです。 そんなこともあり、後に Chicago と Cairo の対立が歴然となり、Cairo 側から Windiws 95 の技術的な問題点を指摘する際に、「Windows 95 が OLE を使っていない」を主要な論点にしようとした Cairoの技術者が、「light-weight COM」の存在を知って、完全に「肩透かし」を食うハメになったそうです。 ちなみに、当時、「次世代OS」として莫大な人員とお金を投資して開発された、Microsoft の Cairo、IBM の OS/2、Apple のCoplandとTaligentがことごとく失敗に終わる中、Cairo がリリースするまでの「中継ぎ」でしかなかったはずの Windows 95 が市場で成功し（そして、そのコードベースが Windows 10 にまで使われ続けており）、Apple を追い出された Steve Jobs が作った NeXTSTEP が今や iOS や macOS のベースになっているというのは、なんとも痛快な話です。 ９０年台のMicrosoftは、外から見ると磐石に見えたと思いますが、内部抗争も社内政治も結構あったし、莫大な開発費が何も生み出さないことも多々ありました。そんな中でも、会社のビジョンとミッションに惚れ込んだエンジニアたちが一生懸命に働き作ったものが世の中に出て、そのごく一部が世の中で大成功を納める、という厳しいながらもエキサイティングなのが、この業界の特徴なのです。 Bill Gatesの離婚 先週、Twitter に Bill Gates 自身による離婚の発表がありました。