(6) VB2を複数起動してみる
6月に突入しましたが、相変わらずの人生ですさるですこんばんは。
VBでちょっと大きなシステムを作ろうとすると、どーしても機能ごとにEXEを分けなきゃならんわけです。
いえ別にこれはVBに限った話じゃありませんが。
Officeだって起動後におびただしい数のDLLを呼びまくっているわけですから、採用しているアーキテクチャが異なるだけで、どんなシステムもやってるこたぁそんなに変わんないんですね。
まぁ理由としては多人数でえいやっと作る際に個々人への作業の振り分けが楽だったり、動作検証がマルチでできるので作業期間(延べ人月ではなく)が短縮できたり、一度にメモリ展開される機能が少なくなるので体感的な速度が向上したりとけっこういいことあるじゃないって感じなんですが。
これが検証大詰めになったり事後メンテだったりとなると、割と少人数(大抵は一人)で全部のモジュールの面倒をみないばなんなくなったりもするわけです。割と。
そうなるとどうしてもモジュール同士の突き合わせとか参照とかで、複数のプロジェクトを立ち上げたいんですよね。
VB6なんかだとこれができるんです。プロジェクトファイルをダブルクリックするだけで、同時にいくつでも起動可能。
でも、VB2はこれができないんですよ。先に起動しておいたVB2にフォーカスが移るだけ(T_T)。
で、VB2の同時複数起動をなんとか可能にしてみようと。思ったわけです。
今さらですが、VB2は16ビットアプリケーションです。
これを32bits Windowsで動かすと、WOW32ってエミュレータみたいなやつが動いて、その中で16ビットアプリが動作するんですね。
じゃあこのWOW32をVB1個に対して一つずつ起動できればおっけーなんではないかと。
実際そーいうマルチな起動に対応するようにできてるみたいですし。
…と思ったんですが、どうも呼ばれるプログラム側から汎用サンクAPIとかいう16ビットだか32ビットだかよくわかんないAPIで直にコントロールしなきゃならないらしいんですよ。WOW32の複数起動って。
自作のプログラムならともかく、今回なんとかしたいのはMicrosoft謹製アプリケーションですからねぇ。
ってことでこれは却下。
じゃ、できあいの手法でなんとかごまかせないか。
そもそも二重起動を防止しているロジックは、たぶんVBのプログラムそのものの中に実装されているんじゃないか、と考えてみました。
同一かどうかの判断根拠はファイル名で行っているのではないかと。
じゃあ、VB.EXEをリネームしていっぱい用意しておけば、用意した数だけのVBが起動できるかも。
やってみました。
なんか変な動作なんですよ。
「VB.EXE」→「VB2.EXE」でリネームして起動すると確かに両方起動するんですけどね。
「VB2.EXE」そのものは同時に2つ起動できるわけじゃありません。
最終的には.MAKファイルダブルクリックでいくつも起動できるよぅになりたいんですよねぇ。
VB2のプロジェクト選択機能は8.3形式でのファイル名表示ですし、640×480～800×600の画面解像度が当たり前だった時代の産物なのでダイアログが小さいんですよ。
「VB2.EXE」でも複数起動できないってことは、起動時のファイル名を二重起動の根拠に使ってるんでしょう。
てことで、起動するたんびに違うファイル名にしてやんないと二重チェックに引っかかるってことですね。
…あ。8.3形式？
じゃ、8.3形式を逸脱したファイル名に変更して起動したらどうでしょう。
VB2内部では8.3形式でしかファイル名を保持できないでしょうし、Windowsのプロセス管理が8.3形式に限定されないファイル名管理を行っていれば、VB2の二重起動チェックのロジックをだまくらかせるんではないかと。
試しに「コピー ～ VB.EXE」のファイル名のままで起動してみると。
らっきーってんで拡張子の関連づけも「コピー ～ VB.EXE」に付け替えて。
実際に仕事でイジっているデカいプロジェクトを次々に起動！
しまったぁ、VBXがっ！
…思い出しました。
VB2の頃のVBX(プログラムパーツ)って、多重起動できないものがいっぱいあったんです。
VB4になった時に、OCXが多重起動できるんで感動していたんでした。
でもCrystalReportsがシングルスレッドアパートメントタイプのOCXで使えねぇっ！とか怒っていたんでした。
ここまでやってよぅやっと思い出すとは…(T-T)
結論。
VBXを使用しているプロジェクトはほぼ不可能。