特集 Windows 9x or Windows 2000？ 2．Windows 9xカーネルの概要 デジタルアドバンテージ 2000/07/18

---

　オペレーティング システム（以下OS）とは、メモリやディスク ストレージなどのハードウェア資源や、ウィンドウやプロセスといったソフトウェア資源など、コンピュータが持つさまざまな資源を管理し、アプリケーションがこれらを円滑かつ効率よく利用できるように要求を調停するソフトウェアである。逆にいえば、OSの出来が悪ければ、いくらハードウェア的な機能や性能が優れていても、アプリケーションはそれらのメリットを十分に享受できないし、ひいてはユーザーもそれらの恩恵に浴すことができない。周知のとおり、ハードウェアの機能性や処理能力、容量などのスペックは、少なくともこれまでは予想以上のスピードで進化を続けてきた。したがってOSにも、本来はハードウェア同様の進化が求められるわけだが、現実にはこれは極めて難しい。

　MS-DOSのような単純なOSならともかく、現在のWindows OSは、マルチタスクや仮想メモリ、マルチウィンドウ、各種グラフィックス機能など、MS-DOSとは比べものにならないほど複雑なものになってしまった。このため新しい機能を追加しようとしても、単純にその機能を追加するというだけでなく、それによってシステムの別の部分に副作用を生じないかなど、整合性に細心の注意をはらう必要がある。しかし最も厄介なのは、「ソフトウェアの互換性」の問題だ。

　ハードウェアの進化が大幅なものであれば、そのメリットを余すところなく活用するためには、OSも大幅な構成の変更を余儀なくされる。もちろんユーザーにしても、新しいハードウェアによって提供される最新の機能は使いたい。しかしそれはあくまで、「今まで使っていたソフトウェアがそのまま使える」という前提のうえでだ。いくら機能が追加されたとしても、ソフトウェアに対するこれまでの投資が無駄になってしまうのでは困る。古いものも今までどおり、さらに新しいものが使えるOSが求められるのだ。つまりOSは、性能向上という前進を求められながらも、過去との互換性という点で後ろ髪を引かれるというジレンマを抱えている。このジレンマのまっただ中にありながら、発展を続けてきたOSがWindowsだといってよい。特に、MS-DOS時代の影を引きずるWindows 9xは、この荒波にもまれ続けた歴史的にも特異なOSだといってよいだろう。

　下図にWindows 9xのアーキテクチャを示した。以下では、この図を元にして、Windows 9xのアーキテクチャについて解説を進めていこう。なお、現在販売されている最新のWindowsはWindows 98 SE（Second Edition）だが、基本的なOSとしての構成は、Windows 95からWindows 98、Windows 98 SE、そして次期バージョンのWindows Meと大きく変化していない。

Windows 9xカーネルの構成

Windows 9xでは、x86プロセッサの特権リングを使用して、低レベルなカーネル コードとアプリケーション コードを分離した。従来のWindows 3.xと比較すると、コンポーネント化やレイヤ化はだいぶ進められたが、完全と言えるレベルではない。

Intel x86の特権リングを利用して、システム処理コードとアプリケーションを分離

　Intel 386プロセッサでは、より安全性の高いシステムを実現するために、0〜3までの4段階の特権レベル（privilege level）を設け、これらの特権レベルに応じて、プログラムが実行できる処理に差が付けられている。特権レベルの数値は、小さいほど制限が緩く（特権レベルが高く）、大きいほど制限が強い（特権レベルが低い）。特権レベルのこの様子は、最も高い0を中心として、順にそれよりも低い特権レベルをその外周にリング状に表現できることから、特権リング（privilege ring）と呼ばれることもある。つまりリング0（特権レベル0）では、何の制限を受けることもなく、すべてのプロセッサ命令を自由に実行でき、またページ テーブルなどのクリティカルなデータに対するアクセスが許される。これに対しリング3（特権レベル3）では、システムにとって重大な影響を及ぼすような命令の実行が制限され、クリティカルなデータへのアクセスが制限される。

　Windows 9xでは、Intel 386のこの特権レベル機能を利用し、仮想マシン マネージャ（後述）やファイル システム、デバイス ドライバやメモリ管理、プロセス管理などの低レベルなシステムの処理をリング0で、その他のWindowsシステム コア（図のKernel、User、GDI）やWindowsアプリケーションをリング3で実行するようになっている。こうして、リング3で実行されるWindowsアプリケーションは、システムの重要なデータにアクセスしたり、リング3で実行されている他のWindowsアプリケーションのメモリ空間をアクセスしたりすることが禁止される。

VMこそがWindows 9xの心臓部

　オペレーティング システムとしてのWindows 9xの心臓部はVM（Virtual Machine：仮想マシン）である。実際、Windows 9xのほとんどの機能はこのVMによって実現されている。VMは、Intel 386からサポートされるようになったプロセッサの機能で、名前が示すとおり、マイクロプロセッサが仮想的な「コンピュータ」を構成できるようにしたものだ。これにより、あるVMの中で実行されたソフトウェアから見ると、あたかもそれが独立した1つのコンピュータのように見えるようになる。こうしてソフトウェアは、あたかもメモリ空間や、ハードウェア アクセスのためのI/O空間を自分だけが占有しているかのように振る舞うことが許される。Windows 9xでは、このVMを駆使することによって、さまざまなWindowsアプリケーションやシステム モジュールをマルチ スレッド／マルチ タスクで実行できるようにしている。

　まずWindows 9xには、図の「Windows 98コア」を始め、すべてのシステム プロセスと、すべてのWindowsアプリケーション（Win16およびWin32アプリケーション）を実行するためのVM（System VM）がある。Windows 9xのネイティブ アプリケーションである32bitのWin32アプリケーションは、このSystem VM内に構成された、それぞれが独立したプロセス空間（メモリ空間）の中で実行される。したがって基本的に各アプリケーション自身は、他のアプリケーションや、システムのメモリ領域を破壊しないことになっている（ただし別稿で詳しく述べるとおり、Windowsシステムのコードを呼び出している最中は別である）。

　これに対し、従来からのWin16アプリケーションは、1つのプロセス アドレス空間内で、複数のWin16アプリケーションが実行される（図「Windows 9xカーネルの構成」）。つまり同時実行されるWin16アプリケーション同士は、1つのメモリ空間を共有しているわけだ。したがってWin16が暴走すると、他のWin16アプリケーションのメモリを破壊する可能性がある。このような構成になったのは、ひとえにWin16アプリケーションの互換性を維持するためだ。残念ながらWin16アプリケーションの中には、複数のアプリケーションが1つのメモリ空間を共有していることを前提として、タスク間通信機能のDDE（Dynamic Data Exchange）が設計されていたり、システムを経由せずにこれらの「共有メモリ」にアクセスする、いわゆる「行儀の悪いアプリケーション」が存在していたからだ（ただし次項で述べるように、Windows NTでは、各Win16アプリケーションを独立したVM内部で実行できるようにされた）。

　Win16／Win32アプリケーションとは異なり、MS-DOSアプリケーションは、それぞれに独立したVMが割り当てられ、Intel 386の仮想8086モード（またはプロテクト モード）でプログラムが実行される（図「Windows 9xカーネルの構成」）。

　これらのVMは、リング0コンポーネントのVMM（Virtual Machine Manager）によって生成され、管理される（VMMの詳細はすぐ次で述べる）。

ファイルI/OサービスはWindows 95で初めて搭載

　伝統的に、Windows 9xのシステム コアには、User、GDI、Kernelという3つのモジュールがある。これらはそれぞれ、ウィンドウ管理やメニュー管理などのユーザー インターフェイスにまつわるサービスを提供するモジュール、グラフィックス描画サービスを提供するモジュール、メモリ管理やプロセス管理などを提供するモジュールである。Windows 3.xまでは、ファイルI/Oのためのシステム インターフェイスがWindowsシステムとしては用意されておらず、リアルモードで実行されているMS-DOSのそれを利用しなければならないなど、Windowsアプリケーションに対して必要十分なサービスを提供していなかったが、Windows 95からは、ファイルI/Oを含め、基本的にすべてのアプリケーション インターフェイスがWindowsによって提供されるようになった（Windows 3.xの詳細については、コラム「Windowsの歴史、メモリの歴史」を参照）。

　またこのWindows 95からは、アプリケーション インターフェイスの32bit化が行われ、基本的にWindows NT（Windows 2000）と同じWin32インターフェイスが提供されるようになった。これによりWin32アプリケーションは、Windows 9xとWindows NTの双方で実行が可能になった。

　ただし表面的なインターフェイスは32bit化されたものの、特に過去との互換性を重視するWindows 95では、完全な32bit化がなされたのはKernelのみで、UserやGDIでは16bit時代のシステム コアがそのまま流用され、それに表面的な32bitのカプセルがかぶせられた。ソフトウェア設計の経験がある読者ならお分かりと思うが、システム ソフトウェアでは、バグも仕様の一部として上位ソフトウェアが設計されたり、本来は公開されていない隠し機能がこっそり使われたりするため、たとえそれが正しいバグ修正であっても、変更を加えると互換性上は不都合を生じるという場合がある。よくも悪くも、広く普及したWindows 3.xには、非常に多くのWin16アプリケーションが存在していた。Windows 9xでは、これらのとの互換性を最大限に守る必要から、このような構成になったというわけだ。

2つのマルチタスク方式

　前述のとおり、リング0コンポーネントのVMMは、Windows 9xシステムを構成するさまざまなVMや、その中で動作するプロセス／スレッドを生成したり、管理したりするものだ。図「Windows 9xカーネルの構成」に示したとおり、具体的にVMMには、「プロセス スケジューリング」、「メモリ ページング」、「MS-DOSモード サポート」という3つの働きがある。

　プロセス スケジューラは、Windows 9x環境で同時実行される複数のシステム プロセスやWindowsアプリケーションが、互いに衝突することなく処理を同時実行できるように、システムの各種資源の割り当てを行う。ひと口にWindowsアプリケーションといっても、Windows 9xのネイティブ アプリケーションであるWin32と、従来のWin3.1向けのWin16アプリケーションでは、プロセスのスケジューリング方法が異なる。前者はプリエンプティブなマルチタスク（preemptive multitask）、後者はノン プリエンプティブなマルチタスク（non-preemptive multitask）と呼ばれる方式である。

　Windows 3.xまでのWindowsでは、同時実行されるアプリケーションが自発的に制御を解放しないかぎり、他のWindowsアプリケーションだけでなく、Windowsシステムすらも処理を実行できなかった。プリエンプティブ（preemptive）は「先取権」というような意味で、システムが強制力を持ってプロセス スケジューリングを行えないことから、このマルチタスク方式はノンプリエンプティブなマルチタスクと呼ばれたり、すべてのアプリケーションとWindowsシステムが、ごく短い時間で制御を解放するという前提に立つため、協調型マルチタスク（cooperatively multitask）と呼ばれたりした。互換性上の理由から、Windows 9xにおいても、Win16アプリケーション同士の間では、このノンプリエンプティブなマルチタスク方式が採られる（つまり、いつまでも制御を返さないWin16アプリケーションが存在すると、他のWin16アプリケーションは処理を進められない）。

　一方Windows 95では、32bit対応とともにWindowsシステムによるプロセス スケジューリング方式が改良され、Windows NT（Windows 2000）と同様のスレッド単位によるスケジューリングと、プリエンプティブなマルチタスクが可能にされた。この方式では、アプリケーションの自発的な制御の解放に依存することなく、Windowsシステムが強制力を持ってあるプロセスから制御を奪い、これを他のプロセスに割り当てることができる。Win32アプリケーションについては、このマルチタスク方式が採られる。

　なお、Windows 9xとWindows 2000のプロセス管理については、独立した節を設けて詳細を解説する予定である。

仮想メモリシステムを実現するメモリ ページャ

　Windows 9xでは、オンデマンド ページングと呼ばれる仮想メモリ方式が採用され、これによって各アプリケーションには、それぞれ独立した32bitのフラットな仮想メモリ空間が与えられるようになっている。具体的にWindows 9xは、Intel 386以上のプロセッサで提供されるページング機能を利用して、システムに搭載された物理メモリを4Kbytes単位のページに分け、これを各プロセスの仮想アドレス空間に必要に応じてマップすることでフラットなメモリ空間を実現している。このメモリ ページングを制御するのが図「Windows 9xカーネルの構成」のメモリ ページャの役割である。

　MS-DOSやWindows 3.xまでの16bit Windowsでは、Intelプロセッサのセグメント アーキテクチャに従ってメモリを管理していた。このセグメント アーキテクチャは、16bitのセグメント アドレス（プロテクト モードでは、「セグメント セレクタ」と呼ばれ、少々扱いが異なる）と16bitのオフセットを組み合わせることで物理メモリをアドレッシングする方式である。オフセット アドレスが16bit（0000〜FFFFh）であることから、1つのセグメント サイズは64Kbytesで、この64Kbytesのセグメント バウンダリを超えてメモリをアクセスするには、オフセットだけでなく、セグメント アドレスを変更しなければならなかった（セグメント アーキテクチャの詳細については、別稿のコラム「Windowsの歴史、メモリの歴史」を参照）。従来のWin16アプリケーションとの互換性を維持するため、Windows 9xのWin16サブシステムでは、このセグメント方式のメモリ モデルをエミュレートしている。

　32bit対応がなされたWindows 9xでは、ネイティブのWin32アプリケーションは、このように煩雑なセグメント アーキテクチャによることなく、32bitの（4Gbytes）のメモリ空間をフラットにアクセスできるようになった。しかし現実には、Windows 9xシステムのさまざまなところに、16bitのセグメント アーキテクチャ時代の制限が残されている。これらの詳細についても、独立した節も設けて解説する予定だ。

ハードウェアへの排他アクセスなどを可能にするMS-DOSプロテクトモード インターフェイス

　図「Windows 9xカーネルの構成」に示したとおり、MS-DOSアプリケーションには、それぞれ独立したVM（DOS VM）が割り当てられ、通常は他のWindowsアプリケーション（Win32およびWin16アプリケーション）と同時実行することが可能である。しかし一部のMS-DOSアプリケーションの中には、ハードウェアに対して排他的なアクセスを必要とするようなものがある。この典型的な例としては、ゲーム プログラムなどがあるだろう。このようなプログラムを実行可能にするため、Windows 9xのVMMは、ハードウェアに対する排他的なアクセスを可能にするMS-DOSモードと呼ばれる実行環境を提供できるようになっている。これを可能にするのが図の「MS-DOSプロテクトモード インターフェイス」である。

　MS-DOSモードでDOSアプリケーションが実行されると、Windows 9xの他のプロセスに影響されることなく、このプログラムが排他的に各種のシステム資源にアクセスできるようになる。ただしその代償として、このDOSアプリケーションが排他アクセスを解除するまで、他のプロセスの実行は保留になるので、全体的なシステム性能を低下させる要因になる危険性が高い。したがって通常は、必要がある場合にのみMS-DOSモード設定を行うべきだ。

MS-DOSモードでDOSアプリケーションを起動したところ

Windows 9xのMS-DOSモードでは、DOSアプリケーションが排他的に各種のシステム資源にアクセスできるようになる。ただしその間、他のプロセスの実行は基本的に保留になるので、全体的なシステム性能を低下させる要因になる危険性が高い。画面はその警告を示すもの。

　MS-DOSモードでDOSアプリケーションを実行したければ、Windows 9xのエクスプローラで目的のDOSアプリケーションを右クリックし、［プロパティ］メニューから表示されるプロパティ ダイアログの［プログラム］タブで設定を行う。ここで［詳細設定］ボタンをクリックし、表示されるダイアログの［MS-DOSモード］チェック ボックスをオンにすれば、以後はそのプログラムをMS-DOSモードで起動できるようになる。

MS-DOSモードの設定

MS-DOSモードでDOSアプリケーションを実行するには、DOSアプリケーションのプロパティ ダイアログの［プログラム］タブ−［詳細設定］ボタンからこのダイアログを表示させる。ここで［MS-DOSモード］チェック ボックスをオンにする。

MS-DOSモードでプログラムを実行するには、このチェックボックスをオンにする。

IFS（Installable File System）

　Windows Ver.3.1からWindows 95へのバージョンアップにあたり、最も大きなシステム サービスの強化となったのがファイルI/Oである。Windows 3.1までのWindowsアプリケーションは、リアルモードのMS-DOSのファンクション コールを使ってファイルの読み書きを行うほかなかった（ただしディスク キャッシュとスワップ ファイルの2つについては、性能上の理由から、プロテクト モードから直接ディスクI/Oを行えるようにWindows 3.1で改良された）。Windowsのアプリケーション プログラマから見れば、チープなMS-DOSのファイルI/Oファンクション コールをいつまでも使い続けなければならないのは大きな不満だった。またこの当時は、CD-ROMやネットワークといった新しい情報ストレージが急速に普及しつつあり、これらをローカル ディスクと変わらない方法でアクセスできることへのニーズが高まっていた（Windows 3.1までは、リアルモードに常駐されたドライバを経由して、それぞれに異なる手続きを踏んでこれらのストレージにアクセスする必要があった）。

　MS-DOSを必要としない、一人前のOSとして脱皮したWindows 95において、マイクロソフトがファイルI/Oサブシステムとして設計したものが「IFS（Installable File System）」である。図「Windows9xカーネルの構成」から分かるとおり、上位ソフトウェアから見えるのはIFSマネージャと呼ばれるインターフェイスで、この下にハードディスクやCD-ROM、ネットワーク用のファイル システム コンポーネントが用意されている（これらはファイルシステム ドライバと呼ばれる）。つまり、ファイル システム ドライバを用意すれば、上位ソフトウェアからは透過的に（通常のディスク ファイルへのアクセスと同じ手順で）、さまざまなストレージにアクセスできるようになっている。ストレージごとに異なる物理的な違いを吸収して、ファイルシステム ドライバとの間を取り持つのが「ブロックI/Oサブシステム」だ。

デバイス ドライバ開発を容易にしたユニバーサル ドライバ

　Windowsが普及した大きな理由の1つは、それがハードウェアの抽象化を進めてくれたことである。たとえばMS-DOS時代のワードプロセッサには、さまざまなプリンタ用のデバイスドライバが添付されていた。つまり、アプリケーションがプリンタを直接制御しなければならなかったわけだ。ご存じのとおり、現在のPC/AT互換機市場を成功に導いた背景には、公開された仕様に基づき、さまざまなPCメーカーや周辺機器メーカーが激しく競争して切磋琢磨し、より優れた製品の開発を進めてきたということがある。これはすばらしいことだが、アプリケーションによって、使える周辺機器が変わる（提供されるデバイス ドライバが変わる）のではユーザーはたまらない。これに対しWindowsでは、各ハードウェアの違いをデバイス ドライバと呼ばれる小さなソフトウェアで吸収できるようにした。

　しかしWindows 3.x当時のデバイス ドライバ プログラマは、マイクロソフトが開発キットとして提供してくれるサンプル ソース コードを参考にしながら、基本的にほとんどの機能を1から実装しなければならなかった（この当時のドライバは、すべてが一体化しているので、モノリシック（monolithic）ドライバと呼ばれる）。このため当時は、新しいハードウェアに対応するデバイス ドライバがなかなか提供されなかったり、たとえ提供されたとしても、デバイス ドライバ プログラマの力量によって、安定性や性能に大きな違いがあったりという問題があった。

　これに対しマイクロソフトが提供したソリューションがユニバーサル ドライバとミニ ドライバのしくみである。

ユニバーサル ドライバ アーキテクチャ

Windows 9xからは、プリンタやディスプレイなど、デバイスのクラスごとに共通する処理などをユニバーサル ドライバとして従来のデバイス ドライバから切り離し、デバイス ドライバ プログラマが、特定のデバイスに依存した部分だけに注力できるようにした。

　このようにWindows 9xでは、プリンタやディスプレイ、モデムなどといったデバイスの種類（デバイス クラス）ごとに、共通する処理部分を従来のデバイス ドライバから外部化してユニバーサル ドライバとし、残りをミニ ドライバとした。これによりデバイス ドライバ プログラマは、個別のハードウェアごとに異なるミニドライバの部分だけをコーディングすればよい。これによりWindowsのドライバ サポートは急速に充実することとなった。

WDM（Win32 Driver Model）

　デバイス ドライバにまつわるマイクロソフトのもう1つの悩みのタネは、Windows 9xとWindows NT（Windows 2000）で、デバイス ドライバの仕様が異なることだ。Windows 2000が登場したことにより、だいぶ状況は変わりつつあるとはいえ、まだまだデバイス サポートの点では、Windows 2000はWindows 9xに及ばないのが実情である。

　このためマイクロソフトは、Windows 9xでも、Windows NT（Windows 2000）でも共通して使用可能なデバイス ドライバ（バイナリ互換性のあるデバイス ドライバ）を設計できるように、WDM（Win32 Driver Model）と呼ばれる新たなドライバ モデルを提唱した。このWDMをひと口で言えば、デバイス ドライバのレイヤ構成をさらに細分化し、USBやIEEE 1394などの新しいデバイスに対応可能にすると同時に、Windows NTとのデバイス ドライバの共通化を進めようとするものだ。

しかし現実には、Windows 9xとWindows NT（Windows 2000）でのドライバのバイナリ互換性を達成しようというWDMの大きな目標は失われ、ソース互換を目標とすることに改められた（これに伴って、WDMは「Windows」Driver Modelの略と変更された）。2000年後半には、Windows 98 SEの後継となるWindows Meが登場する予定だが、マイクロソフトは、これをWindows 9xコアを持つ最後のOSと位置づけており、WDMやドライバ互換の話題には積極的に触れようとはしていない。従来からの周辺機器をサポートし続けるために、Windows 9xコアを持つWindows Meは発表するが、周辺機器メーカーにはWindows 2000および次バージョンのWhistlerに向けたドライバ開発を進めてもらいたいというのが、マイクロソフトの正直な気持ちかもしれない。WDMの詳細については、別稿の「Windows 2000のデバイス ドライバを探る」を参照のこと。

	関連記事（Windows Server Insider）
		Insider's Eye：Windows Meの全貌
		Insider's Eye：ベールを脱いだWhistler
		Insider's Eye：Windows 2000のデバイス ドライバを探る

INDEX
	［特集］Windows 9x or Windows 2000？
	1．イントロダクション
	2．Windows 9xカーネルの概要
	コラム：Windows歴史、メモリの歴史 （1）
	コラム：Windows歴史、メモリの歴史 （2）
	3．Windows 2000カーネルの概要 （1）
	4．Windows 2000カーネルの概要 （2）
	5．プロセス管理の概要
	コラム：Windows 3.xのマルチタスク システム
	6．Windows 9xのプロセス管理メカニズム （1）
	7．Windows 9xのプロセス管理メカニズム （2）
	8．Windows 2000のプロセス管理メカニズム （1）
	9．Windows 2000のプロセス管理メカニズム （2）

　

特集

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