とあるコンサルタントのつぶやき : 64bit

Part 3. ASP.NET 2.0 Web アプリケーションの 64 ビット対応

nakama — Thu, 13 Nov 2008 10:01:36 GMT

さて、前回のエントリではコンソールアプリケーションやライブラリアプリケーションの 64 ビット対応について解説しましたが、ASP.NET Web アプリケーションでは、一般に実行時コンパイルが行われるため、動作がちょっと複雑になります。これについて、以下に解説したいと思います。

なお、本エントリの解説は、すべて ASP.NET Web サイトプロジェクトによる Web アプリケーションを前提とします。VS2005 SP1 以降で導入された ASP.NET Web アプリケーションプロジェクトの場合には、一部のコードが先行コンパイルされる形になるため、本エントリの解説内容よりももう少し複雑になります。が、本エントリの内容と前回のエントリの内容を正しく理解すれば、スイッチの付与の仕方はわかると思いますので、このエントリでは Web アプリケーションプロジェクトについては解説対象外としたいと思います。

では、以下の順に解説していくことにします。

64 ビット／32 ビット動作の決定メカニズム

Web サイトプロジェクトを含むソリューションのビルド構成設定

IIS 6 のワーカプロセスの動作ビットモードの変更方法

IIS 7 のワーカプロセスの動作ビットモードの変更方法

64 ビットワーカプロセスの制限事項

開発環境において 64 ビットワーカプロセスを使いたい場合について

［Step. 11］ ASP.NET Web アプリケーションの動作ビットの決定メカニズム

まず、結論から記述すると、ASP.NET Web アプリケーションが64 ビット／32 ビットのどちらで動作するのかは、Web サーバのワーカプロセスの動作モードによって決定されます。

*.aspx ファイルや *.asmx ファイルは実行時に .dll ファイルにコンパイルされますが、これらのファイルはすべて Any CPU としてコンパイルされます。このため、この .dll ファイルが 32/64 どちらで動作するのかは、ワーカプロセスの動作モードにより決定されます。

例えば、x64 Windows OS 上に Visual Studio 2008 をインストールし、Web サイトプロジェクトを実行した場合には、32 ビット版の ASP.NET 開発サーバが起動します。

この場合には、64 ビット OS を使っていても、Web アプリケーションは 32 ビット動作（WOW64 上での動作）となります。

また、IIS 6, 7 の場合には、ワーカプロセス（w3wp.exe）に 32 ビット版と 64 ビット版の 2 種類が用意されています（切り替え方は後述）。このため、64 ビット版のワーカプロセスを利用して Web アプリケーションを動作させた場合には、64 ビット動作することになります。

このように、Web アプリケーションの場合には、Web アプリ側で 32/64 ビット指定をするのではなく、ワーカプロセス側の方でビット切り替えを行う必要がある、ということを押さえておいてください。

では、ワーカプロセスのビットを切り替えるためには．．．．と進めたいところですが、その前に Visual Studio 2008 のビルド構成についても解説しておきます。

[Step. 12] Web サイトプロジェクトを含むソリューションのビルド構成設定

ASP.NET Web サイトプロジェクトを含むソリューションの場合には、ビルド構成に "Mixed Platform" や ".NET" という、見慣れない構成が出現しますが、これは以下のようなものです。

まず、コンソールアプリケーションや Windows アプリケーションのように、開発時に完全なコンパイルが行われるソリューションの場合には、コンパイル時のプラットフォームフラグとして、"Any CPU", "x86", "x64" などを指定することができます。その結果として、アプリケーションのビルド時に、動作プラットフォームを完全に決定することができます。

しかしながら、Web サイトプロジェクトの場合、前述したように、開発時に実行プラットフォームを決定することができません。このため、

Web サイトプロジェクトでは、プラットフォームが指定できず、常に ".NET" となる。
ビルド時に動作プラットフォームを完全指定することができないので、ソリューション全体のビルド構成名としては、"Mixed Platform" という特殊な名前が付与される。

となっています。

[Step. 13] IIS 6 のワーカプロセスの動作ビットモードの変更方法

では、引き続きワーカプロセスの動作ビットモードの変更方法を解説します。動作ビットモードの変更方法は、IIS 6, 7 の場合でそれぞれ異なります。

まず、IIS 6 （Windows Server 2003 x64 版）の場合には、以下の 3 つの作業により 64/32 ビットの切り替えができます。

メタベースの W3SVC/AppPools/enable32BitAppOnWin64 を変更する。
32 ビット版の w3wp.exe と 64 ビット版の w3wp.exe のどちらを使うのかを指定します。
ISAPI 拡張子の登録を変更する。
32 ビット版の aspnet_isapi.dll と 64 ビット版の aspnet_isapi.dll は個別に存在しているため、これを aspnet_regiis.exe ツールで切り替えます。
IIS サービスマネージャから ISAPI 拡張の動作許可を与える。
ASP.NET 2.0 の動作許可は、32/64 ビット個別に存在するため、こちらも個別に指定します。

     ■ 32 ビットモードに変更する場合

    C:\>cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

    C:\>%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i

    ※ 最後に IIS サービスマネージャから ASP.NET v2.0.50727 (32-bit) の動作許可を与える

    ■ 64 ビットモードに変更する場合

    C:\>cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

    C:\>%SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i

    ※ 最後に IIS サービスマネージャから ASP.NET v2.0.50727 の動作許可を与える

なお、設定に際して注意すべきこととして、IIS 6 では 64/32 ビット切り替えがサーバ全体でしかできない、という点があります。つまり、当該サーバ内に32 ビット動作を必要とする Web アプリケーションが一つでも存在する場合には、64 ビットモードに切り替えることができない、ということになります。

実はこの制限事項は非常に厳しいもので、たとえば前述した Jet OLE DB や、Oracle (MSDAORA)、ASP.NET 1.1、VB 6 ランタイム（または VB 6 で開発した COM など）はすべて 32 ビット動作が必要です。このため、サーバ内にこれらのアプリがひとつでも存在する場合には、64 ビット切り替えはできない、ということになります。（これについては後述します。）

[Step. 14] IIS 7 のワーカプロセスの動作ビットモードの変更方法

しかし IIS 7 の場合には、アプリケーションプール単位に 32 ビット／64 ビット切り替えができるので、サーバ内に 32 ビットアプリと 64 ビットアプリを共存させることが可能になります。具体的には、アプリケーションプールの「32 ビットアプリケーションの有効化」フラグを True に変えることにより、32 ビット版の w3wp.exe が利用されるようになります。

ちなみに、スクリプトによる変更も可能です。

    ■ 32 ビットモードに変更する場合

    C:\>appcmd apppool set /apppool.name:AppPool#1 /enable32BitAppOnWin64:true

    ■ 64 ビットモードに変更する場合

    C:\>appcmd apppool set /apppool.name:AppPool#1 /enable32BitAppOnWin64:false

[Step. 15] 64 ビットワーカプロセスの制限事項

さて、ここまでの解説からわかるように、64 ビット版の w3wp.exe を使う場合には、以下の制限が発生します。

64 ビット版の ISAPI 拡張しか使えない。
64 ビット版の ISAPI フィルタしか使えない。
64 ビット版のバイナリコードしか使えない。

このため、特に 32 ビットの既存アプリケーションを 64 ビットネイティブで動作させたいと思う場合には、ドライバの提供有無などについて確認する必要があります。マイクロソフトから提供されているランタイムの多くは 64 ビット・32 ビット版の両方が提供されていますが、すべてというわけではありません。また、サードパーティ製の製品の場合には、32 ビット版しか提供されていないことがしばしばあります。アプリケーションランタイムやドライバ類のすべてが 64 ビット対応していない限り、64 ビットネイティブでの動作はできない、という当たり前の点に注意してください。

MS 製品の中で、x86, x64 版のどれが提供されているのかのリストがわかりやすくまとまっていればよいのですが、なかなかいいリストがないのでさくっと作ってみるとこんな感じです。古いアプリで特にひっかかりやすいのが、ASP （Active Server Pages）そのものは 64 ビットランタイムがあるけど VB6 ランタイムには 64 ビットランタイムがない、という点です。OLE DB ドライバなどもドライバにより対応状況が違うので、十分注意するようにしてください。

[Step. 16] 開発環境において 64 ビットワーカプロセスを使いたい場合について

最後に、x64 Windows 上の開発環境で 64 ビットワーカプロセスを使いたい場合について解説しておきます。

64 ビットネイティブで動作する ASP.NET アプリケーションを作ろうと思ったとしても、Visual Studio 2008 上から Web サイトプロジェクトを実行する限り、ASP.NET 開発サーバ（← x86 版しかない）が利用されるため、32 ビットでしかアプリケーションを動作させられません。もし開発時から Web アプリを 64 ビットで動作・デバッグしたいのであれば、以下のような作業を行う必要があります。

x64 版 Windows OS （Vista が便利）を使う。
IIS 7 を使う。
ファイルシステム型開発ではなく、IIS 型開発を行う。

このようにすると、開発時から 64 ビットネイティブでの動作・デバッグが可能になります。参考までに概念図を以下に示しておきますが、Visual Studio 2008 では 64 ビットデバッグが可能になったため、VS2008 自体が 32 ビット動作していても、64 ビットで動作するアプリケーションを直接デバッグすることができます。

［本エントリのまとめ］

以上の解説をまとめると、次のようになります。

ASP.NET Web アプリケーションの実行モードは、アプリケーション側では決定できません。ワーカプロセスの動作モードにより、32 or 64 ビットどちらで動作するのかが決まります。
ASP.NET 開発サーバ（WebDev.WebServer.exe）は、x86 版しか存在しません。よって、常に 32 ビット動作になります。
IIS 6, 7 のワーカプロセス（w3wp.exe）は、x86 版と x64 版が存在します。このため、構成設定により、32 ビット動作と 64 ビット動作を切り替えることができます。
IIS 6 の場合には、サーバ全体でしか 32/64 ビット切り替えができません。IIS 7 の場合には、アプリケーションプール単位に、32/64 ビット切り替えができます。

［まとめ］

というわけで、全 3 回にわたって .NET アプリケーションの 64 ビット対応について解説してきましたが、.NET アプリケーションの場合には、MSIL と呼ばれる中間言語が絡むため、32/64 ビット両対応が可能なバイナリを作れる半面、動作がやや複雑になります。一度理解してしまえばそんなに難しい話ではないのですが、この機会にぜひ 64 ビット対応可能な .NET アプリの作り方も理解していただければと思います。

Part 2. .NET Framework 2.0 アプリケーションの 64 ビット対応

nakama — Thu, 06 Nov 2008 08:48:55 GMT

では引き続き、Part 2. のエントリでは、.NET Framework 2.0 のアプリケーションがどのようにして 64 ビット（または 32 ビット）で動作するのか、についてみていくことにします。.NET Framework では、IL （中間言語）と呼ばれるものが利用されているため、x86, x64, IA64 すべてに対応する .exe ファイルや .dll ファイルを作成することができます。にもかかわらず、Visual Studio を開くと、

……と、こんなスイッチがあるわけなのですが、いったいこれは何なのか？これを理解するためには、.NET Framework のコンパイル動作を正しく把握する必要があります。これについて以下の手順で解説していくことにします。

IL コードとネイティブコード
コンソールアプリケーションにおけるコンパイルスイッチの意味
ライブラリアプリケーションにおけるコンパイルスイッチの意味

［Step 7. IL コードとネイティブコード］

.NET Framework の開発言語である C# や VB で書いたコードは、コンパイルしてもすぐに x86 や x64 などの命令コード（ネイティブコード）には変換されません。

.NET のアプリケーションコードはまずコンパイル時に MSIL （Microsoft Intermediate Language）と呼ばれる中間言語コードに変換されます。
そして実行時に CLR ランタイムがこれをネイティブコード（x86 や x64 用の命令コード）に変換し、そして CPU 上で実行します。

このため、.NET で書かれた .exe ファイルや .dll ファイルは、x86 Windows OS 上で動作させれば 32 ビット動作し、x64 Windows OS 上で動作させれば 64 ビット動作します。つまり、ひとつのファイルで、32 / 64 ビット両方の動作をさせることができるようになっています。

［Step 8. コンソールアプリケーションにおけるコンパイルスイッチの意味］

一般に、アプリケーションプログラムが MSIL のみで記述されている、つまり完全に .NET コードのみで記述されている場合には、上記のような動作は全く問題がありません。しかし、この .NET のアプリケーションが周辺のライブラリファイルなどを利用している場合には、問題が生じることがあります。

例えば、.NET のコンソールアプリケーションが Access .mdb ファイルにアクセスするために内部で Jet OLE DB プロバイダを使っている場合を考えてみましょう。実は、Jet OLE DB プロバイダは 64 ビット版ドライバが提供されていません。このため、.NET アプリケーションが 64 ビット動作してしまうと、ドライバが見つからずにエラーが発生する、という現象が起こります。

となると、このようなコンソールアプリケーションは、x64 Windows OS 上であっても 64 ビット動作されては困る、ということになります。このような場合に利用するのが、最初に示したプラットフォームスイッチです。Visual Studio 2008 のツールバーには、下図に示すようなプラットフォームスイッチがあります。

ここから構成マネージャを開き、アクティブソリューションプラットフォームを追加していくと、CPU 名を追加していくことができます。

"Any CPU" とは、「実行時に、どのような CPU 向けのネイティブコードを作成してもよい」というスイッチです。これを指定しておくと、x86 版 Windows 上で実行したときは x86 コードに、x64 版 Windows 上で実行したときは x64 コードに変換されて実行されるようになります。
それ以外のスイッチは、「どんな環境だろうと、指定した CPU 向けのネイティブコードしか作成しちゃいけません」というスイッチです。例えば "x86" を指定しておくと、x64 版 Windows 上で実行した場合でも、強制的に x86 コードに変換されて（WOW 上で）実行されるようになります。

64 ビット版 Windows OS でも、32 ビット版の Jet OLE DB プロバイダであれば同梱されています。このため、先の Jet OLE DB プロバイダを使うアプリケーションの場合には、このスイッチとして "x86" を指定しておき、32 ビットコードに変換されるようにしておかないと、64 ビット OS 上で正しく動作させることができなくなります。

ここで留意していただきたいのは、このプラットフォームスイッチはアセンブリファイルに出力される MSIL コードそのものを変えるものではない、という点です。このプラットフォームスイッチで変更されるのは PE ヘッダ情報内のフラグである、という点に注意してください。

ですので、プラットフォームスイッチを変えなければならないのは、以下のようなケースに限られます。

64 ビット版が存在しないライブラリを使っているアプリケーション
典型的なものとしては、ODBC ドライブを使っているもの（ODBC は 32 ビット版ドライバしか存在しない）、Jet OLE DB や Excel OLE DB を使っているもの。
32 ビット版しか存在しない COM を InProc で使っているアプリケーション
例えば ADO などは 64 ビット版がちゃんと提供されていますが、サードパーティ製の COM は 32 ビット版しか提供されていないものの方が多いです。
unsafe ブロックを使っていたり、ポインタ操作（IntPtr）をしているアプリケーション
32 ビット環境での動作しか考えられていないポインタ操作などが含まれている場合には、C# や VB のみで完遂しているアプリケーションであってもプラットフォームスイッチの指定が必要です。

x86 オプションをつけないと危険なものについては、Migrating 32-bit Managed Code to 64-bit などの資料に取りまとめられていますので、こちらについても参照してみるとよいでしょう。

ちなみにこのような理由から、32 ビットマシンや 32 ビット OS を使っている場合であっても、64 ビット C# アプリケーションのコンパイルができます。なぜなら、単にヘッダ情報を "x64" として MSIL コードを出力するだけだからです。（もちろん、出力された .exe ファイルは 32 ビット OS 上では動作しませんが。）

［Step 9. ライブラリアプリケーションにおけるコンパイルスイッチの意味］

上記の解説を踏まえれば、ライブラリアプリケーション（dll ファイル）におけるスイッチの意味についても明らかです。このスイッチは、要するにどのようなプロセスからこの dll ファイルを利用してよいのか、を規定するものになります。

例えば、下図のように Jet OLE DB プロバイダを利用するクラスライブラリ（dll ファイル）をコンパイルする場合には、"x86" オプションをつけておくべきです。なぜなら、64 ビットプロセスがこの dll ファイルを呼び出しても、正しく動作することができないからです。

当たり前のことですが、.dll ファイルは、プロセスからロードされて利用されるライブラリです。なので、クラスライブラリ側に、プロセスの動作モード（32 ビット／64 ビット）を切り替える権利や機能はありません。最初に .exe ファイルを起動した時点で、プロセスの動作モード（32 or 64 ビット）はすでに決定しており、そこから呼び出せるかどうかが .dll ファイルのスイッチにより決定されます。以下に、.exe ファイルと .dll ファイルのスイッチの組み合わせ例を示しますので、じっくり見てみてください。

［Step. 10］動作モードやヘッダフラグの確認方法

なお、アプリケーションの内部から、現在自分が 64 ビット／32 ビットどちらで動作しているのかを知る一番簡単な方法は、IntPtr.Size プロパティをチェックするというものです。

IntPtr.Size = 8 の場合は 64 ビットモードでプロセスが動作している。
IntPtr.Size = 4 の場合は 32 ビットモードでプロセスが動作している。

この方法では、x64, IA-64 の区別はつきませんが、通常はこれで十分でしょう。（どうしてもそこまで切り分けたい場合には、GetSystemInfo() Win32 API を利用します。）

また、PE ヘッダの確認を行う場合には、Windows SDK に含まれる CorFlags.exe ツールを利用します。これを利用すると、Any CPU, x86, x64/Itanuim などのいずれのヘッダを持つのかを比較的簡単に見分けることができます。（この中の PE, 32BIT フラグに着目します。こちらの方法も x64, Itanium を見分けられないのがちょっと残念な感じですが；）

     C:\>corflags "C:\Documents and Settings\nakama\My Documents\Visual Studio 2005\P

    rojects\ConsoleApplication1\ClassLibrary1\bin\x86\Debug\ClassLibrary1.dll"

    Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  2.0.50727.42

    Copyright (c) Microsoft Corporation.  All rights reserved.

    Version   : v2.0.50727

    CLR Header: 2.5

    PE        : PE32

    CorFlags  : 3

    ILONLY    : 1

    32BIT     : 1

    Signed    : 0

［ここまでのまとめ］

では、今回のエントリのポイントの復習です。

.NET アプリケーションのアセンブリファイルは、実行時にネイティブコードに変換されます。このため、x64, x86 の両方に対応するアセンブリファイルを作成することができます。
既定値である Any CPU 設定でコンパイルを行うと、実行時に x86, x64 のどちらのネイティブコードも生成してくれます。
C# や VB のコードのみで完結しているアプリケーションであれば 32, 64 ビットどちらでも動作できますが、Unmanaged ライブラリを呼び出している場合（Jet OLE DB など）には、x64, x86 の両方に対応できないアプリケーションとなる場合があります。
特定プラットフォームでしか動作しないアプリケーションを作成する場合には、コンパイルプション（x86, x64 など）により、ヘッダ部に情報を付与しておく必要があります。
プロセスタイプは、プロセスの起動時に決定されます。このため、例えばコンソールアプリ（.exe）からライブラリ（.dll）を呼び出す場合、プロセスタイプはコンソールアプリ起動時に決定されます。

と、長々と書きましたが、要点をまとめるとたったひとつです。

「特定プラットフォームでしか動作しないモジュールを作る場合には、必ず x86, x64 などのオプションをつけてコンパイルすること」

この一点だけをちゃんと守ってもらえれば OK です。

……がしかし、IIS 上で動作する ASP.NET アプリケーションの場合はちょっと話が複雑になります。これについては次回のエントリにて^^。

Part 1. 64 ビット Windows OS の基本知識

nakama — Thu, 30 Oct 2008 13:35:35 GMT

さて、現在のデスクトップ向けの Intel 系主流 CPU は Core2 Duo や Core2 Quad ですが、こうした現在の主流の CPU はほぼすべてが 64 ビット CPU になっています。64 ビット CPU 自体の歴史は長く、2003 年頃から CPU が、そして 2005 年頃から OS も 64 ビット版が出荷されていました。対応する CPU やデバイスドライバの問題などから（少なくともコンシューマユースでは）なかなか普及が進まなかったのですが、さすがに現在にもなると、OS はもとよりデバイスドライバも 64 ビット版のものが非常に入手しやすくなっており、いよいよ 64 ビット環境が使いやすくなってきました。

また、アプリケーション開発環境でも .NET Framework 2.0 が 64 ビット対応を行ったことで、64 ビットネイティブアプリケーションの開発というものが容易になってきました。とはいえ、.NET Framework は中間言語（IL）と呼ばれる仕組みを使うため、64 ビット対応の仕掛けはやや複雑です。そこで最初のエントリでは、64 ビット Windows OS の基本知識として、以下のようなポイントをまとめておきたいと思います。

x86, x64, IA64 の違い
Windows OS の種類
64 ビットプロセスと 32 ビットプロセス（WOW64）
DLL ファイルのロードメカニズム
x64 版 Windows OS のフォルダ構造
x64 版 Windows 上での Visual Studio 2008 の利用

［Step 1. x86, x64, IA64 の違い］

現在の PC 市場向けの CPU は、x86 系、x64 系、IA64 系の 3 種類に大別されます。正確な CPU の型番情報は Wikipedia などが詳しいですが、キーポイントは以下の通りです。

少し前に使われていた Pentium 4 や Core Duo（無印）などは、x86 と呼ばれる 32 ビット系 CPU です。
最近使われている Core2 Duo や Athron64 などは、x64 と呼ばれる 64 ビット系 CPU です。
サーバ市場向けに使われている CPU である Itanium 2 などは、IA64 と呼ばれる 64 ビット系 CPU になります。
64 ビット系 CPU は、x64 と IA64 の 2 種類が存在することになります。しかし、IA64 はサーバ市場向け CPU （＝めっちゃ高い）、ということになりますので、今回の説明からは割愛します。

なお、64 ビット系 CPU の中でも、x64 系は、x86 系の上位互換となっているのが大きな特徴です。IA64 系の 64ビット CPU は、x86 系との命令の互換性に乏しく、既存の x86 系アプリケーション（＝32 ビットアプリケーション）が動作しないことが多いです。

［Step 2. Windows OS の対応 CPU］

基本的に、x86, x64, IA64 は CPU レベルでは異なるもの（＝異なるハードウェア）です。このため、利用する Windows OS も、x86 版、x64 版、IA64 版がそれぞれ存在します。例えば Windows Server 2008 の場合には、

Windows Server 2008 x86 版（32 ビット版）
Windows Server 2008 x64 版（64 ビット版その１）
Windows Server 2008 IA64 版（64 ビット版その２）

という 3 種類が存在しています。ただし、先に述べたように、IA64 はサーバ系マシンでしか使われていないため、クライアント系 OS である Windows Vista の場合には、

Windows Vista x86 版（32 ビット版）
Windows Vista x64 版（64 ビット版）

の 2 種類のみが提供されています。

ここで重要なのは、x64 系 CPU が x86 系 CPU の上位互換 CPU として設計されている、という点です。このため、Core2 Duo や Athron 64 などを搭載したマシン（＝x64 マシン）に、32 ビット版の Windows OS （例えば Windows Vista x86 版）などをインストールして使うことができます。このようにすると、x64 CPU を x86 CPU と全く同じように使うことができる、というわけです。もし 64 ビット OS の機能が特に要らないのであれば、x64 マシンに x86 版 OS をインストールして使ってもよい、ということになります。

※ ちなみに IA-64 マシンに x86 版の OS をインストールすることはできません。

［Step 3. 64 ビットプロセスと 32 ビットプロセス］

我々が利用するアプリケーションプログラムのファイル（.exe ファイル）の中には、通常、CPU が実行するバイナリ実行コードがそのまま格納されています。このため、

x86 系の命令で書かれた .exe ファイルは、x86 系 CPU + x86 系 OS の上でしか動作しない。
x64 系の命令で書かれた .exe ファイルは、x64 系 CPU + x64 系 OS の上でしか動作しない。
IA64 系の命令で書かれた .exe ファイルは、IA64 系 CPU + IA64 系 OS の上でしか動作しない。

となります。しかしこれでは、64 ビット OS に移行したとたんに、過去に作成された資産（x86 系 .exe アプリケーション）が一つ残らず使えなくなってしまいます。これでは困るので、64ビット版 Windows OS では、WOW64 （Windows 32bit on Windows 64bit）と呼ばれるエミュレータ機能を提供しています。

下記がその概念図です。x64 版 Windows OS には x64 用 WOW64 が、IA64 版 Windows OS には IA64 用 WOW64 が付属しています。このため、x64 版 Windows または IA64 版 Windows 上でも、x86 版のアプリケーションをエミュレーション動作させることができるようになっています。

※ このエミュレーション動作は当然のことながらすべての x86 版アプリケーションの動作を保障する、という類のものではありません。特に IA64 版 Windows 上での x86 版アプリケーションの動作互換性は必ずしも高くはないようです。しかし、x64 版 Windows 上での x86 版アプリケーションの動作互換性はかなり高いです。このページなどを参照してみるとよいかと思いますが、概してデバイスドライバが絡むものは互換性が低いです。（← デバイスドライバは OS のカーネル部で動作するので、32 ビット版のデバイスドライバは 64 ビット版 OS では決して使えない）．．．．というか結構びっくりするのはゲーム類ですらほとんどのものは動作する、という点ですね。

では、ここまでの確認をする意味で、SQL Server 2008 を例に取って解説したいと思います。

まず、SQL Server 2008 には、以下の 3 つのバージョンがあります。

SQL Server 2008 x86 版
SQL Server 2008 x64 版
SQL Server 2008 IA64 版（← SQL Server 2008 Express Edition では提供されてませんが）

そして、それぞれは以下の環境で動作させることができます。

① SQL Server 2008 x86 版

x86 系 CPU マシン（Pentium 4 マシンなど）上に Windows OS x86 版を乗せ、そこにインストールする。（この場合は 32 ビットネイティブ動作）
x64 系 CPU マシン（Core 2 Duo マシンなど）上に Windows OS x86 版を乗せ、そこにインストール。（この場合は CPU が 32 ビットモードで動作するので、Windows OS も SQL Server も 32 ビットネイティブ動作になる。）
x64 系 CPU マシン（Core 2 Duo マシンなど）上に Windows OS x64 版を乗せ、そこにインストール。（この場合は OS は 64 ビット動作、SQL Server は WOW64 上で 32 ビットエミュレーション動作になる。）

② SQL Server 2008 x64 版

x64 系 CPU マシン（Core 2 Duo マシンなど）上に Windows OS x64 版を乗せ、そこにインストールした場合のみ動作。（この場合は Windows OS も SQL Server も 64 ビット動作。）

③ SQL Server 2008 IA64 版

IA64 系 CPU マシン（Itanium2 マシンなど）上に Windows OS IA64 版を乗せ、そこにインストールした場合のみ動作。（この場合は Windows OS も SQL Server も 64 ビット動作。）

これからわかるように、32 ビット版アプリケーションはいろんな環境で動作させることができる、という点を覚えておいてください。逆に、x64 版、あるいは IA64 版のアプリケーションは、CPU/OS ともに同じ環境でなければ動作させることができません。

ちなみにこうした理由から、例えば Office 2007 （Word や Excel）は x86 版バイナリしか提供されていません。しかし、これを x64 版 Windows Vista 上で動作させて利用することは普通にできます。

なお、ここで気をつけておきたいのは x64 版 Windows 上で大半の x86 アプリが動作するとしても、それが公式にサポート対象となっているかどうかは話が別、という点です。例えば、

Office 2007 （x86 版のみ提供） → 一部アプリを除き、x64 版 Windows 上での動作をサポート。
.NET Framework 1.0 → x64, IA64 版 Windows 上での動作は非サポート。
.NET Framework 1.1 → x64, IA64 版 Windows 上での動作をサポート。
.NET Framework 2.0 x86 版 → x64, IA64 版 Windows 上での動作をサポート。

となっています。特にゲームなどでは、動作はするけどサポートはしていない場合がほとんどで、上記のページも自己責任でアプリを動かしているはずです。このことは、特にサポートが重要視される業務アプリケーション開発などでは大問題になるケースがありますので、サードパーティ製のライブラリを利用しているような場合には、x64 版 Windows OS 上での動作がサポート対象となるのか否かを確認するようにしてください。

なお、64 ビット OS 上で、あるプロセスが 64 ビットネイティブモード／32 ビット互換モードのどちらで動作しているのかは、タスクマネージャを見るとすぐに判別できるようになっています。

また、ある .exe ファイルを 64/32 ビットどちらで起動すればよいのかに関しては、Windows OS が自動的判定するようになっています。64 ビット版 Windows OS は、.exe ファイルを起動する際に、.exe ファイルのヘッダ情報（PE ヘッダ）を確認し、それにより、.exe ファイル内のバイナリコードが x86, x64, IA64 のいずれのものであるのかを判別します。そして適切なプロセスを起動する、という流れになっているため、ユーザが起動時に 32/64 ビットどちらで起動するのかを指定する必要はありません（し、できません）。

※ 言い換えると、PE ヘッダ部に誤った情報が書かれていると、間違ったビット数でのアプリ起動を行ってしまい、クラッシュすることになります。このため、.exe ファイル作成時（＝アプリケーションのコンパイル時）に正しい PE ヘッダを作成することが重要です。これは Part. 2 以降で解説します。

［Step 4. DLL ファイルのロードメカニズム］

64/32 ビットを考える上でもう一つチェックしておきたいのが、DLL ファイルのロードです。一般的に、Windows OS では、.exe ファイル（アプリケーション本体）が利用する拡張ライブラリを、.dll ファイルとして作成しておき、これをアプリケーションプロセスが動的に読み込んで利用します。（このため DLL = Dynamic Link Library と呼ばれている）が、.exe ファイルと同様に、この .dll ファイルの中身は実行バイナリです。このため、.dll ファイルにも x86 版、x64 版、IA64 版の区別が存在します。そして、.dll ファイルに関しては、ひとつのプロセスの中に同じタイプのものしか共存させることができない、というルールが存在しています。簡単にいえば、下図のように、64 ビットプロセスの中に 32 ビット DLL ファイルをロードしたり、32 ビットプロセスの中に 64 ビット DLL ファイルをロードしたりすることはできません。

こうした理由から、64 ビット版 Windows OS では、Internet Explorer について 32 ビット版と 64 ビット版の 2 種類が提供されています。例えば Silverlight や Flash といったブラウザのプラグインの多くは 32 ビット版のバイナリしか提供されておらず、これらは 64 ビット版の IE では利用できません。このため、64 ビット版 Windows OS では 2 種類の IE が提供されています。

［Step 5. x64 版 Windows OS のフォルダ構造］

では引き続き、x64 版 Windows OS のフォルダ構造を眺めてみます。x64 版 Windows OS では、64, 32 ビットのアプリケーションプログラムがうまく共存動作できるように、フォルダやレジストリなどがきれいに構造化されています。

GAC 内

フォルダ構造を見ると、いくつかの特徴があることがわかります。

Program Files については、x86 版アプリケーション用のフォルダと、x64 版アプリケーション用のフォルダが別々に用意されている。
GAC については、x86, x64 共通で一つのフォルダになっている。（※ GAC は、内部に x86 版 dll, x64 版 dll を共存させておくことができるようになっているため。AMD64 = x64 です。）
.NET Framework については、x86 版、x64 版が両方インストールされている。
システムフォルダについても、x86 版（SysWOW64）と、x64 版（system32）の 2 つが用意されている。

※ システムフォルダについてはここでは話が複雑になるので解説しません。興味がある方は別途 SysWOW64 について書かれた資料を探してみてください。

なお、一点注意していただきたいのは、Program Files フォルダです。64 ビット版 Windows には、2 つの Program Files フォルダができますが、このフォルダは、64/32 ビットどちらでアプリを起動するのかの判定に使われているわけではありません。アプリケーションを 64/32 ビットどちらで起動するのかは PE ヘッダー情報に基づいて行われており、フォルダ名に基づいて行われているわけではありません。あくまでこれらのフォルダは、ユーザの便宜のため（＝わかりやすくするため）だけに使われていますので、x86 版のアプリケーションを、x64 用フォルダ（Program Files）下にインストールしても、動作上の不具合は特に発生しません。

［Step 6. x64 版 Windows 上での Visual Studio 2008 の利用］

では、最後に Visual Studio 2008 上で x64 版のアプリケーションを開発する方法について考えてみましょう。Visual Studio 2008 で x64 版アプリケーションを開発する場合、開発環境の選択としては以下の 2 通りがあります。

x86 版 Windows OS 上に、Visual Studio 2008 を入れて開発を行う。
x64 版 Windows OS 上に、Visual Studio 2008 を入れて開発を行う。

前者の方法の場合、x86 版 Windows OS （32 ビット OS）上では 32 ビットのアプリしか動かせませんので、64 ビット OS 上での動作検証をするためには、リコンパイルやコピーを行い、64 ビット OS 上での動作確認を再度行わなければいけません。

しかし、右図のように 64 ビット OS 上に Visual Studio 2008 をインストールすれば、64 ビットのネイティブアプリが動作させられるので、直接 64 ビットアプリを開発してデバッグできる……と単純に考えると危険です。その理由は、Visual Studo 2008 は、x86 版しか提供されていないからです。

つまり、たとえば Visual Studio 2008 上で Web アプリケーションを開発してデスクトップで動作させた場合には、

Visual Studio 2008 → WOW 上の 32 ビット動作
SQL Server 2005 Express Edition → WOW 上の 32 ビット動作
ASP.NET 開発サーバ → WOW 上の 32 ビット動作
Internet Explorer → 既定では 32 ビット版の IE が使われる。

ということになり、なんにも考えずに動かすと、実はあらゆるものが 32 ビット動作する、ということになります。

このため、64 ビットアプリケーションを開発したいと思った場合でも、x64 版 Windows 上に Visual Studio 2008 をインストールすれば OK、なんていう単純な話ではない、というところに関しては注意が必要です。これについて解説．．．．していきますが、長くなったので Part 1. はいったんここまで、ということで^^。

［ここまでのまとめ］

64 ビット CPU には、x64 系と IA64 系がある。32 ビット CPU である x86 系と互換性が高く、現在の PC 向け CPU メインストリームで使われているのは、x64 である。
x64 CPU の代表例は、Core2 Duo や Athron 64 である。
x64 CPU は、x86 CPU として使うこともできる。つまり、x64 CPU 上に x86 版 Windows OS をインストールすると、従来の 32 ビット CPU と全く同じ動作をさせることができる。
x64 CPU 上に x64 版 Windows OS をインストールし、x64 バイナリコードで書かれた .exe ファイルを実行すると、64 ビットネイティブでアプリが動作する。
x64 CPU 上に x64 版 Windows OS をインストールし、x86 バイナリコードで書かれた .exe ファイルを実行すると、WOW64 上で 32 ビットエミュレーションモードでアプリが動作する。
x64 コードと x86 コードが同一プロセス内に共存することはできない。

引き続き次回は、.NET Framework 2.0 による 64 ビットアプリの開発についてみていきたいと思います。

.NET Framework アプリケーションの 64bit 対応

nakama — Thu, 30 Oct 2008 12:35:05 GMT

さて、次は何のネタを書こうかなぁと迷っていたのですが、そういえばこの blog を書いている自分のマシンは Windows Vista の 64bit 版。Lenovo ThinkPad X60 （Core2Duo）のマシンに 64bit 版 Vista を入れているのですが、64bit OS はまだ使われたことがない、という方も多いんじゃないでしょうか？私もなんだかんだと理由をつけて（笑）、なかなか 32bit 環境から移行してこなかったのですが、さすがに仕事でも 64bit OS を使う機会が増えてきたり、あるいはいくつかのアプリケーションは 64bit 版しか提供されない、といった形になってくると、64bit OS を食わず嫌いで通すわけにもいかなくなってきました。

一年ほど前に .NET Framework の 64 ビット対応とは何なのか、ということを調べようと思ったところ、意外にきれいに情報がまとまっているものが少なくて苦戦したので、エンジニアとして知っておくべき 64bit OS の基本をまとめたいと思います。

なお、.NET Framework アプリケーションの 64ビット対応を考える上では、そもそも 64 ビット OS とは何か、という点を理解することが重要です。このため、このエントリではまず OS 一般の話、そしてそのあとに .NET Framework の話、と 2 段階に分けて解説したいと思います。

■ Part 1. 64 ビット Windows OS の基本知識

x86, x64, IA64 の違い
64 ビットプロセスと 32 ビットプロセス
WOW64
x64 版 Windows OS のフォルダ構造
x64 版 Windows 上での Visual Studio 2008 の動作

■ Part 2. .NET Framework 2.0 アプリケーションの 64 ビット対応

IL コードとネイティブコード
コンソールアプリケーションの場合
ライブラリアプリケーションの場合

■ Part 3. ASP.NET 2.0 Web アプリケーションの 64 ビット対応

64 ビット／32 ビット動作の決定メカニズム
IIS 6, 7 の動作ビットモードの変更方法
64 ビットワーカプロセスの制限事項
開発環境において 64 ビットワーカプロセスを使いたい場合について

ではでは、順番に見ていくことにしましょう。:-)