| OLEみんなで渡れば怖くない(前編) |
マイクロソフトが2月に発売したMicrosoft Visual C++ Version 2.0が飛ぶように売れている。秋葉原のThe Computer館では平台に山積みされているし、セミナー業者のカタログにも｢VC++ 2.0概論｣、｢Visual C++ 2.0とMFC3.0｣、｢VC++ 2.0プログラミング詳細｣などのコースがあふれている。マイクロソフト社の言語担当者など、講師に引っ張りだこで、仕事をする時間があるのかしらと心配になるほどである。
Windowsの普及促進団体であるWindowsコンソーシアムでも、VC++ 2.0の出荷日に合わせた技術セミナーを開催したが、通常の倍の220名が参加するほどの盛況であった。
なぜ、Visual C++ 2.0が日本でこのように大きな反響を呼ぶのであろうか。それにはいくつかの理由が考えられる。
まず第一は｢日本人の言語好き｣である。
日本のパソコンユーザーには｢コンピュータを操作するにはプログラミング言語が必要である｣という妙な固定観念を持った人が多い。これはPC-8001やPC-9801(無印)、日立ベーシックマスターなどの初期のパソコンがROM BASICを搭載し、ユーザーズ･マニュアルにPRINT、MID$、CLOADなどのBASIC言語があふれていた事に起因する。当時の｢アスキー｣や｢マイコン｣にはBASIC言語のサンプルソースが氾濫し、記事の半分近くがBASICのソースだった英語版｢Dr. Dobb's Journal｣を持っていることがステータスシンボルになっていた。10数年前からの｢パソコン=言語｣という考えが綿々と続いているのである。
遠い昔のDisk BASICブーム、Turbo Cブーム、Microsoft C 3.0ブームと同じように、今、また言語ブームが再現している。1986年に出荷されたMicrosoft C 3.0のときは、Lattice社から買い取った、最初のマイクロソフト印Cコンパイラだったので、爆発的にヒットした。販売元のアスキーでは、パソコン用のC言語など売れないだろうと、20万円近い価格で売り出したのだが、うれしい誤算で言語の営業マンはホクホク顔だったのを覚えている。今回は、CD-ROMで定価48,000円という良心的なプライスである。
第二には｢VC++ 1.5の日本でのパス｣がある。
VC++ 2.0が出るまで、日本ではVC++ 1.0しか発売されていなかった。何と、日本ではOLE2に対応したクラスライブラリであるMFC 2.5が入った開発ツールが、今まで存在しなかったのである。
VC++ 1.5やVisual Basic 3.0のように、非常に重要な位置付けの開発ツールが日本では移植体制が整わないなどの理由でパスされる傾向にある。開発ツールとOSは密接な関係にあるので、VC++ 1.5のようなひどい矛盾が生じることになる。｢マイクロソフトはOLE2を強力に推進しています。今後のアプリケーションはすべてOLE2対応としてください。しかし、開発ツールはありません｣という矛盾である。OSには90日ルールというものがあって、米国で出荷されたOSは90日後には日本語版が出されているが、開発ツールにも同じルールをつくってもらいたい。米国での、開発ツール、OS、データベースなどのBack Office製品群、Word、ExcelなどのOffice製品群の間の綿密に計算されたスケージュールをそのまま90日後に、すべて日本語で出して欲しい。
今、Windows開発者は、｢待ってましたOLE2｣とばかりに、VC++ 2.0を買い求めている。
第三に、｢Windows NT 3.5のプログラム開発｣という視点がある。
昨年12月に出荷されたWindows NT Workstation 3.5とWindows NT Server 3.5は大きな成功を収めつつある。Windowsコンソーシアムの副会長がWindows World誌のWindows Heart Beatというコラムで｢NTは大成功です｣といっても信じていただけないかもしれないが、日本の大企業がこぞってNTの採用を決めている。
Windows 3.1ではなくNT WorkstationをクライアントOSといて採用するということは、スレッドや高信頼性への期待からであるが、Windows 3.1に比べてNTは開発ツールが少ない。Visual Basic 4.0のうわさはあったが、US版も含めて先送りされてしまった。今回のVC++ 2.0はNT開発の切り札として、皆が期待しているのである。
また、大規模システム開発の標準ツール体系であるWOSAの拡張を、すべてOLE2のカスタムコントロールであるOCXで作る動きがあり、このためのツールキットCDKもパッケージに含まれている。CDKを使って、OLE2サーバーライブラリのようなサブシステム群を作り、各種アプリケーションから呼び出すのである。
第四に、｢Windows 95への備え｣が挙げられる。
Windows 3.1の次バージョンである、Windows 95は、OLE2がOSの前面に出てくる。Windows 95のロゴライセンスでも、OLE2対応は重要な要件である。
Windows 95"ロゴ"対応のアプリケーションを作る場合、OLE2が必須となる。OLE2のプログラミングには、MFC 2.5や3.0が必要である。そして、MFCを使うには、Visula C++やSymantec C++、Borland C++などのC++言語をマスターしなければならない。
VC++ 2.0には、Windows 3.1つまりWin16アプリケーションの開発用にVC++ 1.5も同梱されているので、Windows 3.1ベースでの開発も可能となっている。因みに、VC++ 2.0は32ビットのOSである、Windows NTおよびWindows 95でしか稼動しない。
4つの要因中の3つまでがOLE2である。
OLEっていったい何だろう。アプリケーション間のデータの渡し方かな?
MS-DOSでのファイルを介したデータ交換が、Windowsの登場でクリップボード経由のカット&ペーストに替わり、DDEというプログラム間でのデータのやり取りが可能になった。確かにその先にOLEがあるのだが、データ交換用にしては仕組みが大きすぎる。データ交換ではなくオブジェクト交換ですといっても抽象的でわからない。OLE2はファイルシステムも持ち、OSに近いサービスを提供している。
面倒な、わけのわからない仕組みを、マイクロソフトは強力に推進している。開発者は疑心暗鬼でマイクロソフトに付き合っている。マイクロソフトにしても、Cairoでの輝かしいOLEの未来を予測できているわけではなさそうである。
先日、新宿西口、文化服装学園の前の横断舗道を歩いていて、こんな言葉が頭をよぎった。｢OLEみんなで渡れば怖くない｣
｢すべての道はカイロに通じているのである｣
#19「OLEみんなで渡れば怖くない(後編)」