- さらに広がるVisualBasicの世界 -
酒井 法雄
今、VisualC++と並びWindows用のもっともスタンダードな開発環境として認知されているVisualBasic。エントリーのしやすさ、効率の良さから言えば、VisualC++をはるかにしのぐものがある。今後もVisualBasicはWindowsでの開発環境の中心として位置づけられていくのだろうか? 今、VisualBasicの歴史を振り返り、今後のMicrosoftのWindows戦略を分析し、VisualBasicの将来性を考えてみる。
今を去ること30年前、1964年 米国ダートマス大学の John G. KemenyとThomas E. Kurtz は、BASIC言語を設計した。BASIC というと、『基本』という日本語訳が出てきそうだが、本来は Beginner's All-Purpse Symbolic Instruction Code の略である。つまりは、初心者向きの汎用言語というコトだ。もちろん、『基本』という概念が彼らの頭にあったことを想像することは難しくはない。
このときの、元祖BASICは、汎用機の TSSシステム用として設計されたものである。今と違って個人がコンピュータを持つなどというコトは夢の夢だった時代だ。コンピュータと言えば、汎用機に繋がった端末を選ばれた一部の人間だけが使うモノといった時代である。しかし、プログラミング言語とはそういう人間にとっても難しいものであった。
そんな一握りのプログラマーだけではなく、学生たちにも使えるコンピュータ言語として、彼らはBASICを設計したのだ。したがって、従来の言語とは大きくことなるコンセプトがあった。例えば、初心者が試行錯誤しながらマスターできる対話言語を目指したため、厳密な型チェックや厳格な構文を排除した。このような目的を達成するため、彼らは次の8つの原則を掲げてBASICを設計した。
1974年 MITS(Micro Instrumentation and Telemetry System)社の発売した Altairは、パーソナルコンピュータの元祖となる小型コンピュータであった。このマシンには、メインメモリがわずか256Bytes しかなかった。
Altairが発売された翌年、William H. Gates と Paul G. Alen の手によって開発された BASIC が搭載される。これが大当たりし、BASICがパーソナルユースに使われはじめるきっかけとなった。この二人こそが、今日のMicrosoft社を作り上げた張本人たちである。そして、Microsoft社を作るきっかけとなったのは、外の何物でもない BASICだったのだ。
しかし、このBASICは、当初のBASICとは大きく異なっていた。ハードウェアのメモリ制限が厳しかったことから、マルチステートメントやコマンドの短縮、インタープリタといった一般にBASICの欠点と言われるものが、この時点で採用されることになったのだ。
とはいえ、少ないメモリ、非力なCPUパワーのマシンで、人間の言語に近い高級言語が使えるというのは大きなメリットだった。このため、その後発売されたマイクロコンピュータには標準言語としてGatesたちの BASIC が搭載されていく。我が国でも、N-BASIC、N88-BASIC などをはじめとしてMicrosoft の BASICが搭載された。
この頃、『マイクロコンピュータを使うということ』=『BASICを使うこと』にほかならなかった。というのも、オペレーテイングシステムというものが存在していなかったからだ。当時は、マイコンには
BASICの ROMが搭載されていて、ファイルの管理などはBASICで行われたのだ。BASICを避けてマイコンを操作することなどできなかったのである。世の中には、BASICを教える教室ができたりしたものだ。
したがって、あらゆるアプリケーションは BASICで記述されていた。一部、高速な処理が必要な部分だけをアセンブラで記述するといったハイブリッドな使い方が一般的であった。
しかし、そんな時代も次第に移り変わっていった。それは、CPUが8bitのZ80から 16bitの8088や8086に移行し、マイクロコンピュータはパーソナルコンピュータと名を変えた頃だった。オペレーティングシステムの登場である。もちろん、8bitの時代からCP/Mというオペレーティングシステムはあった。しかし、我が国ではさして普及しないうちに時代は16bitになったのである。そして、16bit CPUのOSとして主流となったのは、CP/M 86 ではなくMS-DOSであった。MS-DOSはMicrosoft社の製品である。これには、面白い裏話がたくさんあるが、それらについてはすでにたくさんの本が出ているから、そちらを参照されたい。ここで一つだけ覚えておいていただきたいのは、マイコン、そしてパソコンのもっとも基本となるソフトウェアは
BASICから MS-DOSに変化したが、その供給元はMicrosoft社であったという事実である。
MS-DOSの普及にともなって、BASICは急激にすれていった。少なくとも、我が国ではそう見えていた。これにはいくつかの原因がある。
まず、一つはC言語が流行したコトだ。Cはunixを記述するために開発された言語である。高級言語というよりは、高級アセンブラといった方が近いモノだ。しかし、構造化制御構文をサポートした言語仕様、細かい部分で比較的融通が効くところがプログラマー好みであったこと、ポータビリティーに優れていること、実行コードがコンパクトで高速であったことなどから、『コレはプロ好みのよい言語だ。今までのBASICなんて話にならん』という評判になった。そのため、我が国では一大Cブームとなったのである。しかし、現実問題として、マトモに使える人間は10%もいないのではないかというくらい、みんなCはできなかった。いや、C本来の美しさや利点を活かすプログラミングができなかったのだ。
もう一つの原因は、MS-DOSに BASICがバンドルされなかったことだ。米国では、GW BASICと呼ばれるBASICがMS-DOSにはバンドルされており、タダで使える言語として根強い人気を持っていた。しかし、我が国では BASICは別売の製品であり、その価格も異常に高価であった。
このようなことから、我が国ではCの人気上昇に反比例してBASICの人気は落ちていった。そして、プログラミングなんて全然できないヒトからも『いまどきBASICじゃねえ』といった言葉が聞かれるようになっていたのだ。
しかし、米国では大きく事情が異なっていた。BASICがバンドルされていたことに加えて、アメリカ人のプラグマティズムはカッコ良さだけでCを選んだりはしなかった。もっとも需要があり、もっとも作られている受託開発の業務プログラムでは、Cでゴリゴリ書くよりも、BASICを使った方がカンタンだ。もちろん、文字列の操作も楽だ。さらにBASIC用のISAMライブラリや画面作成ライブラリも充実してきた。速さは、BASIC Compilerとマシンの高速化が解決してくれる。BASICに何の不満があるだろうか。プログラムは動いたモノ勝ちだ。こうして、米国では『BASICはプロの使うモノ』という常識ができていった。
需要があれば、供給がある。そして、今までよりも使いやすいBASICという要求が出てくる。メーカーはそれに応えるべく新製品を作る。こうして、Microsoft社はバンドルしている BASICを改良するとともに、さらにプロフェッショナル向きの BASICを作っていった。Microsoft BASICである。そして、統合開発環境を売りにした初心者向きの製品として、Quick BASICを発売した。これは、PC/AT用だけではなく、Macintosh用もあった。
しかし、我が国ではすでにBASICを使っているなどというと技術力を疑われるというのが常識となっていた。
しかし、1988年12月、我が国でもQuickBASIC 4.2が発売された。プロフェッショナル用というのは受け入れられないだろうという配慮からか、初心者向けのQuickシリーズのみの発売であった。4.2というバージョンは、英語版4.0を元にしていた日本語版という意味だった。このバージョン番号からも、MicrosoftがBASICにずっと力を入れ続けていたことが分かる。この製品は結構バグが多く動作が不安定であったものの、構造化制御構文やプロシージャ、ローカル変数も装備しており、エディタ、コンパイラ、デバッガを装備した統合開発環境での開発が可能であり、スタンドアローンのEXEファイルが作成できるというメリットもあった。また、MS-DOSのファンクションリクエストをコールする機能やライブラリ作成機能などもあり、C言語を凌駕するパワーを持っていた。そのため、C言語を始めたものの、イマイチ分からないといったホビーユーザーはQuickBASICに飛びつくことになった。
一年後の1989年 11月、QuickBASIC は4.5にバージョンアップした。これに伴い、製品は安定しBASICは過去のモノではないということにプロフェッショナルユーザーも気づき始めた。翌年、Microsoftはプロフェッショナル向けのMicrosoft BASIC 7.1を発売した。これには画面作成やISAMライブラリ、PWBなども装備されていた。また、QBXと呼ばれる QuickBASIC 4.5の上位コンパチの開発環境も用意されており、これぞ究極のQuickBASICだと言われた。
もちろん、この間もMS-DOSにバンドルされているBASICも進化しており、QuickBASICのサブセットである QBASICがバンドルされるようになった。
『どうやらMicrosoftはBASICに本気らしい』誰もがそう気づき始めた。そもそも、Microsoftという会社はBASICがなければできなかった会社である。今でこそ世界一の金持ちとなったBill Gatesには、BASICは特別の思い入れがあるであろうことは想像に難くない。なにせ、Microsoft社内でプロジェクトが予定通りに進行しないときには、『そんなときには、Billに頼めばいいさ。彼なら一晩でみんな書き上げてしまうよ。BASICで...』という冗談が囁かれるというほどだ。
OSはMS-DOSからGUIに移行しつつあった。OS/2になるか、はたまたWindowsになるかといった時代に、『Bill GatesはBASICをGUIに搭載する気らしい。それもオブジェクト指向の言語にして』という噂が流れてきた。主流となる言語も、CからC++へと誰もが考え始めていた時代だ。QuickBASICでCに追いついたBASICは、次の世代のBASICでC++にも追いつくことになるというのは、Microsoftの、いやBill Gatesの歴史を見れば、さもありそうな話だった。
そして、MicrosoftはWindows 3.0を大々的に発売した。しかし、Microsoftが『これからはWindowsだ』と声を大にしたところで、Windowsでのプログラミング開発はたやすいものではなかった。膨大なAPIやメッセージ、イベントドリブンの考え方、リソースの作成、リソースとコードの関係づけ、それらのすべてが手間のかかることばかりであった。特に、MacintoshやWindowsがそれまで普及していなかった我が国では、Windowsでの開発など、どうしたらよいか分からないというのが現状であった。今までのC言語以上にスキルの高いプログラマーにしかできない環境だったのである。
我が国では、Windows 3.0は発売されたものの、その上で動くアプリケーションがさっぱりないという状態が続いた。ActorやToolBookなどといったカンタンなプログラミング環境はあったが、現実的にアプリケーション開発に使えるモノではなかったのだ。
そんな1991年6月、Microsoftはついに VisualBasic 1.0 を発売した。そして、直後にIBMとの長い蜜月関係を解消した。発売直前までは、WindowsおよびOS/2用とされていたVisualBasicは、Windows専用となった。VisualBasic 1.0は、コードとデータをひとまとまりのオブジェクトとして捉える点、フォームやコントロールごとにプロパティやメンバ関数(メソッド)を装備している点、Windows APIやメッセージを完ぺきに隠蔽し、あらかじめ用意されているイベントにBASICのコードを記述していけばよいという点、ウィンドウデザインの容易さとったオブジェクト指向のもっとも基本的な部分を押さえた製品であった。もっとも、真の意味でオブジェクト指向というには、クラスの継承やオーバーライドなどのメカニズムが現実的にはないという問題があった。しかし、カスタムコントロール(VBX)の採用で、オブジェクトの再利用という道は残してある。この点は、VisualBasic 3.0までも変わっていない。
VisualBasic 1.0は日本語版こそ発売されなかったものの、その生産性の高さに注目した日本人は数多かった。英語版を元にした連載記事や、当時我が国で主流だったPC-9801で使うための書籍などが発売され、一挙に注目されるようになった。さらに、Professional Tool Kitと呼ばれるカスタムコントロール集 + カスタムコントロール開発キット(CDK)の発売で、VisualBasicの世界は広がってきた。
1992年 10月、VisualBasic 2.0 Standard Editionが発売された。操作性の向上や言語仕様の見直し、高速化などがなされ、さらにOLEにも対応したVisualBasicは、実用的なアプリケーションを作るに十分な資質を持っていることをアピールした。カスタムコントロールやCDK、データベースとの接続インターフェイスのODBCなどの機能を装備した Professional Edition も同時に発売された。
翌1993年 2月には、異例の速さでVisualBasic 2.0日本語版が発売された。通常、英語版から日本語版発売までのタイムラグは半年から一年もあるのが普通だったのだが、VisualBasicは違っていた。それだけ、日本語版への要望があったと見るべきだろう。しかし、残念ながら日本語版は Standard Editon のみの発売となった。これは、ODBCなどの日本でのサポートが当時は未定だったことによるものと思われる。
ところが、4月には米国では早くもVisualBasic 3.0が発売されることとなった。わずか半年という、これまた異例の速さのバージョンアップである。見かけはほとんど変わっていないVisualBasic 3.0ではあるが、実際には非常に重要な変更がなされている。主な変更点は、バグフィックス、ODBC仕様の見直し、Accessコンパチのデータベースサポート、セットアッププログラムをカンタンに作るSetUp Wizardの搭載、データベースの帳票出力をビジュアルに設定できる Crystal Reports のバンドル、そして OLE2に対応した機能の搭載などである。
6月には、日本語版 Visual Control Packが発売された。これは、英語版であれば
Standard Edition から Professional Edition への機能アップキットとも言えるものなのだが、日本語版ではカスタムコントロール集のみであった。
翌 1994年1月になって、やっとMSKKは2.0日本語版のProfessional Editonを発売する。これは前年末に
Access 1.1日本語版が発売されたため、ODBCなどの日本側でのサポート体制ができてきたからだろう。
しかし、MSKKは公式にVisualBasic 3.0を日本で発売しないことを明言している。これには非常に大きな問題を含んでいる。それについては後ほど述べることにしよう。これは、1995年1月現在も変わっていない。次に日本語版が発売されるのは、VisualBasic 4.0になるということらしい。では、その発売時期はいつになるのか? 残念ながらMicrosoftは正式に発表をしていない。しかし、Windows 95 の発売直後になるのではないかという観測がもっぱらである。では、Windows 95日本語版はいつ出るのか? どうも95年ギリギリではないかという噂がもっぱらである。すると、96年第一四半期に発売と見るのが正解となりそうだ。
さて、ここで改めてVisualBasicのメリットを考えてみよう。すでに述べたように、Windowsのネイティブなプログラミングは非常に面倒なものである。その面倒な部分を隠蔽して、表面上はBASICの文法やステートメント、関数などが使えるようになっている。しかも、メッセージに対応するコードは、あらかじめ用意されているイベントプロシージャに記述すればよい。ここがもっとも重要なところである。
これを、一般的なWindowsのプログラミングの比較してみよう。次の図は、Windows での一般的なメッセージの流れである。ハードウェアからの入力は、Windowsが管理しているシステムキューに投げ込まれる。Windowsは入力があった位置や入力の種類などによって、その入力を対応するアプリケーションキューに対応するメッセージを放り込む。各アプリケーションは、自分のアプリケーションキューを監視するループを持っており、何らかのメッセージがWindowsから送られてきたときには、ウィンドウプロシージャを起動したり、対応する処理をしていく。このとき、コントロールの操作などをするときには、そのコントロールに対してアプリケーションからメッセージを発行する。Windowsではコントロールも一つのウィンドウなのだ。
※Windows SDKプログラミングガイド
P.11の図
しかし、すべての機能をメッセージだけで実現していては、膨大な労力が必要になってしまう。WindowsにはDOSのファンクションリクエストのように基本的なウィンドウの入出力などをつかさどる関数が用意されている。これが、Windows API(Application Programming Interface)と呼ばれる関数群である。これらの関数群は、用途に応じて
KRNEL386.EXE, GDI.EXE, USER.EXEの各モジュールに分けて用意されている。EXEという拡張子であるが、これらは実際には
DLL(Dynamic Link Library)である。
つまり、Windowsでの動作はメッセージを基本とした構造を取りながら、必要に応じてWindows APIをコールしていくというものなのだ。
ところが、このメッセージやWindows APIは膨大な数があり、やれ DDEMLだ、マルチメディアだ、OLEだ、コモンダイアログだ、Win32だ Win32Sだといった具合に増え続けている。また、これらのAPIは比較的低レベルなものであるから、使い方が難しいものが少なくない。これらの内容を完璧に理解して使いこなすのは、イタチごっこであり、すでに不可能になってきている。現に、基本的なWindows APIだけが記載されているオンラインヘルプのサイズは7Mbytes以上もあるのだ。
その後発売されたVisualC++では、MFC(Microsoft Foundation Class Libray) と呼ばれるC++のクラスライブラリが用意されており、APIをうまく隠蔽して使いやすくしている。また、メッセージもメッセージマップを作ってそれに対応したプロシージャの外枠を作ってくれ、リソースの概略まで作ってくれる App Wizardという機能が内蔵されている。このおかげで、C++と言えどもCよりはずっとカンタンにプログラミングできるようになっているのだ。
VisualBasicではこれらのメッセージやAPIは完全に隠蔽されているため、それらについての知識がまったくなくてもアプリケーションを作成することができる。これが何といっても最大のメリットだ。しかし、それがそのまま落とし穴になっていることも否定できない。
VisualBasicは、前述したVisualC++に比較すると言語仕様上はクラスの作成、継承、オーバーライドなどができないため、オブジェクトの再利用には難がある。これを解決するために、VisualBasicでは Cで作成したカスタムコントロールを再利用できることはできるようになっている。
また、あらかじめ用意されていない特定のメッセージに対応するイベントを知ることはできない。これもウィンドウをサブクラス化するVBXの使用で解決することが可能だ。
VBXとは拡張子が『.VBX』になっていることに由来するのだが、実際にはVBXはDLLである。内部的には、図のようにWindowsからきたメッセージはVisualBasicが受け取り、VBXにはWindowsのメッセージがそのまま行くこともあるし、VisualBasicの仕様に合わせた VBMメッセージとして送られることもある。VBX内のコントロールプロシージャではこれに対応した処理をして、VisualBasicのデフォルトコントロールプロシージャに制御を返す。VisualBasicでは必要に応じて後処理をしてからWindowsのデフォルトウィンドウプロシージャに制御を返すことになる。
VBXを作るには、VisualC++ とVisualBasic
Professional Editon 付属の CDKが必要になる。
また、VBXはVisualBasicのバージョンアップと共に機能が強化されているため、VisualBasic 3.0用に作成されたものは2.0では動作しないということがある。十分に注意してほしい。
VBXは便利だが作成はそんなにラクではない。というのも、現実的には C++のオイシイところはほとんどつかうことができないので、Cで記述しなくてはならないからだ。
ある程度複雑なVBXが必要になったなら、その用途にあったVBXが市販されていないかをまず確認した方がよい。結局買ってきた方が安くつくからだ。また、Microsoftの Visual Control Packなどに含まれているカスタムコントロールは、そのほんどがサードパーティ製のモノのサブセットである。きちんとした機能が欲しければ、サードパーティ製品を購入すべきである。Microsoftといえどもそれらのソースコードを持っていない可能性が高いから、バグにもすぐに対応できないと思われるからだ。
我が国では、文化オリエント社が米国の優秀なVBXを多数発売している。
VisualBasicが隠蔽しているメッセージの問題やオブジェクトの再利用といった問題では、VBXが解決してくれる。しかし、VisualBasicがあらかじめもっていない機能、つまりAPIには用意されているがVisualBasicには用意されていない部分がある。これは、もちろんVBXで解決する手段がある。この方法は低レベルなAPIは隠蔽されており直接タッチしなくてもVBXの機能でサポートされるから、事故も起こりにくく安全だ。
しかし、VBXをいちいち用意しないといけないなど逆に面倒なこともある。こんなときには、Windows APIを直接VisualBasicから呼ぶとよい。Windows APIは前に述べたとおり実態は DLLである。VisualBasicには DLL内の Exportされた関数をコールする機能がある。もちろん、APIなどの関数はVisualBasicの言語仕様にはないものであるから、Declare文で関数の引数、戻り値、関数のあるモジュールなどを記述して、VisualBasicに教えてやらなくてはならない。しかし、インポートライブラリを作るなどの手間はまったく必要ないので、ごくカンタンに実現するコトができる。
しかし、APIをキチンと利用するためには、Windows自体のメカニズムやWindows API の動作の詳細、さらにはメッセージなどについての知識が必須になる。さらに、VisualBasicが隠蔽している部分とバッティングするためにうまく動作しない関数もある。
また、VisualBasicの言語仕様上呼び出すことができない関数も存在する。コールバック関数などがその代表例だが、これはコールバック関数を使うためのVBXで解決することが可能だ。戻り値がポインタになっている関数を使うにも工夫が必要だ。
また、VisualBasicのデータ型はすべて Signedであるが、API関数には Unsignedであるものが少なくない。このようなときには意図しない値が渡る可能性がある。
このように、Windows APIは万能ではないし、使い方も必ずしもカンタンではない。一つ間違えるとUAEということになりかねないし、よく理解しないで使っているとリソースやメモリが減り続けるといった発見しにくいバグの原因にもなりやすい。しかし、キチンと勉強して使えば、VisualBasicを拡張する上でかなり有用な方法である。ただ、気づいたらVisualBasicの部分よりAPIのコール部分の方が多くなっていたなどというコトになりかねない。そこまで行ったらVisualBasicを使うメリットはない。最初からCやC++を使うべきなのだ。
つまり、VisualBasicを活かすためには、なるべくVisualBasicの機能をうまく使いこなすことであって、いたずらに拡張を目指すことではないということだ。
※図として欲しいもの
Declare 宣言の適当なリスト
Professional Edition のVisualBasicには、Microsoftの提唱するODBC(Open Data Base Connectivity)のドライバマネージャが付属している。ODBCは、Access、ExcelといったMicrosoftのアプリケーションからも使うことのできる窓口であり、C/S(クライアント/サーバ)環境でのデータベースにアクセスできるばかりでなく、アプリケーション間のデータ交換や共有に威力を発揮するものだ。また、同じコードであっても接続先さえ変えれば別のデータベースに同様にアクセスできるのもメリットである。
しかしながら、これには少なからず問題があるのも確かである。というのも、VisualBasic 2.0ではODBCの古いバージョンのAPIしか使うことができないので、機能が低いのだ。また、VisualBasic 2.0自体のODBC関係の動作にはかなり怪しいところがあるのも否定できない。現実的にはVisualBasic 3.0以降で初めてODBCは使えると思った方がよい。ちなみに、VisualBasic 3.0でのデータベース関係の言語仕様は Access 1.1日本語版にきわめて近い。日本語もほぼ問題なく通るから、あとは文字列処理だけが問題になる。
また、AccessコンパチのローカルデータベースもVisualBasic 3.0からのサポートである。このデータベースエンジンは Jetと呼ばれている。VisualBasic 3.0にはJetが装備されているだけでなく、それを能率よく使うための Dataコントロールが用意されている。また、コントロール自体もテーブルのカラムをテキストボックスやチェックボックス、ピクチャーボックスなどにリンクさせるバウンダリー機能を装備した Data-Aware コントロールになっている。
ただし、日本語版 Access 1.1 の.MDBファイル形式とはコンパチビリティーがない。もし、Accessとのデータ交換を考えるならば、Access 1.0形式のデータベースを Accessで作成し、1.1形式のファイルをインポートすれば、VisualBasic 3.0から読むことが可能だ。
このように、Microsoft製品だけでデータベースをキチンと使いたいならば、VisualBasic 3.0は必須である。
しかし、サードパーティ製品を考えるならば、Btrieve for WindowsのDLLが Novelから供給されている。これをDLLコールすれば、Btrieveのファイルにアクセスすることが可能だ。また、文化オリエント社からは DBControls というVBXが発売されており、これを使えばふつうのコントロールも Data-Aware コントロールのように使うことができる。ただし、サポートされるデータベースエンジンは dBASE形式か ObjecTrieve形式のものである。ObjecTrieveなどのエンジンは同じく文化オリエント社から発売されている。
一方、C/S環境を考えた場合、ODBCは実のところVisualBasic 3.0でも絶望的にパフォーマンスが悪い。C/S環境で一般的に使われるデータベースサーバー(Oracle 7 Serverや Sybase SQL Server、もしかしたら Microsoft SQL Server)などは SQLをベースとしたものだ。SQLはそれ自体が ANSIで規定された文法を持つ言語であり、データを一連のセットとして扱うものだ。ところが、Jetはインデックスを基本とする ISAM系のエンジンに SQLモドキの構文をかぶせたものである。VisualBasicや Accessから ODBC 経由で SQL 系のサーバーにアクセスしたものを、VisualBasicや Access Basic のような使いやすい構文で使えるように、内部的には Jetのエンジンが使われる。ここでのオーバーヘッドがかなり大きいのである。
そう考えてくると、C/S環境で ODBCを使うのは決して得策ではないことが容易に理解できるだろう。
そうなると、システムラボから発売されているVBMan for ODBCのように ODBCをマトモに利用するための VBXを使うという解決法もある。
いずれ、C/S環境のデータベースアクセスツールは発展途上にある。現在言えるのは、MSKKだけを窓口と考えた場合、VisualBasic 2.0J は残念ながら使えるクライアントツールではないということだ。
※図として欲しいもの。
ODBCの構造概念図
VisualBasic 3.0のデータベースアプリケーション実行画面
DBControls をフォームに配置したときに出てくるダイアログの画面
すでにデータベースのところでチョット出てきたが、VisualBasicには兄弟とも言える製品がある。これらはいずれもMicrosoft製である。VisualBasicほど汎用性のある言語ではないが、特定の目的を持ったアプリケーションでありながら、その処理に適したマクロとしてVisualBasic相当のモノを持っているモノだ。つまり、アプリケーションに特化したVisualBasicということが言える。
これらには現在のところ、次のようなモノがある。
★Test 3.0 アプリケーションのテストをするためのツール
TestにはTest
Basicが搭載されており、アプリケーションをテストするための細かい制御関数が装備されている。モノによってはWindows API以上に強力な機能を持っている。Testの機能はDLLとして実現されているので、Pascal 形式の関数はVisualBasicから呼び出すことが可能である。さらに、Visaul Basic Powerup kit with MS Test というBBSなどで配布されているキットを使えば、ほとんどの機能をVisualBasicから使用することが可能だ。詳細については、DDJ日本版 1994年○月号の『VisualBasicではじめるWindowsプログラミング』をご覧いただきたい。
★Access 1.1J データベースアプリケーション
データベースを使うための Access
Basicが内蔵されている。かなり高度なことまでできるが、ある程度以上の規模のデータベースになると、データへのアクセス速度は極端に遅くなる。また、VisualBasicからは呼び出すことができないので、
DDEなどを使うコトになる。これには制限が多くあまりおすすめできない。現実的には、比較的小規模のデータベースでAccess スタンドアローンで使うべきだろう。なお、近く日本語版が発売されるというAccess 2.0 ではアクセス速度などが改善されている。
★Excel 5.0 スプレッドシート
Excel 4.0 までは表形式で記述する特殊なマクロだったが、5.0からは Visual
Basic for Application Edition (VBA)が搭載されている。これはまさにVisualBasicという名前であるが、VisualBasic 2.0に比較したらずっと進んだVisualBasicである。というのも、OLE2の OLE Automation
機能を使って外部からこのマクロをキックすることができるからだ。単にキックするだけでなく、戻り値を得ることができるので、VisualBasic 3.0の MSOLE2.VBXを使えば、まるでVisualBasicのカスタムコントロールのようにExcelを内蔵させることができる。このとき、OLE2 の In-Place
Activate 機能が使われるため、本当に ExcelがVisualBasicのフォームの内部に配置されたように見える(図)。しかし、残念ながらVisualBasic 2.0ではOLE2をサポートしていないのでこれは実現できない。
★Word 6.0 ワードプロセッサ
ワードプロセッサに特化した Word
Basic が搭載されている。VBAという名前ではないが、OLE Automation でVisualBasic
3.0からWord Basic の機能を呼び出すことができる。たとえば、VisualBasicのテキストボックス中にある文章のスペルチェックを
Wordのスペルチェック機能を使って実現することが可能だ。
このように、MicrosoftのアプリケーションにはVisualBasicに準ずる言語が搭載されてきている。さらに、低レベルな用途に向いた TestではDLLが公開されているし、Excelや Word では OLE Automation の機能が使えるから、VisualBasicからこれらのアプリケーションの持っている機能をVisualBasicの機能の一部として呼び出すことが可能である。
いずれ、これらのマクロ言語はすべて VBAとして統合され、VisualBasicから OLE
Automationを使って呼び出すことができる時代がくる。そうなれば、特定の用途に向いたアプリケーションを買ったり作ったりするのではなく、既存のアプリケーションの機能をVisualBasicから呼び出して使うことができるようになるわけだ。まさに究極のアプリケーションカスタマイズである。
Windowsは16bitから32bitに以降しつつある。これにともなって問題が露呈してきたのがVBXの仕様である。実は、VBXの仕様は16bit Windowsを前提としたものであり、32bitへの拡張性は考慮されていない。このため、現実的に VBXは近い将来にはなくなる運命となった。
しかし、VisualBasicを活かすためには、VBXのような仕組みは必須である。そこで考え出されたのが、OCXである。
OCXは、OLE2のアーキテクチャーを元にしたカスタムコントロールである。実際には、VBXと同じくDLLとして実現されている。次の概念図を見れば分かるとおり、この構造は一般的な
OLE2サーバーとほとんど同じである。
※OCXの概念図
※OCXのアーキテクチャー
言うならば、OCXとは OLE2サーバーの(Excel などと比較して)単機能なものを DLLとして実現したものである。実際に OCXを使うときには、LoadLibrary して DLLをロードしてから使う。このため、通常の OLEサーバーに比較して OLEエンベッド時にいちいちディスクにアクセスに行くといったことはない。
とはいえ、実際に OCXを使ってみると、16bit環境では明らかに遅い。したがって、本格的に32bit環境が普及するまでは、しばらくはVBXも生き残ることになりそうだ。
また、OCXを使うことができるのは、現在のところ
Access 2.0のみである。本来VisualBasicのために考えられたと信じていたOCXを使うことのできるVisualBasicがないというのも意外なことだ。OCXを使うことのできるVisualBasicは、次のバージョンからということになりそうだ。
VisualBasicを取り巻く流れの中で、大きなものは二つある。一つはVBAやOCXといったOLE2アーキテクチャーを元にしたものだ。そして、もう一つはデータベースのクライアントツールとしてのVisualBasicだ。
現在のところ、後者のDB関係にはちょっと見通しがきかないところがあるが、前者のOLEベースのオブジェクト指向環境には明確なビジョンと流れがある。といっても、これにも二つのコトがある。
一つはすでに見えていることだが、VBAを搭載したアプリケーションの一部または全部の機能をVisualBasicの一部として取り込んでしまうという、アプリケーション統合のための手段としてのVisualBasicである。これはもちろんVisualBasicを使わなくても、あるアプリケーションのVBAを使って外のアプリケーションの機能を呼び出すこともできるようになる。しかし、細かい制御やプログラミング環境としてのまとまりの良さから、中心はVisualBasicになることは間違いないだろう。
もう一つは、オブジェクト指向OSでの開発ツールとしてのVisualBasicである。Microsoftでは、次期Windows NT(Cairo)ではオブジェクト指向のOSになると言明している。オブジェクト指向のOSとは何か? これは一言では言いにくいのだが、あえて一言で言うならば、OSのすべての機能をVisualBasicから呼び出すことができるようになるというコトだ。つまり、OS自体がVisualBasicからアクセスできる小さな OLEオブジェクトの塊になるというわけである。別の言い方をすれば、OSそのものが VBAみたいなモノの集合体になってしまうということだ。つまり、今までメッセージだAPIだと言っていた部分は徐々になくなっていき、すべてが隠蔽されたオブジェクトになってしまうというのだ。
オブジェクト指向OSの重要性は、ネットワークで接続された分散処理型環境でその本領を発揮することになるだろう。しかし、現在のOLE2アーキテクチャーでは、あくまでもアプリケーション主体のオブジェクト指向であり、本当にOSがオブジェクト指向になるかというと、少々疑問が残るところもある。おそらく、Cairoでは完全なオブジェクト指向OSと言えないモノであり、さらに次のWindows NTで完全なオブジェクト指向OSとなるのではないだろうか。
いずれにしても、そうなったときのOSでもっとも適した開発環境はといえば、間違いなくVisualBasicであろう。アプリケーションの連携の中心、そして開発の中心はすべてVisualBasicになっていく。まさに、BASICには薔薇色の未来があるというコトだ。これこそが、Microsoftの、いや Bill
Gates のBASIC作戦なのだ。
そうは言うものの、我が国の状況はいささかさびしいものがある。純然たるWindowsの将来を考えた場合、もっとも重要なテクノロジーである OLE2をVisualBasic 2.0Jではまったく触ることができないというのは大きな問題だ。
また、Windows NTやWindows 95が普及してくると、ネットワーク環境があたりまえになってくる。これらの OSでは非常にカンタンにネットワークの設定ができるからだ。そうなってくると、ダウンサイジングに熱心なC/S環境で食べてきたunix屋は、がぜんWindows NTに注目することになる。同時に、Oracle や Sybaseといったデータベースサーバーで実績のあるソフトハウスも NT用の安価なサーバーを発売してきた。今年こそは本当に C/S環境元年になりそうだ。
PCのソフトウェアベンダーは気づいていないが、unixベンダーはPC市場に対して非常に大きな危機感を持っているのだ。彼らがPCでの C/S環境市場を開拓しようとするのは必至である。このままでは、我が国のPCベンダーはアプリケーションやツールで米国に大きな遅れを取り、C/S環境でunixベンダーに叩きのめされることになるだろう。
そんな今年の動きをMicrosoftが読んでいないワケはない。米国ではすでにいろいろな動きがある。しかし、MSKKでは人的リソースや計画性に難があると見えて、売るものがないのだ。現に、クライアントツールとしてAccess 1.1しかコマがない。VisualBasic 3.0さえあればこんなヒドいことにはならなかっただろうに。
そういうわけで、本書の読者諸氏にオススメしたいのが、VisualBasic 3.0の使用である。英語版だからとかいって二の足を踏んでいる場合ではないのだ。今やっておかないと、いつ出るかわからないVisualBasic 4.0まで、我々はなにもできないのである。