Insider's Eye： Windows 2000のデバイス ドライバを探る 第2回 WDMは何が変わったのか（1／2） 元麻布春男 2000/02/05

　WDM] Win32 Driver Modelの略。Windows 9xとWindows NTで共通のデバイス ドライバ（バイナリ）が利用できるよう、Windows NTのデバイス ドライバ モデルに基づいて定義された新しいデバイスドライバ アーキテクチャ。

　 もし、あなたの持っているコンピュータ用語辞典がWDMについてこのように書いているとしたら、残念ながらその用語辞典の情報は最新ではない。WDMは、もはや「Win32 Driver Model」の略ではなく、「Windows Driver Model」の略になってしまったからだ。また、WDMの目標から、バイナリレベルでの互換性も削除されてしまった。「Win32」から「Windows」へ変更は、Windows 9xとWindows NT（Windows 2000を含む）で同じデバイス ドライバを利用できるようにするという、Microsoftの従来の約束の後退を意味する。もちろん、同じデバイス ドライバが利用可能なこともあるだろうが、それはWDMによって保証されたものではないのである。

　なぜ、このような変更が行われたのだろうか。ユーザーの中には、デバイス ドライバに関するWindows 9xとWindows NT間のバイナリ互換性の約束が、大々的に告知されることなく反故にされたことに対して、裏切りに似た感情を持つ人さえいるかもしれない。WDMによって、これまでデバイス ドライバ サポートに難があったWindows NTも、Windows 9x並みのサポートが得られるようになるのでは、と考えていた人はなおさらそう思うことだろう。

　だが、Microsoftとて、意味なく約束を反故にするハズがない。ここでは、そもそもWindows NTのデバイスドライバとはどんなものなのか、次にWDMとはいったい何なのかということを簡単に振り返ったうえで、なぜWDMが変わったのかについて、考えてみることにしよう。

Windows NTカーネル モード ドライバとは？

　本来のWindows NTのデバイス ドライバ モデルには、どうやら正式な名称らしきものはない。「Windows NTカーネル モード ドライバ（Windows NT kernel mode driver）」と呼ぶのが一般的だが、これは固有名詞ではなく、一般名詞だと考えられている。名称が示すように、このドライバはカーネル モードで動作するわけだが、逆にわざわざカーネル モードと断ってあるのは、そうでないデバイス ドライバも存在する（した）からにほかならない。図1は、Windows NT 3.51のシステム アーキテクチャを示したものだが、カーネル モードのI/Oマネージャの下にカーネル モード ドライバがあるのに加え、ユーザー モードの各種サブシステム内にGDIやマルチメディア関連のデバイス ドライバなどがあり、そこにもユーザー モード ドライバ（subsystem-specific driverとも呼ぶ）が存在した。

図1　Windows NT 3.51のシステム アーキテクチャ

Windows NT 3.51では、ユーザー モードの各種サブシステム内でGDIやマルチメディア関連のデバイス ドライバが動作するようなアーキテクチャとなっていた。

　カーネル モード ドライバとユーザー モード ドライバがどのような関係にあったのか、ということをGDIを例に示したのが図2だ。両者が連携して、1つの機能を実現していることが分かる。

図2　Windows NT 3.51のカーネル モード ドライバとユーザー モード ドライバの関係

図のように、Windows NT 3.51では、ドライバがカーネル モードとユーザー モードに分かれており、両者が連携して1つの機能を実現するようになっている。このような構成により信頼性や移植性は向上するが、ドライバの構造は複雑になり、開発は容易ではなかった。

　なぜ、わざわざ1つの機能をユーザー モードとカーネル モードで分けたのか。その理由はシステムの信頼性と移植性（ポータビリティ）の向上のためと思われる。図2の中でビデオ ミニポートと呼ばれるドライバは、ハードウェア固有のリソース情報（I/Oアドレス、メモリアドレスなど）を扱うもので、非常にシンプルなものだ。線や円弧といった図形の描画はディスプレイ ドライバが行う（ディスプレイ ドライバがハードウェアを参照する際に、ビデオ ミニポートが呼び出される）。複雑な処理を行うディスプレイ ドライバは、その分問題が生じることも少なくない。ディスプレイ ドライバをユーザー モードに置いておけば、万が一のエラーが発生した場合でも、OS全体に致命的な影響が及ぶことを回避できる可能性が高いというわけだ。また、複雑なコンポーネントをユーザー モードに置き、シンプルなカーネルを維持することで、OSの移植性も高まる。最盛期において、Windows NTはMIPS、PowerPC、Alphaの各RISCプロセッサもサポートしていたことからも分かるように、移植性も重要な要素であったわけだ。

　逆に、図2のような構造の問題は、性能上のオーバーヘッドが大きいことだ。ディスプレイの描画にユーザー モードとカーネル モード、両方のコンポーネントを必要とするということは、描画の際にユーザー モードとカーネル モード間での遷移が頻繁に発生するということでもある。そのオーバーヘッドは決して小さくない。

　もう1つの問題は、DirectXのサポートである。DirectXは、システムの信頼性を損なわないよう、OSの監視下のもとでアプリケーションにハードウェアの機能を直接利用可能にするテクノロジである。DirectXが想定する用途（リアルタイム グラフィックスなど）では、アプリケーションとハードウェアの間にユーザー モードとカーネル モードへの遷移のようなオーバーヘッドが介在する余地はない。ディスプレイ サブシステムをカーネル モードへ移すことは、DirectXをサポートするうえで、不可避といってよいだろう。

　そこでWindows NT 4.0は、図3のようにディスプレイドライバやGDIといったコンポーネントをカーネル モードへと移した。これにより、Windows NT 4.0は限定的ながらもDirectXをサポートすることが可能になったが、すべてのコンポーネントがカーネル モードへ移行したわけではない。たとえばサウンド関連のサブシステムは、Windows NT 4.0ではユーザー モードのままであった。

図3　Windows NT 4.0のシステム アーキテクチャ

Windows NT 4.0では、これまでユーザー モードで動作していたディスプレイ ドライバやGDIをカーネル モードで動作するように変更した。これにより、DirectXが限定的ながらも実装可能となった。

INDEX
	第1回	なぜWindows 2000を使わないのか
	第2回	WDMは何が変わったのか(1/2)
		WDMは何が変わったのか(2/2)
	第3回	WDMの理想とするところ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）