2009年01月03日
川俣晶の縁側ソフトウェア技術雑記 total 9060 count

複数プログラム言語間相互呼び出しはCOMや.NET Frameworkの新機能ではなくマイクロソフトの根深い伝統であるか!?

Written By: 川俣 晶連絡先

 荒井省三さんの著書"The Root of .NET Framework"を数日前に読み終わりました。内容は大変に面白く、ワクワクしました。概念的な説明を主体としたオフィシャルの解説書は過去にも読んでいますが、本書は16進数のアドレスと各種構造のダンプの塊であり、遙かに具体的です。しかも、内容を確認するために追試を行う方法も示されていて、極めて科学的かつ合理的です。

 とはいえ、本質的ではない部分で1つだけ引っかかったので、本筋と関係ない話題を1つ書くことにしました。

 ただし、うろ覚えの記憶でいい加減に書き飛ばすので、内容を信じてはいけません。

マイクロソフトはじめて物語 §

 上記書籍では以下のような歴史像描かれているように思いました。

  • Windows 3.1のWin16 APIはC言語を前提とした「単一プログラム言語API」である
  • COMの導入は、マイクロソフトとして「初めて」APIに「言語非依存性」を導入した
  • .NET Frameworkが特定プログラム言語に依存しないのはCOMの発展形だからである

 つまり、以下のように要約できます。

  • マイクロソフトの技術体系は単一言語依存から言語非依存へというベクトルで進化を続けた

 しかし、この歴史像には微妙に違和感を感じます。

 というのは、マイクロソフトは伝統的に「単一言語依存」ではなく、単一言語依存性が発生するのは実はWindows 3.1前後以降の特殊状況ではないか、という気もするからです。

MS-DOS時代のmixed language programming §

 MS-DOS時代のMS言語製品はmixed language programmingをサポートしていました。たとえば、C, FORTRAN, Pascal, アセンブラ(MASM)で書かれたモジュールをリンクして1本の実行ファイルに仕立てることができたわけです。だから、MS-Cには実際にpascalやfortranというキーワードがあり、それぞれPascalやFORTRANで書かれたコードに対して「呼び出す/呼び出される」ために使用される仕様でした。そして、リンカは言語に関わらず1つのリンカを使います。

 実は、Win16 APIで使用されるPascal呼び出しとは「Pascal風の呼び出し規約」ではなく、実際にはMicrosoft Pascalの呼び出し規約であり、Win16 APIのヘッダーに多数記述されたpascalキーワードとは、本来Microsoft Pascalで書かれたコードに対して「呼び出す/呼び出される」機能をMS-Cで実現するためのキーワードであったわけです。

Cは単一の選択肢ではなかった §

 更に言えば、Windows誕生前後の状況を見ると、C言語は必ずしも「唯一選択される単一の開発言語」ではなかったことが分かります。

 パソコンの開発言語はBASICとアセンブラが初期の主流となりますが、それらの後継言語として最初に注目されたのはPascalです。たとえば8bit時代からPascal/MT+やUCSD Pascalといった名前が取りざたされています。その後、徐々にC言語というものもある……という認識が浮上してきますが、それでもしばらくの間はPascalの存在感が大きかったのは事実です。たとえば、ボーランドが最初に手がけた言語はTurbo Pascalです。ボーランドがTurbo Cをリリースするのは、Turbo Pascalに対する大きな利用者からの支持でブランドを確立した後のことになります。また、Macintoshの最初の純正開発言語はMPW Pascalです。Cは後から追加された開発言語に過ぎません。

 このような背景と16bit Windows APIの定義に散りばめられたpascalキーワード(実際にはマクロ定義されていて大文字のPASCALだったりするが)を見ると、結果としてCだけがサポートされる形になったとはいえ、PascalによるWindowsプログラミングの可能性、というよりも初期においてはPascalこそが主力開発言語として検討されたこともあるのではないか、という気もします。

 (ちなみに、APIのpascal問題にはパフォーマンスの問題もあります。C呼び出しよりもPascal呼び出すの方が効率が良いので、限界までチューニングを要したWindowsがそれを採用したという可能性もあり得ます。しかしそう考えても、APIにPascal呼び出しを使っても、プログラム内部の呼び出しには使う慣習がないというミスマッチが見られます)

 (もう1つ余談を入れると、Win16 APIでも引数が不定個数のwvsprintfのようなAPIはC呼び出しを使っています。しかし、引数不定のAPIは不確かな記憶によるとWindows 3.0前後に追加されたもので、初期には存在しなかったように思います)

墓穴はどこで掘られたのか §

 私の持論は「パソコン業界において敗者は勝者に滅ぼされたのではなく自滅によって敗者になる」ですが、私の個人的な感想としては、マイクロソフトは2つの自滅行為によってプログラム言語処理系の世界で存在感を後退させたと感じます。

 その2つとは以下です。

  • MS-C 7.0で導入したたMFCと3.0までのVisual Basicの間でオブジェクトの相互運用性が無かった
  • この問題はCOMによって解消されるはずだったが、バージョニングという致命的な欠陥があった

 つまり「Javaの流行」とはJavaの勝利を意味するのではなく、上記の2つのマイクロソフトの自滅行為によってもたらされたものであり、未だにJavaが勝利者として圧倒的なシェアを取れない理由もJava陣営が様々な自滅行為を行っているから、と解釈されます。

 ここで1つめの問題が、本来マイクロソフトの技術体系に無かった単一言語依存という状況を導入してしまい、2つめの状況が単一言語依存を解消する技術体系への移行を阻んでしまったように思います。

 .NET Frameworkとは、この2つの問題を完全に解消する技術であり「墓穴は全て埋まった」と思います。

 しかし、それは私から見ればmixed language programmingが当たり前だった時代の水準に復帰したような状況であって、けして初めて獲得した栄光ではないと思います。

 とはいえ、mixed language programmingと、言語非依存のインターフェースやライブラリは「同じ」ではなく、後者の方がより理想的であることは言うまでもありません。その理想に接近するために、一時的に混迷の世界に迷う必要があったとすれば、上記の2つの問題も無価値ではなかったのでしょう、たぶん。そして、その理想に向かうベクトルは、マイクロソフトという企業の内部文化に存在し続けたのだろう、とも思います。

 (ポール・アレンとビル・ゲイツはもともとミニコン文化の住人であって、ミニコンの世界でBASICは必ずしも主流の開発言語ではありません。BASIC=単一言語以外の言語が常に意識される文化が発生するのは当然の成り行きでしょう)

余談・COMは悪くない §

 "The Root of"に書かれたCOMは悪くない、という主張は私もそう思います。悪かったのはCOMではなく、COMの使い方であり、COM開発を支援するツールであり、COMの上に構築された技術体系だったと思います。実際、最初にCOMに関する解説を読んだときは、本気でこれは使えると思いました。COMから手を引いたのは、COMの理想が全く実現化されていなかったからに過ぎません。

 そのように考えれば、.NET Frameworkが本来あるべきCOMの理想の継承者であるという"The Root of"の世界観を拒否する理由は何もありません。