Windows Info 第129回

DOS時代から使われてきたネットワークドライバーの改良がついに進む

　Windows 10のRSシリーズではネットワークドライバーの改良が行なわれている。

従来のNDISネットワークドライバーの動作環境。ネットワークアダプター（NIC。Network Interface Card）のドライバーはNDIS環境で動作してい

DOSやOS/2時代から使われてきたNDIS

　NDIS（Network Driver Interface Specification）は、MS-DOSの時代からマイクロソフトのOSで利用するネットワークデバイスドライバーの仕様の名称だ。最初はMS-DOSのネットワークで利用するイーサーネットカードのデバイスドライバーの仕様として、マイクロソフトと3Com社が開発した。

　NDISは、その後はWindowsで利用されたが、当時は、Windowsの下にMS-DOS環境があり、ドライバーの仕様を大きく変える必要がなかった。

　ちなみに本来ならNDIS 1.0となるべき最初の仕様は、単にNDISと呼ばれていた。また、ネットワークが普及しはじめたOS/2やWindows for Workgroups 3.1の時代には、仕様が拡張されNDIS 2.0となった。最初の大きな変化はWindows NTが登場したときである。Windows NTは、32bit CPUの仮想メモリや特権モードといった、近代的なプロセッサを使う、近代的なマルチタスクOSとして作られ、デバイスドライバーは、従来のMS-DOSに比べると複雑化した。

　マイクロソフトは、このWindows NT用にNDIS 3.0を開発した。Windows NT Device Driver Modelと呼ばれる最初の32bitデバイスドライバー仕様に基づくものだ。Windows 95以降、このNDIS 3.0をベースにNDIS 3.1、4.0、5.0～5.1と更新されていく。NDISは、デバイスドライバーの仕様であるとともにWindowsが用意するネットワーク関連のモジュール（たとえばプロトコルを処理するモジュール）の動作環境でもあるため、Windows側の機能が拡張されてもNDISのバージョンは上がっていく。

　たとえば、Windows XPでは、無線LANにおいて接続前に電波強度を表示するなどの機能が組み込まれた。また、携帯電話ネットワークの接続は、従来はモデム扱いで接続にはダイヤルアップ接続が使われていたが、これもWindows 8でNDISに取り込まれ、ネットワークとして接続できるようになった。

　さて、こうして発展してきたNDISだが、問題もあった。1つには、Windowsの標準的なデバイスドライバーフレームワークであるWDF（Windows Driver Foundation）との違いが大きく、標準的なデバイスドライバーの作り方と大きく異なっている。

　またNDIS側には、電力管理などの機能がなく、この部分では、WMFと連携する必要がある。WindowsのデバイスドライバーはWDFの導入により、「差分」のみを記述する構造となり、以前のWDM（Windows Driver Model）より開発が簡単になった。しかし、ネットワークドライバに関しては、NDIS仕様に従うため、そのメリットが得られなかった。

開発が面倒だったWindowsのネットワークドライバー
これまでよりは簡単になることが期待できる

　RS2（Windows10 Ver.1703）からマイクロソフトは、「NetAdapter Class extensions for WDF」（NetAdapter Cx）のプレビューを開始した。Class Extentionsとは、WDFのカーネル用ドライバークラスの拡張として組み込まれる機構である。

　一般にドライバーの「クラス」とは、特定の種類のデバイス、たとえばネットワークやストレージといったドライバーの「ひな形」を意味し、このひな形に対して、実際のハードウェアとの相違部分や足りない部分を追加することでデバイスドライバーを作成する。この方法では、ゼロからドライバーソフトウェアを書く必要がない。また、クラスで定義されている部分に対しては、信頼できるものとして別途検証やテストなどを念入りにする必要がないため、開発時の負担が減る。

　NetAdapter Cxは、ネットワークハードウェア（ネットワークアダプター）のドライバーの拡張機能として組み込まれ、この部分が従来のNDISスタックと通信することで、NDISプロトコルスタック側に変更を加えることなく、ネットワーク用のドライバーをWDFを使って記述できるようにするものだ。

　現在プレビューが進んでいるRS5（Windows 10 Ver.1809と予定されている）では、モバイルブロードバンドネットワークがこのNetAdapterCx対応となった。

　NetAdapterCxは、基本的にはWDFドライバーとして動作し、受信したパケットの処理は、クラスエクステンションを介してNDISスタックと接続する。また、USBやPCI Express用のバスドライバーの利用もWDFドライバーとして利用可能なため、全体として動作効率が高くなる。従来のNDISでは、NDISドライバーを管理しているNDISモジュール側を介して、USBなどのバス経由でアクセスしている。

　また、この方法では、プロトコルドライバーの部分には影響がなく、これまでずっと使われていたTCP/IPなどのプロトコル処理部分を変更する必要がない。ネットワークプロトコルは複雑で、さらに多数のメーカーの機器が関係するため、仕様書に厳密に対応することが求められると同時に、実情に合わせた実装も求められるという二律背反的な部分がある。

　このためにプロトコルスタックは長い年月をかけて完成されており、いきなりゼロから書き換えるというのは、かなりの困難が伴う。実際、テレビなどの家電にLinuxが組み込まれるというのは、すでにLinuxが実績のあるネットワークスタックを持っているからだ。

　Windowsでは、LTEや3Gなどのモバイルネットワークへの接続などを「モバイルブロードバンド（Mobile Broadband Network、MBN）」と呼ぶ。RS5では、このMBNで利用するUSBデバイス用のドライバーがNetAdapterCx対応のものに変更になった。インサイダープレビュービルド17655では、手動でドライバーを差し替える必要があったが、ビルド17677では自動的に差し替わるようになった。

　マイクロソフトによれば、NetAdapterCxにすることで、ドライバーが扱うデータの転送効率が高まるとしているが、今のところベンチマーク結果などが発表されているわけではなく、あくまでも論理的な話でしかない。それに、携帯電話ネットワークのように、通信状態が刻一刻と変化していく環境でユーザー側がベンチマークをするというのもかなりの困難を伴う。2つの測定で同じ環境とすることができないからだ。可能だとしたら長期間にわたって多数の測定を実施し、ネットワーク状態の影響を最小にするなどの手法が必要になる。

　とはいえ、今回のNetAdapter Cxにより、ユーザー側からみた「レガシー」がまた1つなくなったのも事実。実際には、内部にNDISプロトコルスタックは残るものの、ネットワークドライバーの開発は比較的容易になることが予想される。