Windows NTのアーキテクチャ

Win32 環境サブシステムは、32 ビット Windows アプリケーションを実行できます。コンソールとテキスト ウィンドウのサポート、シャットダウン、および他のすべての環境サブシステムのハード エラー処理が含まれています。また、MS-DOSおよび16 ビットWindows ( Win16 ) アプリケーションを Windows NT 上で実行できるようにする仮想 DOS マシン(VDM) もサポートしています。専用の MS-DOS VDM があり、独自のアドレス空間で実行され、 MS-DOS 5.0 を実行するIntel 80486をエミュレートします。一方、Win16 プログラムは Win16 VDM で実行されます。デフォルトでは、各プログラムは同じプロセスで実行されるため、同じアドレス空間を使用し、Win16 VDM は各プログラムに実行用のスレッドを割り当てます。ただし、Windows NT では、Win16 プログラムを別の Win16 VDM で実行することもできます。これにより、プログラムはプリエンプティブ マルチタスクで実行できます。Windows NT は、実行中のアプリケーションが 1 つだけ含まれる VDM プロセス全体をプリエンプトします。 Win32環境サブシステムプロセス（）には、ウィンドウ管理機能も含まれており、これは「ウィンドウマネージャ」と呼ばれることもあります。このプロセスは、キーボードやマウスからの入力イベントを処理し、その入力を受け取る必要のあるアプリケーションにメッセージを渡します。各アプリケーションは、これらのメッセージに応じて、自身のウィンドウやメニューを描画または更新する責任を負います。csrss.exe

OS/2 環境サブシステムは、16 ビット文字ベースの OS/2 アプリケーションをサポートし、OS/2 1.x をエミュレートしますが、OS/2 2.x 以降で使用される 32 ビットまたはグラフィカルな OS/2 アプリケーションは、x86 マシンでのみサポートします。^{[ 3 ]}グラフィカルな OS/2 1.x プログラムを実行するには、Windows NT アドオン サブシステム for Presentation Manager をインストールする必要があります。^{[ 3 ]} OS/2 サブシステムを搭載した最後の Windows NT バージョンは Windows 2000 であり、Windows XP 以降はサポートが終了しています。^{[ 4 ] [ 5 ]}

POSIX環境サブシステムは、POSIX.1標準または関連するISO / IEC標準に厳密に準拠して記述されたアプリケーションをサポートします。このサブシステムは、 Windows Services for UNIXの一部であるInterixに置き換えられました。^{[ 4 ]}これはさらにWindows Subsystem for Linuxに置き換えられました。

セキュリティサブシステムは、「環境システムに代わってオペレーティングシステム固有の機能を管理し、セキュリティシステムプロセスで構成されます」。このセキュリティシステムプロセスはローカルセキュリティ機関（LSA）であり、セキュリティトークンを管理し、リソース権限に基づいてユーザーアカウントへのアクセスを許可または拒否し、ログイン要求を処理してログイン認証を開始し、Windows NT によって監査する必要のあるシステムリソースを決定します。^{[ 6 ]}また、 Active Directoryも管理します。 ワークステーションサービスは、Windows ファイルおよび印刷共有のクライアント側であるネットワークリダイレクタを実装します。これは、リモートファイルおよびプリンタへのローカル要求を、ネットワーク上の適切なサーバーに「リダイレクト」することによって実装します。^{[ 7 ]}逆に、サーバーサービスは、ネットワーク上の他のコンピュータがローカルシステムによって提供されるファイル共有および共有プリンタにアクセスできるようにします。^{[ 8 ]}

Windows エグゼクティブ サービスは、カーネル モードの低レベル部分を構成し、ファイル に含まれていますntoskrnl.exe。^{[ 9 ]}これは、I/O、オブジェクト管理、セキュリティ、およびプロセス管理を扱います。これらは、キャッシュ マネージャ、構成マネージャ、I/O マネージャ、ローカル プロシージャ コール(LPC)、メモリマネージャ、オブジェクトマネージャ、プロセス構造、およびセキュリティ リファレンス モニタ (SRM)など、いくつかのサブシステムに分かれています。これらのコンポーネントをまとめて、エグゼクティブ サービス(内部名Ex ) と呼ぶことができます。システム サービス(内部名Nt )、つまりシステム コールも、パフォーマンス向上のためにカーネル レイヤーに直接呼び出すごく少数のものを除いて、このレベルで実装されています。 ^{[ 12 ]}

この文脈における「サービス」という用語は、一般的に呼び出し可能なルーチン、または呼び出し可能なルーチンのセットを指します。^{[ 12 ]}これは、 Unix 系オペレーティングシステムのデーモンにいくらか類似したユーザーモードコンポーネントである「サービスプロセス」の概念とは異なります。^{[ 13 ]}

オブジェクトマネージャー

オブジェクトマネージャ（内部名Ob）は、他のすべての実行サブシステム、特にシステムコールが Windows NT リソースにアクセスするために通過しなければならない実行サブシステムであり、実質的にリソース管理インフラストラクチャ サービスとなっています。^{[ 14 ]}オブジェクトマネージャは、他の実行サブシステムにおけるオブジェクト リソース管理機能の重複を減らすために使用されます。重複は、バグの原因となり、Windows NT の開発を困難にする可能性があります。^{[ 15 ]}オブジェクトマネージャにとって、各リソースは、物理リソース（ファイルシステムや周辺機器など）であろうと論理リソース（ファイルなど）であろうと、オブジェクトです。各オブジェクトには、オブジェクトマネージャが認識しなければならない構造またはオブジェクト タイプがあります。

オブジェクトの作成は、作成と挿入の2 つのフェーズからなるプロセスです。作成によって空のオブジェクトが割り当てられ、オブジェクトマネージャが必要とするリソース（名前空間内の (オプションの) 名前など）が予約されます。作成が成功した場合、作成を担当するサブシステムが空のオブジェクトを埋めます。^{[ 16 ]}最後に、サブシステムが初期化が成功したと判断した場合、オブジェクトマネージャにオブジェクトを挿入するように指示します。これにより、オブジェクトは (オプションの) 名前またはハンドルと呼ばれるCookie を介してアクセスできるようになります。^{[ 17 ]}それ以降、オブジェクトのライフサイクルはオブジェクトマネージャによって管理され、オブジェクトマネージャから破棄するように指示されるまで、サブシステムはオブジェクトを動作可能な状態に維持する責任を負います。^{[ 18 ]}

ハンドルは、不透明な値を介してカーネル リソースへの参照を表す識別子です。^{[ 19 ]}同様に、オブジェクトをその名前で開くとセキュリティ チェックの対象となりますが、既存の開いているハンドルを介して操作する場合は、オブジェクトが開かれたり作成されたりしたときに要求されたアクセス レベルに制限されます。

オブジェクト型は、オブジェクトのプロシージャとオブジェクト固有のデータを定義します。このように、オブジェクトマネージャは、オブジェクト型をオブジェクトを定義するポリモーフィッククラスと考えることで、 Windows NTをオブジェクト指向オペレーティングシステムとして機能させています。ただし、I/Oマネージャという顕著な例外を除き、ほとんどのサブシステムは、すべてのオブジェクト型プロシージャのデフォルト実装に依存しています。

作成されたオブジェクトの各インスタンスには、その名前、オブジェクト作成関数に渡されるパラメータ、セキュリティ属性、およびオブジェクトタイプへのポインタが格納されます。オブジェクトには、オブジェクトのクローズ手順と参照カウントも含まれており、システム内の他のオブジェクトがそのオブジェクトを参照している数をオブジェクトマネージャに伝え、クローズ要求が送信されたときにオブジェクトを破棄できるかどうかを判断します。^{[ 20 ]}すべての名前付きオブジェクトは、階層的なオブジェクト名前空間に存在します。

キャッシュコントローラー

メモリマネージャ、I/Oマネージャ、およびI/Oドライバと密接に連携し、通常のファイルI/O用の共通キャッシュを提供します。Windowsキャッシュマネージャは、ローカルファイルとリモートファイル間の一貫した動作を実現するために、デバイスブロックではなくファイルブロック上で動作します。また、キャッシュブロックはメモリマップドビューの特殊なケースであり、キャッシュミスはページフォルトの特殊なケースであるため、メモリマップドビューとの一定の整合性を確保します。

構成マネージャー

Windowsレジストリに必要なシステムコールを実装します。

I/Oマネージャ

デバイスがユーザーモードサブシステムと通信できるようにします。ユーザーモードの読み取り/書き込みコマンドを読み取り/書き込みIRPに変換し、デバイスドライバに渡します。ファイルシステムI/O要求を受け付け、デバイス固有の呼び出しに変換します。また、ハードウェアを直接操作して入力の読み取りまたは出力の書き込みを行う低レベルのデバイスドライバを組み込むことができます。さらに、読み取り要求をキャッシュし、バックグラウンドでディスクに書き込むことでディスクパフォ​​ーマンスを向上させるキャッシュマネージャも含まれています。

ローカルプロシージャコール（LPC）

接続セマンティクスを備えたプロセス間通信ポートを提供します。LPCポートは、ユーザーモードサブシステムがクライアントと通信するため、エグゼクティブサブシステムがユーザーモードサブシステムと通信するため、そしてMicrosoft RPCのローカルトランスポートの基盤として使用されます。

メモリマネージャ

仮想メモリを管理し、メモリ保護と物理メモリから二次記憶装置へのメモリのページングを制御し、汎用的な物理メモリ割り当て機能を実装します。また、PE実行可能ファイルのパーサーも実装しており、実行可能ファイルを単一のアトミックなステップでマッピングまたはアンマップできます。

Windows NT Server 4.0、ターミナルサーバーエディション以降、メモリマネージャはセッション空間と呼ばれるものを実装しています。これは、ユーザーモードメモリと同様にコンテキストスイッチの対象となるカーネルモードメモリの範囲です。これにより、初期設計上の欠点にもかかわらず、カーネルモードWin32サブシステムとGDIドライバの複数のインスタンスを並行して実行できます。各セッション空間は複数のプロセスで共有され、これらをまとめて「セッション」と呼びます。

新しいオブジェクトタイプを導入することなくセッション間の一定の分離性を確保するため、プロセスとセッションの関連付けはセキュリティ参照モニターによってセキュリティ主体（トークン）の属性として処理され、特別な権限を保持している場合にのみ変更できます。

セッションが比較的洗練されておらず、アドホックな性質を持っているのは、セッションが当初の設計に含まれておらず、サードパーティ ( Citrix Systems ) がWindows NT 用ターミナル サーバー製品WinFrameの前提条件として、メインラインへの影響を最小限に抑えながら開発する必要があったためです。しかし、Windows Vista 以降、セッションはついに Windows アーキテクチャの正式な要素となりました。Win32 を介して間接的にユーザー モードに忍び込むメモリマネージャの構造ではなくなり、ほとんどの実行サブシステムに影響を与える遍在的な抽象化へと拡張されました。実際、Windows Vista を通常使用すると、常にマルチセッション環境になります。^{[ 21 ]}

プロセス構造

プロセスとスレッドの作成および終了を処理し、ジョブの概念を実装します。ジョブとは、まとめて終了したり、共通の制限（割り当てられたメモリの合計最大数やCPU時間など）を適用したりできるプロセスのグループです。ジョブオブジェクトはWindows 2000で導入されました。

PnPマネージャー

プラグアンドプレイに対応し、起動時にデバイスの検出とインストールをサポートします。また、必要に応じてデバイスの停止と起動を行う役割も担っています。これは、USBやIEEE 1394 FireWireなどのバスに新しいデバイスが接続され、それをサポートするためのデバイスドライバをロードする必要がある場合に発生します。その主要な機能は、ユーザーモードのプラグアンドプレイサービスで実装されており、適切なドライバのインストール、新しいデバイスの到着をサービスやアプリケーションに通知、ユーザーへのGUI表示といった、複雑なタスクを処理します。

電源マネージャー

電源イベント（電源オフ、スタンバイ、休止状態など）を処理し、特別な IRP (電源 IRP ) を使用して影響を受けるドライバーに通知します。

セキュリティリファレンスモニター（SRM）

セキュリティ統合サブシステムのセキュリティ規則を強制するための主要な権限。^{[ 22 ]}アクセス制御リスト（ACL）を使用して、オブジェクトまたはリソースにアクセスできるかどうかを決定します。ACL自体は、アクセス制御エントリ（ACE）で構成されています。ACEには、セキュリティ識別子（SID）と、ACEが特定の受託者グループ（ユーザーアカウント、グループアカウント、またはログインセッション^{[ 23 ]）}にそのリソースに対する許可（許可、拒否、または監査）を与える操作のリストが含まれています。^{[ 24 ] [ 25 ]}

GDI

グラフィックス デバイス インターフェイスは、線や曲線の描画、フォントのレンダリング、パレットの処理などのタスクを担当します。Windows NT 3.xシリーズのリリースでは、GDI コンポーネントはユーザー モードのクライアント/サーバー ランタイム サブシステムに配置されていましたが、グラフィックス パフォーマンスを向上させるために、Windows NT 4.0 でカーネル モードに移動されました。^{[ 26 ]}

カーネルはHALとExecutiveの間に位置し、マルチプロセッサ同期、スレッドおよび割り込みのスケジューリングとディスパッチ、トラップ処理と例外ディスパッチを提供します。また、起動時にオペレーティングシステムを起動するために必要なデバイスドライバを初期化する役割も担っています。つまり、カーネルは従来のマイクロカーネルのほぼすべてのタスクを実行します。Executiveとカーネルの厳密な区別は、元のマイクロカーネル設計の最も顕著な名残であり、過去の設計文書ではカーネルコンポーネントを一貫して「マイクロカーネル」と呼んでいます。

カーネルはプロセスマネージャとよくインターフェースします。^{[ 27 ]}抽象化のレベルは、カーネルがプロセスマネージャを呼び出すことはなく、逆方向のみである（ごく少数の特殊なケースを除いて、それでも機能的な依存関係にはなりません）。

Windows NT は、カーネルモードのデバイスドライバを使用してハードウェアデバイスとやり取りします。各ドライバには、オペレーティングシステムの他の部分にエクスポートされる、明確に定義されたシステムルーチンと内部ルーチンがあります。すべてのデバイスは、ユーザーモードのコードからは I/O マネージャ内のファイル オブジェクトとして認識されますが、I/O マネージャ自体からはデバイス オブジェクトとして認識され、I/O マネージャはそれをファイル、デバイス、またはドライバ オブジェクトとして定義します。カーネルモードのドライバは、最上位レベルのドライバ、中間レベルのドライバ、および下位レベルのドライバの 3 つのレベルに存在します。FATやNTFSのファイルシステム ドライバなどの最上位レベルのドライバは、中間レベルのドライバに依存します。中間レベルのドライバは、オプションで下位レベルと上位レベルのフィルタ ドライバの間に挟まれる機能ドライバ (デバイスのメイン ドライバ) で構成されます。機能ドライバは、バス ドライバ (バスコントローラ、アダプタ、またはブリッジを処理するドライバ) に依存します。バス ドライバには、オプションで機能ドライバとの間に配置されるバス フィルタ ドライバがあります。中間レベルのドライバは、機能するために最下位レベルのドライバに依存します。Windowsドライバ モデル(WDM) は中間層に存在します。最も低レベルのドライバは、デバイスを直接制御する従来のWindows NTデバイスドライバか、PnPハードウェアバスのいずれかです。これらの低レベルドライバはハードウェアを直接制御し、他のドライバに依存しません。

Windows NTのハードウェア抽象化レイヤー（HAL）は、コンピュータの物理ハードウェアとオペレーティングシステムの残りの部分との間のレイヤーです。これは、ハードウェアの違いを隠蔽し、カーネルが実行される一貫したプラットフォームを提供するために設計されました。HALには、I/Oインターフェイス、割り込みコントローラ、およびマルチプロセッサを制御するハードウェア固有のコードが含まれています。

しかし、HALはアーキテクチャ内での目的や位置づけに関わらず、カーネルがExecutiveの下位に位置するのと同様に、カーネルの下位に位置するレイヤーではありません。既知のHAL実装はすべて、何らかの形でカーネル、あるいはExecutiveに依存しています。実際には、これはカーネルとHALのバリアントが、連携して動作するように特別に構築された、対応するセットとして提供されることを意味します。

特に、ハードウェア抽象化は命令セットの抽象化を伴いません。命令セットの抽象化は一般的に移植性というより広い概念に含まれます。命令セットの抽象化は、必要に応じて（例えば、x86命令セットの複数の改訂に対応するため、または欠落している数学コプロセッサをエミュレートするためなど）、カーネルによって、またはハードウェア仮想化によって実行されます。

HALは^{[ 30 ]}hal.dllで実装されています。HALは、さまざまなハードウェアプラットフォームによって異なる方法で実装される多数の機能を実装しています。この文脈では、これは主にチップセットを指します。オペレーティングシステム内の他のコンポーネントは、実際の実装に関係なく、すべてのプラットフォームで同じ方法でこれらの機能を呼び出すことができます。

例えば、割り込みへの応答方法は、APIC（Advanced Programmable Interrupt Controller）を搭載したマシンと搭載していないマシンでは大きく異なります。HAL（ハードウェア抽象化レイヤー）は、様々なチップセットによるあらゆる種類の割り込みに対応する単一の関数を提供することで、他のコンポーネントがこれらの違いを気にしなくて済むようにしています。

HAL はカーネルのアドレス空間にロードされ、カーネルモードで実行されるため、HAL のルーチンはアプリケーションから直接呼び出すことができず、HAL ルーチンに直接対応するユーザーモード API もありません。代わりに、HAL は主に Windows のエグゼクティブおよびカーネル、そしてカーネルモードのデバイスドライバにサービスを提供します。ほとんどのハードウェアのドライバは、一般的に.sysファイルタイプの他のファイルに含まれていますが、いくつかのコアドライバは にコンパイルされますhal.dll。

PCIやPCI Expressなどのバス上のデバイス用のカーネルモードデバイスドライバは、HAL内のルーチンを直接呼び出して、デバイスのI/Oポートやレジスタにアクセスします。ドライバがHALルーチンを使用するのは、プラットフォームによってこれらの操作の実装が異なる場合があるためです。HALは各プラットフォームに合わせて操作を適切に実装するため、同じCPUアーキテクチャを使用するすべてのプラットフォームで同じドライバ実行ファイルを使用でき、ドライバソースファイルはすべてのアーキテクチャ間で移植可能です。

Windows 8より前のx86システムでは、インストール メディアに複数の異なる HAL ファイルがあります。Windows のインストール手順では、現在のプラットフォームに適した HAL ファイルを判断し、必要に応じて名前を変更してハード ドライブにコピーします。この選択の基準には、ACPI互換 BIOS の存在、 APICの存在、および複数のプロセッサが存在して有効になっているかどうかが含まれます。（マルチ コア CPUの複数のコア、およびハイパースレッディングCPUによって実装される「論理プロセッサ」もすべて、この目的においては「プロセッサ」としてカウントされます。）x86-64およびItaniumプラットフォームでは、各 CPU アーキテクチャに対して可能なのは 1 つだけです。Windows 8 以降では、x86 バージョンにも HAL は 1 つしかありません。hal.dllhal.dll

HALはWindows 10のバージョン2004以降ntoskrnl.exe^{[ 31 ]}に統合（または静的にリンク）されており、DLLは後方互換性のためのスタブとしてのみ機能します。