新規記事投稿

フォロー記事投稿

記事のキャンセル

さてさて、Win 95 が扱う VxD は、Win 3.1 の仮想デバイスドライバを元に拡張した
ものだ。

そのため、ファイル名の拡張子は、

        Win 3.1 のころは、.386 や .EXE

        Win 95 では、.VXD

となっている。



これらは、Win NT で使用される仮想デバイスドライバ( NT の場合は、VDD と呼ぶ )
とは、ドライバ自体の構造が異なるので、そのまま NT 用として使うことは出来ない。

 Win 95 と Win NT で、ほぼ同じ、Win32 のシステムでありながら、NT 専用のドライ
バが、別途提供されていたりするのは、このためだ。

# Win98 からは、Win NT で共通に使える WDM が提供されている。



アプリ側から見ると、Win 3.1 と Win 95 のデバイスドライバでは、推奨されるアクセ
ス方法が異なっている。


 Win 3.1 ( Win16 だ )の場合は、

    1. INT 2Fh により、VxD が提供する仮想 86 モードの API エントリを取得する

    2. 利用したい VxD の API エントリを FAR CALL する

という、極めて DOS の システムコールに近いスタイルで VxD を使う。


 1. の実行には、通常、デバイスドライバを識別するための VxD ID と呼ばれるものが
必要となる。これは、 MS に申請しなければ、いけないモノなんだそうで、世間に通用
する、まともなドライバを書こうとすると、結構、面倒な感じ。



 Win 95 ( Win32 だ )の場合には、Win32 が提供する API 経由で VxD が使える。

    1. Win32 API - CreateFile で VxD をオープンする

    2. Win32 API - DeviceIoControl で VxD に処理を依頼

    3. Win32 API - CloseHandle で VxD をクローズする


# DOS でも、これに近い形で、デバイスドライバが使えたね。

この方法では、オープンされた VxD のハンドルを使うので、上述の VxD ID は不要だ。

# ラッキー !!


また、1. や 3. では、VxD のダイナミックロードやアンロードも出来る。

つまり、DLL 並みに、こちらの都合で、仮想デバイスドライバをメモリから抜き差しす
ることが、可能なわけ。



 VxD 内では、1. 2. 3. の操作は、それぞれ、OS からのメッセージ

    SYS_DYNAMIC_DEVICE_INIT

    W32_DEVICEIOCONTROL

    SYS_DYNAMIC_DEVICE_EXIT

として送られてくるので、ドライバ内に、これを取り扱うプログラムを書いておく必要
がある。

# 少し凝ると、W32_DEVICEIOCONTROL の応答に、Winsock のような非同期応答を VxD で
# 行なわせることもできるぞよ。



なお、この呼び出し方法は、Win NT でも共通に使えるので、仮想デバイスドライバを
使うアプリケーションのレベルでは、アプリ自体を NT 専用として書きなおす必要が、
ほとんど無い。

よく知られているように、Win 32 のアプリケーションは、Win 95 と NT で共用できる
わけだ。




余談だが、VxD が提供する API の使い方として、上記以外の方法に、I/O トラップと
呼ばれるトリッキーなやり方がある。

これは、I/O ポートに対する入出力が、VxD で仮想化されることを利用するものだ。
 
 VxD で I/Oポートのハンドリングを指定しておくと、CPU が実行するポートへのアク
セスは、OS でトラップされ、VxD 内へ制御が移る。そのため、システムで使用してい
ない空きポートを使って、VxD 内のプログラムを実行させることが出来る。

この時、真正直にポート入出力を行なう必要はないので、適当に API として動作させ
れば、それで良い。この方法も、Win16 と Win32 で共通に使える。

 DOS の時代のソフトウェア割り込みと、ほぼ、同じ感覚の利用法だね。


# オタッキーくんの考えることは、あまり、進歩していない感じがする。