特集Windows 9x or Windows 2000?3.Windows 2000カーネルの概要(1)デジタルアドバンテージ |
|
|
これまでに述べてきたように、Windows 9xのアーキテクチャは、MS-DOSからWindows 1.x、2.x、3.x、Windows 9xという系譜の中で、過去のソフトウェア資産との互換性を最大限に維持しながら、機能拡張を繰り返してきた結果として出来上がったものである。このためWindows 9xの内部には、今もなお16bit時代のDOSが息を潜めているし、Windows 95で新しく導入されたファイル システム関連のモジュール(IFS)は比較的整理されているとはいえ、コア モジュールの1つである仮想マシン マネージャ(VMM)内部のコンポーネント化や、それらの階層化などの整理はあまり進んでいないのが実情である。
これに対しWindows 2000の前身となったWindows NTは、16bit Windowsに代わる次世代32bit OSとして一から設計された。1980年代後半、マイクロソフトは、MS-DOSの次世代を担うOSを開発するために、IBMと共同でOS/2の開発を進めていた。当時はビル・ゲイツ氏を始め、DOSユーザーのほとんども、OS/2が次世代のPC用標準OSとなることを疑わなかった。しかし結果的にマイクロソフトは、その後OS/2の開発から撤退し、独自OSの開発に路線を切り替えることになる(この大きな理由の1つは、マイクロソフトがIBMの官僚的な体質にどうしても馴染めなかったからだと言われている)。こうして開発された32bit OSが現在のWindows 2000のベースとなったWindows NTである(OS/2開発の断念やWindows NTの新規開発など、Windows OSの開発裏話に興味のある方は『ビル・ゲイツの罪と罰』という書籍を参照のこと)。
Windows NTの開発にあたりビル・ゲイツ氏は、かつてミニ コンピュータとして広く普及したVAX-11用のOSを開発した実績を持つデビット・カトラー(David Cutler)氏と、彼の周辺にいた優れたプログラマたちを当時のデジタル・イクイップメント社(DEC社)から招き入れた。こうしてWindows NTには、ミニ コンピュータ用OSの開発で培われたノウハウに加え、OS開発の最新のテクノロジが組み込まれることとなった。
それではさっそく、Windows NT(Windows 2000)のアーキテクチャを覗いてみることにしよう。なお以下の説明では、特にバージョンを明記する必要がなく、Windows NTとWindows 2000に共通してあてはまる事項については「Windows 2000」と表記している。
目標はWindows 9xの弱点を根本的に克服すること
すでにWindows 2000(Windows NT)の大まかな設計目標についてはご紹介したとおりだが、これらをさらに具体的に言うと次のようになる。
目標 | 内容 |
真の32bit環境 | システムのあらゆる部分がリエントラント(再入可能)に設計され、完全なマルチタスクOSであること |
マルチプラットフォーム対応 | Intel x86プロセッサ搭載システムだけでなく、さまざまなハードウェアに対応可能なOSであること |
マルチプロセッサ対応 | シングル プロセッサ システムだけでなく、マルチプロセッサ システムにも対応し、スケーラビリティに優れたオペレーション環境を提供可能であること |
過去の資産との互換性 | 16bitのMS-DOSアプリケーション、Windows 3.xアプリケーションとの互換性を最大限維持すること |
セキュリティ機能の強化 | ミッション クリティカルな処理を安心して実行可能なセキュリティ メカニズムを備えること |
マルチランゲージ サポート | 特定の言語に依存せず、さまざまな言語に容易に対応可能であること |
Windows 2000の設計目標 |
これらWindows 2000での機能強化点は、すなわち、Windows 9xの弱点でもある。詳細は各分野別に節を分けて解説する予定だが、たとえばWindows 9xには、今なお16bit時代のリエントラントではないコードが一部に残されている。Windows 9xはIntel x86アーキテクチャに強く依存しており、これ以外のプロセッサを搭載するシステム上に移植することは事実上不可能である。Windows 9xはマルチプロセッサ システム対応ではない。したがってマルチプロセッサ システム上でWindows 9xを実行しても、システムの能力を引き出すことはできない。Windows 9xには、実質的にセキュリティ メカニズムは備えられていない。システムの起動時にログオン ダイアログが表示されるが、ここでEscキーを押せば、ゲスト扱いでシステムを使うことができる。
モノリシック モデル vs. レイヤ モデル
次の図「Windows 2000カーネルの構成」に、Windows 2000カーネルの内部構成を示した。以下では、この図を基にして、Windows 2000の内部を詳しく見ていくことにしよう。
Windows 2000カーネルの構成 |
Windows 9xのようなモノリシック モデルではなく、Windows 2000では、徹底したシステムのモジュール化とそれらの階層化が進められた。図中で下側半分(カーネル モード側)に表記されている各モジュールの上下関係は、ほぼそれらの階層関係を表現していると考えてよい。 |
前の節で説明したとおり、Windows 9xの核心はVMであり、メモリ管理やプロセス管理といったOSの基本機能を実装したものがVMM(Virtual Machine Manager)であった。この説明の際に用いた図では、「メモリ ページャ」と「プロセス スケジューラ」を上下に配置したが、これは図を描く都合でこのように配置しただけであって、両者が階層的な関係にあるわけではない。実際Windows 9xのVMM内部は、Windowsのバージョン アップに従って、過去との互換性を維持しながら新しい機能性を追加するために、モジュール間が複雑に依存しあっている部分が少なくない。
このように、OS内部の多数の要素が複雑に依存し合うモデルは、「モノリシック モデル(monolithic model。『monolithic』は『一枚岩的な』という意味)」と呼ばれ、古くは汎用大型計算機に実装されるOSなどがこの形式をとっていた。モノリシック モデルの最大の欠点は、複数の要素が依存しあっているために、システムに新しい機能性を追加するのが困難なこと(それによって変更を加えなければならない要素が多岐に渡ってしまうこと)、また複数の要素が共通のシステム メモリ領域を使用するため、万一トラブルが発生すると、システム全体に影響が及んでしまうことである。
これに対し、「マルチプラットフォーム対応」や「マルチプロセッサ」対応など、柔軟なスケーラビリティを実現しようとするWindows 2000では、徹底したシステムのモジュール化とそれらの階層化が進められた。図「Windows 2000カーネルの構成」の中で、下側半分(カーネル モード側)に表記されている各モジュールの上下関係は、ほぼそれらの階層関係を表現していると考えてよい。
このようにWindows 2000では、システムの徹底的なモジュール化と階層化が図られており、各モジュールは、それよりも下位にあるモジュールのインターフェイスを使って処理を行うようになっている。このため、他のモジュールに影響を与えることなく、新しいモジュールを追加したり、一部のモジュールを置き換えたりすることが可能である。
なおWindows 2000を構成するモジュール同士のインターフェイスには、オブジェクト指向の技術が用いられており、各モジュールは、他のモジュールが管理するデータ構造などにダイレクトにアクセスするのではなく、それを管理するモジュールが用意するインターフェイスを経由してデータ構造にアクセスするようになっている(ただしWindows 2000は、クラス継承やポリモルフィズム(多態)などといった本格的なオブジェクト指向の機能は用意されない。あくまでも、モジュール間インターフェイスにオブジェクト指向的な技術が利用されているだけである)。
ユーザー モードとカーネル モード
図「Windows 2000カーネルの構成」から分かるとおり、内部は大きく2つに分かれており、このうちアプリケーションなどが実行される上位側は「ユーザー モード」で、カーネル コードなどの下位側は「カーネル モード」でそれぞれ実行されている。Windows 9xでも同様の構成だったが、こちらは上位側が「リング3」、下位側が「リング0」と表記されていたことをご記憶だろう。
Windows 2000においても、Intel x86プロセッサを搭載するシステム上では、「ユーザー モード」として「リング3」が、「カーネル モード」として「リング0」が使用される。Windows 2000でこのような回りくどい用語を使うのは、Intel x86プロセッサ以外のシステムも念頭に置いているためである。今でこそ、Windows 2000が正式サポートするプロセッサ アーキテクチャはIntel x86とDEC Alphaだけになってしまったが、初期バージョンであるWindows NT 3.1ではMIPS Rシリーズがサポートされていたし、後にPower PCサポートが追加された(残念ながら、広く普及するに至らなかったこれらのプロセッサ サポートはその後廃止された)。Intel x86プロセッサでは、リング0〜リング3の4つの特権モードが利用可能だが、Windows 2000で利用される特権モードは2つだけである。この理由は、Inte x86以外のほとんどのRISCプロセッサが2つの特権モードしかサポートしていなかったし、それ以上は必要なかったからだ。
図から分かるとおり、すべてのアプリケーション(Win32、Win16、DOSアプリケーション)や各種サービス、システム プロセス、Win32サブシステム(いずれも詳細は後述)などはユーザー モードで実行されるため、これらのプログラムは、呼び出し可能なシステム インターフェイスや、アクセス可能なデータなどが制限される。一方、Windows 2000のコア システム コードはカーネル モードで実行される。カーネル モードで実行されるプログラムに対しては、いかなる保護機能も働くことなく、これらはシステム資源に自由にアクセスすることが可能だ。
サブシステム
Windows 2000では、ネイティブなアプリケーション(Win32アプリケーション)だけでなく、OS/2アプリケーションやPOSIXアプリケーションなど、さまざまな環境との互換性を実現するために、アプリケーション環境を「環境サブシステム(environmental subsystem)」として独立させ、複数のアプリケーション環境を1つのシステム内に同居できるようにした。つまりWindows 2000では、ネイティブのWin32アプリケーションや、以前のWin16アプリケーションはもとより、OS/2アプリケーションやPOSIXアプリケーションを同時に実行することができる。具体的には、Win32サブシステム、OS/2サブシステム、POSIXサブシステムが環境サブシステムとして提供されている。
これら環境サブシステムとアプリケーションは、それぞれサーバとクライアントの関係にある。Windows 2000上で実行されるアプリケーションは、これらサブシステムが提供するシステムAPI(Application Program Interface)を通してカーネル モードのモジュールを呼び出す。アプリケーションが直接カーネル モードのコードを実行することは許可されていない。このため万一アプリケーションにバグがあって、不正なAPI呼び出しが行われたとしても、それはユーザー モードにあるサブシステム レベルでトラップし、カーネル モードにまで影響を及ぼさないようにできるようになっている。
■Win32サブシステム
他の環境サブシステムとは異なり、Windows 2000の実行には不可欠な環境サブシステムである。OS/2サブシステムやPOSIXサブシステムは必要に応じて(これらのサブシステムを使用するアプリケーションが実行されたときだけ)起動されるようになっているが、このWin32サブシステムはWindows
2000が実行されている間ずっと実行されている。Win32サブシステムは、キーボードやマウス入力、ディスプレイ出力などを管理しており、システムの稼働に欠かせない存在だからである。実際、OS/2サブシステムやPOSIXサブシステムは、キーボード/マウス入力やディスプレイ表示を制御するために、内部からWin32サブシステムを呼び出している。
■OS/2サブシステム
特殊な古い業務アプリケーションを実行するのでもなければ、OS/2サブシステムはほとんどのユーザーにとって不要なものだろう。これはOS/2 Ver.1.2の16bit
キャラクタモード アプリケーションとの互換環境を実現するものであり、現在販売されているOS/2 Warp(原稿執筆時点での最新版はOS/2 Warp
4)用のネイティブ アプリケーションは実行できない。またWindows 2000のOS/2サブシステムは、Intel x86プロセッサ システム上でのみ利用可能である(DEC
Alphaシステム上では利用不可)。
■POSIXサブシステム
POSIX(Portable Operating System Interface
for UNIX)は、IEEEによるUNIXの標準アプリケーション インターフェイス仕様である。1980年代の中盤から後半にかけて、米国政府機関のコンピュータ
ステムの導入要件(National Institute of Standards and TechnologyのFIPS:Federal Information
Processing Standards)として、このPOSIX準拠であることが策定されたため、設計当初から、Windows NTにはPOSIX互換機能を組み込むことが決定された。
一般的なユーザーがこのサブシステムのお世話になるのは、Windows 2000に移植されたUNIX上のコマンド ライン ツールなどを実行する場合だろう。このWindows 2000のPOSIXサブシステムでサポートされるのはキャラクタ ベースのコマンドライン プログラムだけで、X Window Systemなどのグラフィカル アプリケーションは実行できない。
■セキュリティ サブシステム
系統的なセキュリティ機能を持たないWindows 9xとは異なり、Windows 2000環境では、ファイルやプリンタを始めとするシステム資源へのアクセスが常に監視されており、アクセス権を持たないユーザー(やアプリケーション)がそれらの資源にアクセスすることを禁止できるようになっている。米国の政府機関は、C2レベル
セキュリティと呼ばれる基準を満たしたシステムでなければ導入不可だと規定した。このような背景からWindows NTでは、開発当初からシステムとして抜本的・系統的なセキュリティ
メカニズムが組み込まれることになった。これを可能にするために、カーネルに対してさまざまなセキュリティ サービスを提供するのがセキュリティ サブシステムである。
セキュリティ サブシステムは、実際にはいくつかのコンポーネントで構成されており、具体的には、ローカル システムのセキュリティに関するすべての情報を制御するLSA(Local Security Authority)、ドメイン環境でのログオン処理を司るNet Logonサービス、ユーザー アカウントやグループ アカウント情報を管理するSAM(Security Accounts Manager)サービス、インターネットなどのセキュリティ レベルの低いチャネルを使って安全な認証を行うためのSSL(Secure Socket Layer)プロトコル、認証プロトコルであるKerberos V5やNTLM(Kerberos未使用時の認証プロトコル)が含まれている。Windows 2000では、Kerberos認証機能やファイルの暗号化機能などが新たに追加されたが、これらをシステムとして支援しているのがセキュリティ サブシステムである。
システム プロセス
システム プロセスは、ユーザー モードで実行されるシステム サービスである。これらには、Windows 2000システムの起動時にシステムの初期化などを実行するセッション マネージャ、Ctrl+Alt+Delキーが押された場合のログオン要求を処理するWinlogon、サービス プロセスの開始や停止などを司るサービス コントローラなどがある。
サービス
サービス プログラムは、基本的にGUIを持たず、通常はシステムの起動とともに開始され、システムがシャットダウンされるまでずっと見えないところで動き続けている。これはUNIXで言えばデーモン プロセスのようなものだ。お使いのWindows 2000システムでどのようなサービス プロセスが動いているかを知りたければ、コントロール パネルの[管理ツール]フォルダにある[サービス]アプレットを起動してみればよい。下の画面に示したように、この[サービス]アプレットでは、現在システムにインストールされているサービス プログラムが一覧され、それらの現在の状態(実行が開始されているかどうか)、システム起動時の取り扱い(自動的に開始するか、マニュアルで指示されるまで開始しないか)などが一覧表示される。
コントロール パネルの[サービス]アプレット | |||||||||
この[サービス]アプレットでは、現在システムにインストールされているサービス
プログラムがリストアップされ、それぞれのプログラムが現在開始されているかや、システム起動時の取り扱い方法(自動起動するかなど)が表示される。必要なら、ここで適当なサービス
プログラムを選択して、実行を停止したり、システム起動時の取り扱い方法を変更したりすることができる。 |
|||||||||
|
Windows 2000のカーネル コンポーネントのうち、いくつかはこのサービス プログラムとして実装されているものがある。このうち代表的なものが、図中に示した「イベントロガー」(イベント ログの記録と表示を行う)や「アラータ」(ユーザーやコンピュータに対する管理警告の通知)、「RPC(Remote Procedure Call)」(リモート プログラム呼び出し)などである。これ以外にも、プラグ アンド プレイ モニタなどのハードウェア サポート コンポーネントや、各種ネットワーク用クライアント モジュールなど(DHCPクライアントなど)さまざまなものがサービスとして実装されている。
アプリケーション環境
Windows 2000では、ネイティブ アプリケーションである32bitのWin32アプリケーションに加え、Windows 3.x用の16bitアプリケーション(Win16アプリケーション)とMS-DOSアプリケーションを同時に実行することができる。このうちキャラクタ ベースのDOSアプリケーションは、「コマンド プロンプト」と呼ばれる専用のウィンドウ内で実行されることになるが、Win32アプリケーションとWin16アプリケーションは、どちらもグラフィカルなウィンドウ アプリケーションとして透過的に実行されるので、見た目だけでユーザーがそれらを区別することは不可能だ。しかしシステム内部では、Win32アプリケーションとWin16アプリケーションの取り扱いはまったく異なっている。
■Win32アプリケーション環境
Win32アプリケーションは、それぞれに独自のプロセス空間とメモリ空間が割り当てられ、プリエンプティブに実行される。したがって明示的に共有メモリの使用を宣言しないかぎり、あるアプリケーションが、他のアプリケーションのメモリ空間を破壊する可能性はゼロである(詳しくは後述するが、Windows
9xでは、複数のアプリケーションとシステムで共有されるメモリ領域が存在している)。
またタスク スケジューリングは、ごく短いタイム スライスに従って、Windows 2000カーネルが完全に制御するプリエンプティブ マルチタスクなので、アプリケーションが何をしていようと(極端な話、無限ループに入っていようと)、他のアプリケーションが動けなくなってしまうということはない。
■Win16アプリケーション環境
これに対しWin16アプリケーションが起動されると、Windows 2000はNTVDM(NT Virtual DOS Machine)と呼ばれる特別なプロセスを生成し、この中でWin16アプリケーションの互換環境を実現する。このときNTVDMの中ではまず、WOW(Win16
On Win32)と呼ばれるコンポーネントと、ハートビート スレッド(heartbeat thread)がそれぞれスレッドとして開始される。WOWは、32bit
Windows環境の上で16bit Windows互換環境をエミューレートするためのソフトウェアである。一方のハートビート スレッドは、NTVDMの内部でタイマ割り込みをシミュレートするためのスレッドだ。そして起動されたWin16アプリケーションは、第3のスレッドとして実行されることになる。
ここでさらにもう1つのWin16アプリケーションを起動すると、今生成されたNTVDMの中に新たなスレッドが生成され、1つ目のWin16アプリケーションと同じメモリ空間内で実行される。この後、Win16アプリケーションが起動されりたびに、NTVDM内にスレッドが生成され、実行される。このようにWindows 2000では、個々のWin16アプリケーションに独立したスレッドが割り当てられるのだが、だからといってこれらがプリエンプティブなマルチタスクで実行されるわけではなく、あくまでWindows 3.xと同じWindowsメッセージベースのノンプリエンプティブなマルチタスクによってタスク スケジューリングがなされる。つまり、あるWin16アプリケーションが実行されているときには、他のWin16アプリケーション(のスレッド)はブロックされる。この理由は、Win16アプリケーションでは、システムがノンプリエンプティブなマルチタスク環境であることを前提として(あるWin16アプリケーションが制御を返すまで、別のアプリケーションは実行されないことを前提として)、DDE(Dynamic Data Exchange)などのタスク間通信が実装されているからだ。このため、いずれかのWin16アプリケーションが何らかの理由から正しく制御を解放しなくなると(プログラムがロックするなど)、他のWin16アプリケーションも実行が停止してしまう(これはあくまでNTVDM内部で実行されたWin16アプリケーション同士の話。当該NTVDMの外部にあるWin32アプリケーションやDOSアプリケーションは影響を受けない)。
このように強い制限がある代わり、従来の環境がかなり忠実に再現されているために、前出のDDEを使用するアプリケーションを始め、公開されたWindows APIを使わず、特定のメモリ領域を直接操作するなどの、いわゆる「行儀の悪いアプリケーション」も正しく実行できる可能性がある(ただし、ハードウェアを直接制御するようなものは不可)。
当初、すべてのWin16アプリケーションは1つのNTVDMでのみ実行可能だったが、Windows NT 3.5からは、必要に応じてWin16アプリケーションに独立したNTVDMを割り当てられるように改良された。これにより、NTVDM同士はプリエンプティブにスケジューリングされるようになり、また各NTVDMは独立したメモリ空間を持つので、Win16アプリケーションが不正なメモリアクセスを行っても、異なるNTVDM内のWin16アプリケーションには影響が及ばなくなった(代わりに、メモリ空間を共有していることを前提としてタスク間通信を行うDDEなどは正しく機能しなくなる)。
独立したNTVDMでWin16アプリケーションを実行するには、そのアプリケーションを起動するためのショートカットを作成し、ショートカットのプロパティで設定を行う。
Win16アプリケーションのショートカットのプロパティ | |||
独立したNTVDM内でWin16アプリケーションを実行したければ、アプリケーションのショートカットを作成し、プロパティ ダイアログで[別メモリ領域で実行する]をチェックする。 | |||
|
実行されているWin16アプリケーションとNTVDMの関係は、タスクマネージャの[プロセス]タブで確認することができる([オプション]メニューの[16ビット タスクの表示]が選択されているとき)。
タスクマネージャの[プロセス]タブ | ||||||
画面はWin16アプリケーションであるPaint Shop 3(PSP3)を合計4つ起動したところ。このうち3つは同じNTVDM内で実行され、1つは独立したNTVDM内で実行されている。タスクマネージャの[プロセス]タブでは、NTVDM内のタスクがこのようにインデントされて表示されるようになっている。 | ||||||
|
■DOSアプリケーション環境
Win16では、1つのNTVDM内で複数のアプリケーションが実行されるのに対し、DOSアプリケーションについては、必ず独立したNTVDMが起動され、この内部でDOSアプリケーションが実行される(起動可能なNTVDMの数に特に制限はない)。したがって複数のDOSアプリケーションを同時実行した場合でも、それぞれは独立したメモリ空間で実行され、かつそれぞれはプリエンプティブなマルチタスクによってスケジューリングされる。
DOSアプリケーションを実行するNTVDM内では、DOSアプリケーション用のスレッドとタイマ割り込みをシミュレートするハート ビート スレッド、コンソールI/Oを処理するコンソール スレッドの3つのスレッドが実行される。
DOS NTVDM内では、ROM BIOSの割り込みサービス ルーチンとMS-DOSのINT 21サービス ルーチンがMS-DOSエミュレーション モジュールによってエミューレートされ、仮想デバイス ドライバによってディスプレイやキーボードなどのハードウェア デバイスがDOSアプリケーションから制御可能にされる。ただしWindows 2000のDOS環境には、Windows 98のように、MS-DOSアプリケーションがシステムを排他的に使えるようにする「MS-DOSモード」のような機能はない(こんなことを許したら、システムの安全性などとても維持できない)。
またWindows 2000のコマンド プリントプトでは、画面の上部にスクロールアウトした表示内容をロールバックして表示できるようになるなど、あまり表だって宣伝されることはないが、人知れず機能強化が図られている。これらについては、別稿の「連載:Windows
2000コマンドライン徹底活用」が詳しいので参照されたい。
特集 |
- 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をインストールしてみる
|
|