BOOK Preview インサイドMicrosoft Windows 第4版 上 第2章 システムアーキテクチャ 2.1 要求と設計目標 2.2 オペレーティングシステムモデル マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/08/02

本コーナーは、Windowsシステム管理者向けの書籍から、主要なチャプターをそのまま転載し、その内容を紹介するものです。 　今回ご紹介する『インサイドWindows 第4版』は、Windowsオペレーティング・システムの内部を詳細に解説した決定版です。Windowsカーネルの内部について、ここまで詳しく解説した情報はほかにありません。 　著者の1人であるデビット・ソロモン氏は、Windows NTの開発リーダーだったデビット・カトラー氏とは旧知の仲で、本書の前々版（『インサイドWindows NT 第2版』）を執筆するにあたり、Windowsカーネルのソースコードにアクセスする許可をカトラー氏から与えられました。それだけでなく、デビッド・カトラー氏は、本書の一部（プロセス管理の部分）について、技術校閲も担当しています。 　またもう1人の筆者であるマーク・ルシノビッチ氏は、Windowsオペレーティング・システムの機能を縦横に駆使したツール開発者として著名で、前出のカトラー氏も一目置く存在です。「かゆいところに手が届く」彼のツールは、多くのWindowsエンジニアにとって不可欠な存在となっています（フリー・ツールの入手先はこちら：SysInternals）。 　つまり本書は、Windowsコア・システムの開発責任者と、OS解説のエキスパートが、二人三脚で執筆し、Windowsの歴史とともに改版を重ねてきた希有な書籍なのです。今回の第4版では、Windows XPとWindows Server 2003に加えられたカーネルの変更点や、Windowsの64bitサポートなどについて加筆されています。情報システムの設計者やシステム管理者など、作り手や管理者としてWindowsシステムに接する必要があるなら、本書にまとめられた情報が仕事の随所で役立つはずです。 　本稿では、Windowsカーネルの概要を解説した第2章「システムアーキテクチャ」の部分を何回かに分けて転載しています。 　なお、書籍の詳細については書籍情報のページをご覧ください。

ご注意：本記事は、書籍の内容を改訂することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

　私たちは既に、Windowsに関する用語、概念、および各種のツールを理解しています。本章からはいよいよ、Microsoftオペレーティングシステムの設計目標と内部構造を調査する作業を本格的に開始します。本章ではまず、システムのアーキテクチャ概要を把握してしまいます。具体的には、Windowsのキーコンポーネント、キーコンポーネント間の相互作用、キーコンポーネントの動作コンテキストなどを理解します。それでは、最初のWindowsシステムの仕様作成時に考慮された要求と設計目標を、簡単に振り返っておきましょう。

2.1 要求と設計目標

　Windows NTの仕様が定義された1989年当時は、次のような要求が考慮されていました。

• 真の32ビットオペレーティングシステムが必要（プリエンプティブ、再入、仮想メモリ）

• 複数のハードウェアアーキテクチャとプラットフォーム上で動作すること

• 対称型マルチプロセッシングシステムへの柔軟な対応

• 優れた分散コンピューティングプラットフォーム（ネットワーククライアントとサーバー）

• 既存16ビットMS-DOS とWindows 3.1アプリケーションの動作保障

• 政府設定のPOSIX 1003.1基準のクリア

• 政府ならびに業界設定のOSセキュリティ基準のクリア

• Unicodeサポートによるグローバル市場への対応

　このように、当時の要求はたいへん厳しいものです。Windows NTチームは可能な限りの要求を満たすため、プロジェクトの開始時に次のような設計目標を設定しました。

• 優れた拡張性 ― 市場の要求の変化に応じて柔軟に対応できるようなコード

• 優れた移植性 ― 複数のハードウェアアーキテクチャをサポートし、市場の要求に柔軟に対応できるシステム

• 優れた信頼性と強固な堅牢性 ― 内部の不具合や外部からの不正データ入力から自分自身を保護するメカニズムを組み入れる。アプリケーションは、オペレーティングシステムや他のアプリケーションに悪影響を与えないようにする。

• 互換性 ― Windows NTは既存テクノロジを拡張するものであるが、ユーザーインターフェイスとAPIは従来のWindowsとMS-DOSと互換性を維持する。また、UNIX、OS/2、およびNetWareとの相互運用性を高める。

• パフォーマンス ― 他の設計目標に沿っている限り、個々のハードウェアプラットフォーム上で実行速度と応答性を最適化する。

　Windowsの内部構造と動作を調査していく過程ではっきりしますが、当時の設計目標と要求分析はWindowsシステム内部にうまく融合されています。今すぐにでも分析作業を開始したいところですが、その前に、Windowsの全体的な設計モデルを整理し、他のオペレーティングシステムと比較しておきたいと思います。

2.2 オペレーティングシステムモデル

　ほとんどのマルチユーザーオペレーティングシステムでは、アプリケーションはオペレーティングシステムから切り離されています。つまり、オペレーティングシステムのカーネルコードは、プロセッサの特権モード（本書ではカーネルモードと表現）で動作します。このモードで動作するコードは、システムデータとハードウェアへのアクセス権を与えられます。一方、アプリケーションコードは非特権モード（ユーザーモード）で動作し、利用できるインターフェイスセットとシステムデータへのアクセスは制限されます。また、ハードウェアへの直接アクセスは禁止されます。ユーザーモードプログラムがシステムサービスを呼び出すと、プロセッサはその呼び出し要求をトラップし、呼び出し元スレッドをカーネルモードで動作するように切り替えます。システムサービスの処理が終了すると、オペレーティングシステムは呼び出し元スレッドのコンテキストをユーザーモードに切り替え、動作をそのまま継続させます。

　Windowsは、モノリシックなオペレーティングシステムである点では、ほとんどのUNIXと同じです。オペレーティングシステムとデバイスドライバコードの多くは、同じカーネルモードの保護メモリスペースを共有しています。つまり、すべてのオペレーティングシステムコンポーネントとデバイスドライバは、他のオペレーティングシステムコンポーネントが使用しているデータを破壊してしまう危険性を抱えています。

WindowsはマイクロカーネルベースのOSか？ 　WindowsはマイクロカーネルベースのOSであると主張する人がいますが、その主張の「マイクロカーネルベース」の意味があいまいです。従来、マイクロカーネルベースのOSという場合には、メモリマネージャ、プロセスマネージャ、およびI/Oマネージャなどの主要なオペレーティングシステムコンポーネントは、マイクロカーネル提供の低レベルサービスセットの上位層として実装され、それぞれのプライベートアドレススペース内で分離した状態で動作していました。たとえば、マイクロカーネルアーキテクチャの現在の典型的なOSといわれる、カーネギーメロン大学のMachオペレーティングシステムは、スレッドスケジューリング、メッセージパッシング、仮想メモリ、およびデバイスドライバで構成される最小のカーネルとして実装されています。各種API、ファイルシステム、およびネットワーク機能などの他のすべての機能は、ユーザーモードで動作します。ところが、Machの市販製品は、少なくともファイルシステム、ネットワーク機能、およびメモリ管理コードをカーネルモードで動作させています。その理由はきわめて簡単です。純粋なマイクロカーネル仕様は効率面で問題があり、実用的ではないのです。 　Windowsの多くのコードは、カーネルモードで動作します。これは事実ですが、だからといって、真のマイクロカーネルオペレーティングシステムよりクラッシュする頻度が高いといえるでしょうか。結論を言ってしまえば、ノーです。たとえば、オペレーティングシステムのファイルシステムにバグがあり、そのバグが原因でときどきクラッシュが発生するとします。従来のオペレーティングシステムでは、メモリマネージャやファイルシステム内のバグはオペレーティングシステムをクラッシュさせる原因となったことでしょう。真のマイクロカーネルオペレーティングシステムでは、その種のコンポーネントはユーザーモードで動作しますから、理論的には、問題が発生したコンポーネントだけが異常終了することになります。しかし、実際にはそのようにうまく事は運びません。重要なプロセス内に問題が発生した場合、その回復はほぼ不可能なのです。つまり、システム自体がクラッシュしてしまう確率が高い、といえるのです。

　これらのオペレーティングシステムコンポーネントはすべて、問題を抱えたアプリケーションから完全に保護されています。アプリケーションは、オペレーティングシステムの特権コードやデータに直接アクセスすることは許可されません（他のカーネルサービスを呼び出すことは可能ではあっても）。Windowsはこのような保護機能を実装しているため、堅牢で安定したアプリケーションサーバーやワークステーションプラットフォームとして高い評価を受けているのです。しかも、仮想メモリ管理、ファイルI/O、ネットワーキング、ファイルとプリンタの共有などのコアオペレーティングシステムから見た場合、Windowsの動作性能はたいへん優れていると評価されています。

　Windowsのカーネルモードコンポーネントはまた、基本的なオブジェクト指向設計の原則に沿って開発されています。たとえば、各コンポーネントは基本的には他のコンポーネントのデータ構造体にアクセスし、そのデータを操作しません。その代わりに、コンポーネントは公開されているインターフェイスからパラメータを渡し、データ構造体を間接的に操作しています。

　共有システムリソースは確かにオブジェクトで表現されています。しかし、Windowsは完全なオブジェクト指向システムではありません。オペレーティングシステムコードのほとんどは、移植性を考慮してCで記述されています。当時は、Cの開発ツールが豊富に利用できたからです。ご承知のようにCは、データ型のダイナミックバインディング、純粋仮想関数、あるいはクラス継承などといったオブジェクト指向概念を直接サポートしていません。結果的に、WindowsにおけるC的なオブジェクト実装は、特定のオブジェクト指向言語の機能に依存することはありません（かなり影響を受けているのは事実ですが）。

INDEX
	インサイドMicrosoft Windows 第4版 上
	第2章 システムアーキテクチャ
	2.1 要求と設計目標／2.2 オペレーティングシステムモデル
	2.3 アーキテクチャ概要／2.3.1 移植性／2.3.2 対称型マルチプロセッシング
	2.3.3 スケーラビリティ／2.3.4 クライアントとサーバー間の違い／2.3.5 チェックビルド
	2.4 キーシステムコンポーネント／2.4.1 環境サブシステムとサブシステムDLL
	2.4.2 Ntdll.dll／2.4.3 エグゼキュティブ
	2.4.4 カーネル／2.4.5 ハードウェア抽象化層（HAL）／2.4.6 デバイスドライバ
	2.4.7 システムプロセス／まとめ

　

「BOOK Preview」

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