BOOK Preview

インサイドMicrosoft Windows 第4版 上

第2章 システムアーキテクチャ

2.4.4 カーネル
2.4.5 ハードウェア抽象化層(HAL)
2.4.6 デバイスドライバ

マイクロソフトプレスの書籍紹介ページ
書籍情報のページ
2005/09/06

 本コーナーは、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のそれとは一致しません。あらかじめご了承ください。

2.4.4 カーネル

 カーネルは、Ntoskrnl.exeに実装される関数セットで構成されます。カーネル関数は、プロセッサアーキテクチャごとに異なる低レベルハードウェアアーキテクチャ固有機能(割り込みや例外ディスパッチなど)をサポートすると共に、エグゼキュティブコンポーネント用の基本メカニズム(スレッドスケジューリングや同期サービスなど)を提供します。カーネルコードは主にC言語で記述されていますが、特殊なプロセッサ命令やレジスタへのアクセスが必要な部分はアセンブリ言語で記述されています。

 前の節で触れた各種のエグゼキュティブサポート関数と同じように、カーネル関数の多くはデバイスドライバ内部で使用されることもあり、DDKドキュメントで解説されています。検索時は、Keで始まる関数を探してみるとよいでしょう。

■カーネルオブジェクト

 カーネルは、上位層であるエグゼキュティブコンポーネントが必要とする低レベル機能を提供します。これらの機能は、オペレーティングシステムを構成する基礎部品やメカニズムといわれることもあります。表現を変えれば、カーネルは、オペレーティングシステムメカニズムを提供する一方、システムの使い方(ポリシー)を制限しない設計になっています。簡単に言ってしまえば、カーネルは、ポリシーを決める上位層であるWindowsエグゼキュティブと自分自身を切り離しています。スレッドスケジューリングとイベントディスパッチなどの低レベル作業は別にして、それ以外のほぼすべてのポリシー決定は、Windowsエグゼキュティブに任せています。

 カーネルの上位層であるエグゼキュティブは、スレッドと他の共有可能リソースをオブジェクトとして表現します。これらのオブジェクトは、操作用のオブジェクトハンドル、保護するためのセキュリティチェック、作成時に必要となるリソース量などのポリシーオーバーヘッドを必要とします。カーネルでは単純なオブジェクトが使われているため、この種のオーバーヘッドは発生しません。カーネルが使用しているオブジェクトはカーネルオブジェクトと呼ばれ、エグゼキュティブオブジェクトの作成と管理のベースになっています。エグゼキュティブオブジェクトのほとんどは、1個以上のカーネルオブジェクトを隠ぺいし、カーネル定義属性を継承してできあがっています。

 コントロールオブジェクトと呼ばれるカーネルオブジェクト群は、各種のオペレーティングシステム機能を制御する基盤を与えています。たとえば、このオブジェクト群には、APCオブジェクト、DPC(Deferred Procedure Call)オブジェクト、割り込みオブジェクトなどのI/Oマネージャが使用するいくつかのオブジェクトなどが含まれます。

 ディスパッチャオブジェクトと呼ばれる別のカーネルオブジェクト群は、スレッドスケジューリングを変更あるいは左右する同期機能を備えています。このオブジェクト群には、カーネルスレッド、ミューテックス(内部名はミュータント)、イベント、カーネルイベントペア、セマフォ、タイマ、およびウェイタブルタイマなどが含まれます。エグゼキュティブは、カーネル関数を使用してカーネルオブジェクトを作成したり、それを操作しています。また、ユーザーモードに提供しているより複雑なオブジェクトも、カーネル関数を呼び出して作成しています。オブジェクトに関する詳しい説明は第3を、プロセスとスレッドに関する詳しい説明は第6章で行います。

■ハードウェアサポート

 Windowsは、さまざまなハードウェアアーキテクチャをサポートしています。カーネルには、各種のハードウェア上の違いを隠ぺいし、エグゼキュティブとデバイスドライバを抽象化するという別の役割があります。つまり、各種の関数を定義し、その内部でハードウェアアーキテクチャ上の違いを吸収することになります。たとえば、割り込み処理、例外ディスパッチ、マルチプロセッサ間の同期化などはカーネル関数内部に実装され、エグゼキュティブとデバイスドライバはこれらの関数により、ハードウェア仕様詳細と分離されます。

 カーネル関数は、大量のコードを最大限共有する設計になっています。結果的に、カーネルは、各種アーキテクチャ間で同一の意味を持ち、かつ、移植可能なインターフェイスセットを持つことになりました。このようなインターフェイスを実装するコードのほとんどは、アーキテクチャに依存せず、同じになります。

 しかし、アーキテクチャに応じて異なる実装コードを持つインターフェイスも存在します。あるいは、インターフェイスのいくつかは、アーキテクチャ固有コードで部分的に実装されています。アーキテクチャから意味的に独立しているインターフェイスは、任意のマシン上で汎用的に利用できます。第3章で取り上げるスピンロックルーチンなどのカーネルインターフェイスは、同一のアーキテクチャを持つハードウェアシステム間で実装上の違いが発生することもあり、次の節で取り上げるHAL内部に実装されています。

 カーネルはまた、少量のx86固有インターフェイスを備え、古いMS-DOSプログラムをサポートしています。これらのx86インターフェイスは、他のアーキテクチャベースのマシン上では呼び出すことができません。つまり、移植はできません。たとえば、x86固有コードは、グローバルデスクリプター(GDT)やローカルデスクリプター(LDT)を操作する関数を呼び出す機能を提供します。

 カーネルは、変換バッファやCPUキャッシュ機能などもアーキテクチャ固有コードとして実装しています。この種の機能は、キャッシュの実装方法がアーキテクチャごとに異なり、エグゼキュティブなどの上位層から隠ぺいする必要があります。

 コンテキスト切り替えもアーキテクチャごとに異なります。スレッドの選択とコンテキスト切り替え時には、論理的には同一のアルゴリズムが使えます(直前のスレッドのコンテキストを保存し、新しいスレッドのコンテキストをロードした後に、その実行を開始する、といえます)。しかし、プロセッサが異なれば、実装上の違いが表面化するのが現実です。コンテキストというのは、レジスタをはじめとするプロセッサの状態を基に表現されます。つまり、保存される内容とロードされる内容は、アーキテクチャに依存しているのです。

2.4.5 ハードウェア抽象化層(HAL)

 本章の冒頭で触れたように、Windows設計時の大きな目標の1つは、各種のハードウェアプラットフォーム間での高い移植性の実現です。ハードウェア抽象化層(HAL)は、この移植性実現の上でキーとなるコンポーネントです。HALは、ロード可能なカーネルモードモジュールであり、Windowsが動作するハードウェアプラットフォームへの低レベルインターフェイスを提供します。HALは、その名称が示しているように、I/Oインターフェイス、割り込みコントローラ、マルチプロセッサ通信メカニズムなどのすべてのハードウェアおよびアーキテクチャの詳細技術を隠ぺい(抽象化)します。

 表2-6に示すような複数のHALが用意されています。しかし、使用しているWindowsシステムにインストールされるHALは、あくまでも1つです。Windowsのインストール時、適切なHALが選択され、Hal.dllという名称のHAL ファイルがシステムディスクにコピーされます。VMSなどの他のオペレーティングシステムは、システムブート時に相当するHALファイルを選択することになります。このため、x86インストール時に作成されたシステムディスクは、異なるプロセッサを搭載するシステムでは使えません。HALがサポートするプロセッサが異なれば、そのシステムディスクは意味がありません。

HAL ファイル名 サポートされるシステム
Hal.dll 標準PC
Halacpi.dll 電源構成詳細管理インターフェイス(ACPI)PC
Halapic.dll 高機能プログラマブル割り込みコントローラ(APIC)PC
Halaacpi.dll APIC ACPI PC
Halmps.dll マルチプロセッサPC
Halmacpi.dll マルチプロセッサACPI PC
Halborg.dll Silicon Graphics ワークステーション(Windows 2000 のみ。現在販売中止)
Halsp.dll Compaq SystemPro(Windows XP のみ)
表2-6 \Windows\Driver Cache\i386\Driver.cab のx86 HAL リスト
 
   

 Windows Server 2003からは、ベンダー固有HALは基本システムの一部として提供されなくなりました。

 
実験:Windowsに含まれている基本HALを調べる

 Windowsに含まれているHALを調べるには、\Windows\Driver Cacheフォルダにあるアーキテクチャ固有フォルダを開きます。たとえば、x86の場合、\Windows\Driver Cache\i386\Driver.cabにファイル名が入っています。Halで始まるファイル群の先頭までスクロールダウンすると、表2-6に示したようなファイルリストがあるはずです。

 
実験:現在動作しているHALを調べる

 ここでは、最も簡単な方法を紹介しておきます。\Windows\Repair\Setup.logを開き、Hal.dllを探し、等号の後に続く名前を見てください。その名前は、Driver.cabからコピーされたHALです。たとえば、次のような情報が記述されているはずです。   \WINDOWS\system32\hal.dll = "halaacpi.dll","20143"

 
実験:NTOSKRNLとHALイメージの依存関係を調べる

 カーネルとHALイメージの依存関係を調べるには、Dependency Walker というツールを使用できます。このツールは、WindowsサポートツールとPlatform SDKに含まれています。[File]メニューから[Open]を選択し、目的のイメージファイルをロードします。

 次の画面は、Ntoskrnl.exeイメージをロードした直後のようすを示しています。エクスポートとインポートテーブルの内容が表示されています。


 この画面上からわかるように、NtoskrnlはHALとリンクされると共に、HALもNtoskrnlとリンクされています。つまり、2つのイメージは相互に関数を再利用しあっています。Ntoskrnlはまた、Bootvid.dllとリンクされています。Bootvid.dllは、GUI起動画面を実装するために使用されるブートビデオドライバです。Windows XP以降のWindowsでは、Kdcom.dllというライブラリが追加表示されているはずです。

 そのライブラリには、Ntoskrnl.exeの一部を構成するカーネルデバッガインフラコードが含まれています。

 Dependency Walkerツールの使い方と表示情報の詳しい説明は、ツール付属のDepends.hlpファイルを参照してください。

2.4.6 デバイスドライバ

 デバイスドライバの本格的な説明は第9章で行いますが、ここではその概要(ドライバのタイプと現在ロードされているドライバの確認方法)を簡単に説明しておきます。

 デバイスドライバは、ロード可能なカーネルモードモジュール(通常、拡張子.sysを持つファイル)です。デバイスドライバは、I/Oマネージャと該当するハードウェア間のインターフェイスとして機能し、次のようないずれかのコンテキストで動作します。

  • I/O関数を呼び出したユーザースレッドのコンテキスト

  • カーネルモードスレッドのコンテキスト

  • 割り込み発生時のコンテキスト(この場合には、特定のスレッドやプロセスのコンテキストではない。つまり、割り込み発生時のプロセスかスレッドのコンテキストで動作する)

 既に触れたように、Windowsシステム内のデバイスドライバは、ハードウェアを直接操作しません。デバイスドライバ内部では、HAL内に実装されている関数を呼び出し、ハードウェアと対話しています。Windowsデバイスドライバは基本的にはC言語で記述されていますから(一部はC++)、HAL内部のルーチンを適切に使用すれば、各種のCPUアーキテクチャ間でソースコードレベルでの移植が可能であり、アーキテクチャファミリ的には、バイナリ互換となります。

 デバイスドライバは、次のようなタイプにわかれています。

  • ハードウェアデバイスドライバ ― このタイプのデバイスドライバは、HAL関数経由で、物理デバイスやネットワークとの間でデータのやり取りを行います。ハードウェアデバイスドライバには、バスドライバ、ヒューマンインターフェイスドライバ、マスストレージドライバなどがあります。

  • ファイルシステムドライバ ― このタイプのドライバは、ファイルベースのI/O要求を受け取り、特定のデバイス向けのI/O要求に変換します。

  • ファイルシステムフィルタドライバ ― このタイプのドライバは、ディスクミラーリングや暗号化処理、I/O要求のインターセプトと独自のデータ追加処理などを行います。

  • ネットワークリダイレクタとサーバー ― このタイプのドライバはファイルシステムドライバの一種であり、ファイルシステムI/O要求をネットワーク上のマシンに送信したり(リダイレクタ)、ネットワーク側からの要求を受信します(サーバー)。

  • プロトコルドライバ ― TCP/IP、NetBEUI、IPX/SPXなどのネットワークプロトコルを実装します。

  • カーネルストリーミングフィルタドライバ ― このタイプのドライバは、相互に連携してデータストリームの信号処理(オーディオとビデオの記録と表示)を行います。

 ユーザー作成カーネルモードコードをシステムに追加したい場合には、デバイスドライバを開発し、インストールする必要があります。このため、プログラマの中には、(DDKから公開されていても)ユーザーモードからはアクセスできないオペレーティングシステム内部関数やデータ構造体にアクセスする最後の手段として、デバイスドライバを活用しています。たとえば、www.sysinternals.comから公開されているユーティリティの多くは、Windows GUIアプリケーションと、内部システム情報やカーネルモード関数にアクセスするデバイスドライバで構成されています。

■Windowsドライバモデル(WDM)

 Windows 2000は、プラグアンドプレイ(PnP)と電源管理オプションを追加し、Windows Driver Model(WDM)と呼ばれているWindows NTドライバモデルを拡張しました。Windows 2000以降のWindowsバージョンは、旧式のWindowsNTドライバを実行しますが、新しく追加された機能や拡張された機能はサポートしません。つまり、旧式のドライバを使用しているシステムは、この2つの機能面で制限を受けることになります。

 WDMから見た場合には、3種類のドライバが存在することになります。

  • バスドライバ ― このタイプのドライバは、バスコントローラ、アダプタ、ブリッジ、あるいは下位デバイスを持つすべてのデバイスにサービスを提供します。バスドライバは必須ドライバで、通常、Microsoftが提供してくれます。システム上の個々のバスタイプ(PCI、PCMCIA、およびUSB)は、専用のバスドライバを持っています。VMEbus、Multibus、およびFuturebusなどの新しいバス仕様用のドライバは、サードパーティ製のものが利用できるようになっています。

  • ファンクションドライバ ― ファンクションドライバというのはメインとなるデバイスドライバであり、デバイスを操作するためのインターフェイスを提供します。デバイスが直接操作されないような場合(たとえば、SCSI PassThruのように、I/Oはバスドライバと何らかのバスフィルタドライバで行われるような実装形態)、ファンクションドライバは必須となります。ファンクションドライバは、要するに、デバイス固有情報(レジスタなど)を一番よく知っているドライバです。

  • フィルタドライバ ― フィルタドライバは、デバイス(あるいは、インストール済みデバイス)に機能を追加したり、他のドライバとの間で交換するI/O要求とその応答を修正するために使用されます(ハードウェアリソースに関する不正確な情報を送信するデバイスの動作を修正するようなこともあります)。この種のドライバは必須のものではなく、個数も制限されていません。たとえば、ファンクションドライバの上位や下位、およびバスドライバの上位におくことも可能です。通常は、デバイスの製造会社あるいは独立ハードウェアベンダー(IHV)が提供しています。

 WDMドライバ環境では、1個のドライバがデバイスのすべての面を制御するようにはなっていません。バスドライバは、バス上のデバイスからPnPマネージャへのレポートを担当し、ファンクションドライバはデバイスを操作します。

 ほとんどの場合、下位レベルフィルタドライバはデバイスハードウェアの動作を修正します。たとえば、あるデバイスが、実際には16個のI/Oポートを必要とするとき、バスドライバに4個のポートを要求したとします。このような場面では、デバイス固有の低レベルファンクションフィルタドライバがバスドライバとPnPマネージャ間に介在し、I/Oポート数を更新したりします。つまり、バスドライバのハードウェアリソースレポートは、別のドライバによってチェックされるわけです。

 上位にあるフィルタドライバは、基本的には付加機能を提供し、デバイスの機能を拡張します。たとえば、キーボードなどの上位デバイスフィルタは、セキュリティチェック機能などの付加サービスを提供しています。

 割り込み処理については第3章で取り上げます。I/Oマネージャ、WDM、PnP、電源管理オプションの詳細については、第9章を参照してください。

実験:インストールされているデバイスドライバを調べる

 現在ロードされているデバイスドライバを調べる場合、Drivers.exeユーティリティ、あるいはPstat.exeユーティリティを使用できます。DriversユーティリティはWindows 2000リソースキットに、PstatユーティリティはWindows XP サポートツール、およびPlatform SDKにそれぞれ含まれています。次の情報は、Drivers.exeが出力する情報の一部です。

c:\>drivers
ModuleName    Code    Data   Bss  Paged   Init    LinkDate
------------------------------------------------------------------------------
ntoskrnl.exe  495616  106496   0  1327104 180224  Thu May 27 09:35:29 2004
     hal.dll   36864   49152   0    40960  16384  Tue Mar 25 16:07:24 2003
   KDCOM.DLL    4096    4096   0     4096   4096  Tue Mar 25 16:08:00 2003
 BOOTVID.dll    8192    4096   0        0   4096  Tue Mar 25 16:07:58 2003
    ACPI.sys  106496   12288   0    45056   8192  Tue Mar 25 16:16:21 2003
  WMILIB.SYS    4096    4096   0     4096   4096  Tue Mar 25 16:13:00 2003
     pci.sys   20480    4096   0    32768   8192  Tue Mar 25 16:16:40 2003
  isapnp.sys   12288    4096   0    24576   4096  Tue Mar 25 16:16:35 2003
  pciide.sys    4096    4096   0        0   4096  Tue Mar 25 16:04:46 2003
 PCIIDEX.SYS    8192    4096   0    16384   4096  Tue Mar 25 16:04:44 2003
intelide.sys    4096    4096   0        0   4096  Tue Mar 25 16:04:45 2003
MountMgr.sys    4096    4096   0    32768   4096  Tue Mar 25 16:03:05 2003
  ftdisk.sys    8192    4096   0   106496   8192  Tue Mar 25 16:05:26 2003
  dmload.sys    4096    4096   0        0   4096  Tue Mar 25 16:08:08 2003
    dmio.sys  122880   16384   0     4096   4096  Tue Mar 25 16:08:14 2003
 volsnap.sys    8192    4096   0    86016   8192  Tue Mar 25 16:05:47 2003
 PartMgr.sys    8192    4096   0    20480   8192  Tue Mar 25 17:04:02 2003
   atapi.sys   49152    4096   0    32768  12288  Tue Mar 25 16:04:48 2003
    disk.sys    8192    4096   0    24576   8192  Tue Mar 25 16:05:20 2003
CLASSPNP.SYS   32768    4096   0    24576   8192  Tue Mar 25 16:38:14 2003
PxHelp20.sys    7168    5536   0        0   1120  Fri Oct 18 08:09:28 2002
...
     srv.sys   69632   12288   0   258048  12288  Tue Mar 25 17:49:51 2003
   ipnat.sys   69632    4096   0     4096   4096  Tue Mar 25 16:11:05 2003
    mc21.tmp       0       0   0        0      0
   ntdll.dll  528384   20480   0        0      0  Wed Mar 26 12:53:00 2003
------------------------------------------------------------------------------
       Total 9263456 2588064   0  4699584 828960

 このように、現在ロードされているカーネルモードコンポーネント(Ntoskrnl、HAL、デバイスドライバ)の名称が、イメージ情報(セクション単位での大きさ)と共に返されています。

 Pstatユーティリティも同じようにロードされているドライバリストを返してきますが、その前にプロセスリストとスレッド情報を表示してきます。Pstatは、Driversユーティリティが返さない1つの情報を返してきます。それは、システムスペース内のモジュールのロードアドレスです。このアドレスは、実行中のシステムスレッドとデバイスドライバを関係付ける際に必要になります。詳しくは後述します。

 
非公開インターフェイスを解析する

 Ntoskrnl.exe、Hal.dll、あるいはNtdll.dllなどといった、キーとなるシステムイメージ内のエクスポート関数名やグローバルシンボル名を調べると、Windowsシステムに関する深い知識を身に付けることができます。たとえば、それまで漠然と理解していたWindowsの内部動作が、関数名やシンボル名を通してはっきりわかるようになります。もちろん、関数名を知ったからといって、プログラム内で呼び出せるようになるわけではありません。また、インターフェイスによっては非公開になっており、将来変更されることもあります。非公開のインターフェイスは、基本的に使用すべきではありません。しかし、非公開のインターフェイスを知ると、Windowsの内部動作をかなり理解できるようになるものです。

 たとえば、Ntdll.dll内の関数のリストを表示してみると、すべてのシステムサービスがわかります。それらのサービスは、WindowsがユーザーモードサブシステムDLLに提供しているものです。これらの関数の多くは、公開済みサポート関数に対応していますが、Windows API経由で利用できないものもあります。この当たりの詳細については、www.sysinternals.comの記事「Inside the Native API」を参照してください。

 また、Kernel32.dll、Advapi32.dllなどのWindowsサブシステムDLLのインポート関数と、呼び出しているNtdll関数を調べるのもおもしろいことです。

 Ntoskrnl.exeイメージはダンプしてみる価値があります。カーネルモードデバイスドライバが使用するエクスポート関数の多くはWindows DDKに記述されていますが、記述されていない(非公開)関数も結構存在します。NtoskrnlとHALのインポートテーブルを調べるのも一興です。NtoskrnlとHALが相互に依存していることがわかります。

 表2-7は、Windowsエグゼキュティブコンポーネント内部で共通して使用されている関数名プリフィックスのほぼ完全なリストです。それぞれのエグゼキュティブコンポーネントは、リストされているプリフィックスの派生名を使用して、内部関数を表現しています。たとえば、internal(内部の)の「i」をプリフィックスの先頭文字に続けて記述したり、あるいは、private(私的な)の「p」をプリフィックスに続けて記述しています。たとえば、Kiは内部カーネル関数を、Pspは内部のプロセスサポート関数などを表しています。

プリフィックス コンポーネント
Cc キャッシュマネージャ
Cm 構成マネージャ
Ex エグゼキュティブサポート関数
FsRtl ファイルシステムドライバランタイムライブラリ
Hal ハードウェア抽象化層
Io I/O マネージャ
Ke カーネル
Lpc ローカルプロシージャコール
Lsa ローカルセキュリティ認証
Mm メモリマネージャ
Nt Windows システムサービス(ほとんどはWindows 関数として公開される)
Ob オブジェクトマネージャ
Po 電源管理
Pp PnP マネージャ
Ps プロセスサポート
Rtl ランタイムライブラリ
Se セキュリティ
Wmi WMI(Windows Management Instrumentation)
Zw (Nt で始まる)システムサービスミラーエントリポイント。Nt システムサービスは、アクセスモードをカーネルモードに切り替えますが、ユーザーモードからカーネルモードに切り替える場面では、受け取るパラメータの妥当性を検証しています。このため、システムサービス内部でのパラメータ検証作業は不要になります。
表2-7 Windows エグゼキュティブと一般的なプリフィックス

 Windowsシステムルーチンが採用している命名規則を理解していると、これらのエクスポート関数名をより簡単に理解できるようになるでしょう。基本的には、次のような命名規則を採用しています。

<プリフィックス><操作><オブジェクト>

 この場合、<プリフィックス>はルーチンをエクスポートする内部コンポーネント、<操作>はオブジェクトやリソースに対して行われる処理内容、そして<オブジェクト>は操作対象をそれぞれ示しています。

 たとえば、ExAllocatePoolWithTagと命名されたルーチンは、ページあるいは非ページプールからメモリを割り当てるWindowsエグゼキュティブサポートルーチンであることを示しています。KeInitializeThreadは、カーネルスレッドオブジェクトを割り当て、それを初期化するルーチンであることを示します。

 

 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」


Windows Server Insider フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Windows Server Insider 記事ランキング

本日 月間