連載
.NETの動作原理を基礎から理解する!

第2回 .NETアプリケーションが起動する仕組み

―― Windowsローダーの働き ――

デジタルアドバンテージ 一色 政彦
2005/07/09
Page1 Page2


Back Issue
1
.NETアプリケーションを動かす土台

 前回は、パソコン上でWindows OSやアプリケーション・ソフトウェアなどのプログラムがどのようにして動作しているのかを、PCというハードウェア環境の観点で説明した。今回は、アプリケーションが起動する仕組みについて、Windows OSというソフトウェア実行環境の視点で解説する。

 ただし、今回説明するのは、.NETアプリケーション(以降、.NETアプリ)が.NET Frameworkの実行環境(「CLR:Common Language Runtime」と呼ばれる)の上で動作を開始するまでの処理過程の話である。実際に.NETアプリケーションがCLRにより実行される仕組みついては次回で解説する予定だ。

 前置きはこれくらいにして、さっそく「.NETアプリケーションが起動する仕組み(Windowsローダーの働き)」について説明していこう。なお本稿で提示されている図版などは、説明を簡略化するために、すべての詳細を正確に明記してはいないことをあらかじめお断りしておく。

Windows OSという視点から見た場合のプログラム実行の仕組み

 まずはWindows OSを利用するユーザーの視点で、Windows OS上でアプリケーションが起動する際の処理プロセスについて考えてみよう。

●Windows OS上でアプリケーションが起動する際の処理プロセス

 ここで前提知識として、次のことを知っておいてほしい。

 それは、.NETアプリケーションであろうと、Win32アプリケーションであろうと、それらのプログラムがWindows OSから最初に起動される処理過程は、基本的に同じであるということだ(なお、「.NETアプリケーション」と「Win32アプリケーション」の違いについては、前回の説明を参照してほしい)。

 従って本稿では、.NETアプリケーションの起動例を取り上げることで、Windows OS上でのアプリケーション起動の仕組みを説明することにした。例に用いる.NETアプリケーションとして、本稿では「WindowsApplication1.exe」というシンプルなWindowsアプリケーションを用意した。

 次の画面は、そのアプリケーションをダブルクリックして起動したときの、処理の流れを図示したものである。

Windows OS上でアプリケーションが起動する際の処理の流れ図
ディレクトリ(この例では「C:\fdotnet\WindowsApplication1\bin\Release」)の中にあるWindowsアプリケーション「WindowsApplication1.exe」をダブルクリックして実行したときの処理プロセスを図示したもの。なお、 の処理プロセスで示されている、CPUおよびメイン・メモリでの処理の流れについては、前回の「Windows上でプログラムが実行されるまでの処理の流れ」を併せて参照するとよい。
  ユーザーが「WindowsApplication1.exe」という<ファイル>をダブルクリックする。
  Windows OSは、をきっかけとして、クリックされたファイルである「WindowsApplication1.exe」がプログラムかどうかを判定する。
  Windows OSは、の作業によりファイルがプログラムと判定されると、そのプログラム・データ(=プログラム・コード)をメイン・メモリ上にロードしたうえで、<Win32アプリケーション>のプログラムとして実行する。
  メイン・メモリ上にロードされた「WindowsApplication1.exe」のプログラム・コードを、CPUが1つずつ処理していく。これにより、.NETの実行環境「CLR」が構築されて、その環境上でアプリケーションが実行される。そして最終的に、Windows OSのデスクトップ画面上に、[Form1]というタイトルでアプリケーション・ウィンドウが表示される。

 それでは、ここで図示されている一連の処理の流れを、1つずつ、もう少し詳しく説明していこう。

ユーザーがファイル「WindowsApplication1.exe」をダブルクリックする

 この一連の処理プロセスの中で特に注目すべきは、これまで「プログラム」や「アプリケーション」と呼んでいたものの正体が、実は単なる<ファイル>に過ぎなかったということである。なるほど、ファイルの種類には、例えば「テキスト・ファイル」「Word文書ファイル」などなど、いろいろなものがあるが、プログラムもそれらのファイルと本質的には何ら変わらないわけである。

 しかしよく考えてみると、Windows OSにとってこれが1つの課題・障壁となるのではないだろうか。もしそれらがすべて「ファイル」という同じものであるのならば、Windows OSはそのファイルが一体どのようなものか、つまり「ファイルの種類」(以降、ファイル・タイプ)を認識しなければならないはずだ。このファイル・タイプが分からなければ、そのファイルに対する適切な操作方法(例えば「Windows OS上でプログラムとして直接実行する(Execute)」のか、「アプリケーションでそのファイルを開く(Open)」のかなど)も分からないはずだからである。

 当然ながらWindows OSはこの課題をクリアしている。例えば、ユーザーが「memo.txt」というテキスト・ファイルをダブルクリックすると、Windows OSは、そのファイルのファイル・タイプを正確に判定して(この例では、「テキスト・ファイルである」と判定される)、ユーザーが要求するアクション(この例では、「アプリケーションでそのファイルを開くこと」)を適切に開始する。これによりWindows OSは、ユーザーが意図するアプリケーションを、正しく起動できるわけである(この例では、「メモ帳(notepad.exe)」などのテキスト・エディタ・アプリケーションで実際に開かれる)。

Windows OSが「WindowsApplication1.exe」がプログラムかどうかを判定する

 このように、OSによるプログラムの起動では、「ファイル・タイプの判定」作業が肝心である。ファイル・タイプの判定方法は、OSごとに異なるが*1、Windows OSでは、「拡張子の名前」(この例では「.exe」)によって行われている(これは「拡張子とファイル・タイプの関連付け」と呼ばれるWindows OSが持つ機能の上に成り立っている)。つまり、先ほどの課題に対するWindows OSの場合の解決方法は、「拡張子」なのである。

*1 ちなみにMac OSは、基本的にファイル・タイプを「拡張子」では判定しない。その代わりに、Mac OS専用のファイル・フォーマット(「Mac OS拡張フォーマット」または「HFS Plusフォーマット」と呼ばれる)のヘッダ部分(=多くの場合、ファイルの先頭部分に配置されるファイル自体の構成内容に関する情報を格納するための領域)にあるファイル情報(「Finder情報」と呼ばれる)を用いて、ファイル・タイプを判別している。ただし最新のMac OS Xなどでは、Windows OSと同じように(Finder情報を使わずに)「拡張子」で判定されるケースも多いらしい。

 Windows OSでは、ファイルの拡張子が「.exe」である場合、そのファイルのファイル・タイプは「実行可能ファイル(Executable File)だ」と識別される。つまり、「Windows OS上で実行可能なプログラムである」と判定されるわけだ。

 従って、本稿の例の「WindowsApplication1.exe」というファイルには、「.exe」という拡張子が付けられているために、実行可能ファイルとして取り扱われて、実際にプログラムとして実行が開始されることになる。

Windows OSは「WindowsApplication1.exe」をプログラムとして実行する

 プログラムの実行開始を受け持つWindows OSの機能は、「Windowsローダー(Windows Loader)」と呼ばれている。Windowsローダーは、「実行可能ファイル」と判定されたファイルを、「Microsoft Portable Executeフォーマット」*2(以降、「PEフォーマット」)と呼ばれるプログラム実行用(主にWin32アプリケーション)のファイル・フォーマット(=ファイル形式)で作成されたファイルとして取り扱う。

 つまり、すべての実行可能ファイル(.exeファイル)は、PEフォーマットで作成されている必要があるわけだ。これについても、Win32アプリケーションであろうが、.NETアプリケーションであろうが、等しく同じ条件である。すなわち、.NETアプリケーションといえども、Windows OSからは「実行プログラムの1つである」と見えているのだ*3

*2 PEフォーマットは、Win32アプリケーションの基本フォーマットで、.NETアプリケーションやWin64アプリケーションでも用いられるフォーマットである。
*3 厳密にいえば、Windows XPやWindows Server 2003以降のOSは、.NETアプリケーションの存在を知っており、.NETアプリケーションを「Win32アプリケーション」ではなく、きちんと「.NETアプリケーション」として認識している(詳細後述)。

 実行可能ファイルが正しくPEフォーマットで作成されていれば、Windowsローダーは、そのファイルを<Win32アプリケーション>のプログラムとして取り扱い始め、実際にプログラムとして起動する。その際の処理過程は次の図のとおりだ。

Windowsローダーによるアプリケーションの起動プロセス
Windowsローダーは、PEフォーマットで作成された実行可能ファイルを、<Win32アプリケーション>のプログラムとして起動する。具体的な手順の内容は以下の記述を参照。

Windowsローダーは、PEフォーマットに基づいて、実行可能ファイルの先頭部分に格納されている情報(以降、「PEヘッダ」)を解析する

Windowsローダーは、解析結果に基づき、実行に必要なプログラム・コードをメイン・メモリ上にロードする

Windowsローダーは、解析結果に基づき、プログラムの実行開始位置(Entry Point。以降、「エントリ・ポイント」)にアクセスし、そこに記述された処理命令をCPUに実行させる

CPUが、そのエントリ・ポイントから順番に1つずつ処理命令を実行していくことで、プログラムが実行開始される

 これらの一連のWindowsローダーの処理がすべて完了して、初めてプログラムが現実に実行される(本稿の例でいえば、[Form1]というWindowsアプリケーションのウィンドウが表示される)わけである。

Windows OSのデスクトップ画面上に、[Form1]というタイトルでアプリケーション・ウィンドウが表示される

 ここまでが、.NETアプリケーションが<Win32アプリケーション>として起動するまでの流れである。そしての処理段階からは、.NET Frameworkの実行環境「CLR」へと、その実行の舞台が移される。つまりプログラムが、<Win32アプリケーション>という存在から、<.NETアプリケーション>という存在へと変ぼうするのだ。このの処理段階以降の話については、次回詳しく説明するので、それまでお待ちいただきたい。

 以上が理解できたら、の処理内容をもっと具体的に細かく見ていくことにしよう。次のページでは、Windowsローダーが処理する手順で、プログラムの内部を1つずつ追っていくことにする。


 INDEX
  .NETの動作原理を基礎から理解する!
  第2回 .NETアプリケーションが起動する仕組み
  1.Windows OSという視点から見た場合のプログラム実行の仕組み
    2.Windowsローダーがアプリケーションを起動する処理プロセス
 
インデックス・ページヘ  「.NETの動作原理を基礎から理解する!」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間