Insider's Eye: Windows 2000のデバイス ドライバを探る第3回 WDMの理想とするところ
|
||
Windows NTのデバイス ドライバ レイヤであるカーネル モード ドライバ(kernel mode driver)が階層化されたものであったこと、その利点については「第2回 WDMは何が変わったのか」で述べた。では、なぜWDMが必要なのか。逆にいえば何がカーネル モード ドライバに欠けていたのか。また、WDMが提供されるもう一方のプラットフォームであるWindows 98にとって、WDMはどのような意味を持つのか。ここでは、こうしたWDMに関する疑問に答えよう。
WDM誕生のキッカケ
WDMが誕生する直接のきっかけになったのは、USBおよびIEEE 1394という高速シリアル バスの登場だろう。これらの新しいバスをどのようにサポートするか、ということについてMicrosoftが下した結論こそ、WDMに違いない。おそらく、この時点でMicrosoftの社内では、将来のOSをWindows NTベースで一本化するという話になっていたのではないかと思う。そこで、Windows 9xとWindows NTで共通したドライバ モデルを用意し、USBとIEEE 1394を共通のドライバ ベースでサポートし、将来のOS統合に備える、というシナリオが描かれたのだろう。
この推定が当たっているかどうかはともかく、WDMは、Windows 98と将来のWindows NT(つまりはWindows 2000)で、USBとIEEE 1394をサポートする共通の枠組みとしてスタートすることになった。将来的には、ディスプレイ ドライバを除く、大半のデバイス ドライバをWDMベースに移行させることを視野に入れながら、Windows 9x系OSとWindows NT系OSで、同じデバイス ドライバを使えるようにしたい、という触れ込みであった。それにより、周辺機器ベンダは1つのデバイス ドライバで2つのOSに対応することができるし、当時デバイス ドライバサポートで遅れをとっていたWindows NTのドライバ サポートがWindows 9x並みになる、という期待もあったのではないかと思われる。
WDMのベースとして選ばれたのが、Windows NTのデバイス ドライバ レイヤであるカーネル モード ドライバだ。将来の統合されたOSのベースがWindows NTである以上、WDMのベースにWindows NTのデバイス ドライバ モデルを採用しても、何もおかしなことはない。だが、そのままカーネル モード ドライバをWindows 9xに持ち込むわけにはいかない。カーネル モード ドライバ モデルには、Windows NTに依存した(たとえばHALの機能に直接かかわる)部分があるからだ。つまり、WDMはカーネル モード ドライバからWindows NT依存部を取り除いたものであり、ある意味でカーネル モード ドライバのサブセットと考えられる。
その一方、WDMには、もともとのカーネル モード ドライバに欠けていた機能も追加された。それはいうまでもない、プラグ アンド プレイ(Plug and Play)だ。Windows 2000のカーネル モード ドライバではACPIベースのプラグ アンド プレイがサポートされているが、当時のカーネル モード ドライバにプラグ アンド プレイ機能はなかった。将来的にはもちろんのこと、最大のターゲットであるUSBとIEEE 1394がプラグ アンド プレイをサポートしている以上、WDMがこれなしで済むハズがない。特にホットプラグの機能をサポートするには、デバイス ドライバのダイナミックなロードとアンロードが不可欠だ。
Windows 98にとってのWDMサポートのメリット
ここでWDMをWindows 9xの側から見ておこう。Windows 9xのデバイス ドライバの多くは、Windows 3.xから引き継いだ、階層化されていないデバイス ドライバ(モノリシック ドライバ)である。たとえばキーボード ドライバ(VKD)は、ユーザーやカーネルといったOS部と、PS/2互換キーボード コントローラである8042(チップセット内の相当する部分)をカバーしている。もし、この構造のままUSBキーボードをサポートしようとすると、USBキーボードからOSにまたがるモノリシック ドライバを用意しなければならない。
これは、USBキーボードを提供しようというベンダ(USBキーボード ドライバを開発する必要のあるベンダ)にとって困難であるばかりでなく、USBという最大127のデバイスを接続可能なバスの特性を活かすうえでも難しい。USBキーボード ドライバという特定のデバイスのドライバの中に、USBというバス サポートが埋めこまれてしまうことになるからだ。複数のデバイスで共有されるバスと、それぞれのデバイスで、ドライバを分離することでバスの共有が容易になる。
また、OSからデバイスにまでまたがるモノリシック ドライバは、処理がドライバに渡ってから結果が得られるまで、長い時間がかかりがちだ。つまりデバイスにアクセスしたとたん、長い待ち時間を要する可能性があるわけで、システムの良好なレスポンスが保証できない。汎用的な階層化されたドライバ モデルを備えていないWindows 9xにとってWDMは、ドライバ開発を容易にする、将来のOS統合へ向かった準備、といった意味を持つと同時に、レスポンスのよいシステムを実現するための枠組みを目指すものと考えられる。
もう1つ、Windows 9xにとってWDMの重要な役割は、共通化されたエミュレーション機能を提供することだ。Windows NTにないWindows 9xの特徴は、リアルモード アプリケーション(ハードウェアに直接アクセスするアプリケーション)との互換性だ(将来的にはDirectXに置き換えられていくものだが)。WDMが共通化されたエミュレーション レイヤを提供することで、そうしたアプリケーションのパッチが容易になる。たとえば、個々のサウンド チップがSound Blaster互換のエミュレーションを提供した場合、ゲーム ベンダはそれぞれとの互換性を検証しなければならないが、Windowsが標準的に提供するエミュレーション機能であれば、それとの互換性だけを検証すればよい。あとは、サウンドチップ ベンダが、Windows標準のエミュレーション機能を利用できるドライバ(つまりはWDMに準拠したサウンド ドライバ)を提供してくれれば、問題は解消するハズだ。
ここでWDMの構造を簡単に見ておこう。図にあるミニ ドライバは、それぞれのデバイス固有の機能を実装した小さなドライバで、OSから直接参照されることはない。OSに対してさまざまな機能を提供するのはクラス ドライバの役割であり、デバイス(ハードウェア)とOSは完全に分離(抽象化)される。また、大半のクラス ドライバをMicrosoftが提供することで、サードパーティは主にミニ ドライバの開発に専念できるため、開発が容易になる。
Windows 9xのミニ ドライバの構造 |
WDMでは、デバイス ドライバが図のようにミニ ドライバとクラス ドライバに分かれている。ほとんどのクラス ドライバはMicrosoftが提供するため、デバイス ベンダはミニ ドライバの開発を行うだけでデバイス ドライバが提供できる。 |
仮想ドライバ(VxD)は、上述したエミュレーション機能を提供するドライバだ。つまり、ハードウェアに対するアクセスをクラス ドライバに対するコマンドに変換するドライバである。システム サービスというのが、WDMの実体であり、I/Oの管理を行う部分だ。
WDMの理想と現実
WDMが最初に実装されたのは、Windows 95 OSR 2.0である。ただし、この時点ではWDM開発の目的の1つであったUSBのサポートは行われておらず、事実上開店休業状態だった。WDMによるUSBサポートが実現したのは1996年の年末、USB Supplementがリリースされ、Windows 95 OSR 2.1になったときのことだ。その後、Windows 9xはWindows 98、さらにはWindows 98 Second Edition(SE)へとアップデートされていった。そのたびにWindows 9xに組みこまれているWDMマネージャは、少しずつ改善されているようだ。
しかし、これは逆にバージョン間での非互換性があるということだ。たとえば市販されているUSBデバイスの中には、Windows 98 SE以外での動作を保証しないものがあるが、MicrosoftはWindows 95 OSR 2.1やWindows 98のユーザーに、USBサポート部だけをWindows 98 SE相当にするアップデートを提供していない。また、DirectX 7のDirectMusicのハードウェア アクセラレーションは、Windows 98 SE以降でないと利用できない。これは、Windows 98 SE以降のWDMマネージャが必要なためと考えられている。
現時点で最新のWDMマネージャを備えるのは、間違いなくリリースされたばかりのWindows 2000だ。しかし、2000年末に登場する予定のUSB 2.0がサポートされるのは、とりあえず夏ごろリリース予定のWindows ME(Millennium Edition)だけ、それも2000年末にリリースされるUSB 2.0 Supplementが必須というありさまだ。もし、WDMが当初の予定通りのものであれば、USB 2.0 SupplementはWindows 2000でもそのまま利用できたハズではないのか。だが、現実にはUSB 2.0 SupplementはWindows ME専用で、Windows 98 SEやWindows 2000でのUSB 2.0サポートは、「現在検討中」という状況だ(OEMからの要望はかなりあるようなので、実現する可能性はかなり高いと思われる)。結局、OSのバージョンとデバイス サポートは1対1の関係にあり、WDMの理想が実現されているとは言い難い。
それに加えて、第2回「WDMは何が変わったのか」で述べたバイナリ互換性の放棄である。WDMはもはやバイナリ互換性をうたったWin32 Driver Modelではなく、ソースレベルの互換性しか保証されないWindows Driver Modelになってしまった。
だが、Win32 Driver ModelがWindows Driver Modelになった理由はもう1つあるものと思われる。それは、Itaniumと同時にデビューする予定のWindows
NT/64だ。64bit化されたWindows NTと32bitのWindows NT間でドライバのバイナリ互換性を維持することは、不可能ではないにせよ、性能面あるいは機能面での制約がつきまとう。ソースレベルの互換性にして、64bit版と32bit版でそれぞれコンパイルし分ける、というのが現実的なところだろう。後は、本当にソースレベルでの互換性が保たれるのかどうか、それが気にかかるところだ。
INDEX | ||
なぜWindows 2000を使わないのか | ||
WDMは何が変わったのか(1/2) | ||
WDMは何が変わったのか(2/2) | ||
第3回
|
WDMの理想とするところ | |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|