Windows アプリケーションに限った話です。
私は、[Windows 95]以来ずっと、32ビット版OS(オペレーティングシステム)を使ってきました。
今調べるとWindows XPにも64ビット版があったようですが、ごく最近までそのことさえ知りませんでした。
Windows 7の発売以来、64ビット版のOSが普及してきましたので、アプリケーションも64ビット版への対応が必要になってきました。
この度64ビット版への対応を勉強しましたのでご報告いたします。
マイクロソフトが提供するWindows開発ツールは[Visual Studio]です。[Visual Studio]は32ビットOSでも64ビットOSでも同じように動作します。
[Visual Studio]で32ビットあるいは64ビット用のアプリケーションを作成するのですが、その方法は、ビルドするときにコンパイルスイッチを、[x86]、[x64]あるいは[AnyCPU]の何れかに設定するだけです。ここでひとつ理解しておかなければいけないことがあります。
Visual Studioでビルドしたものを、ターゲットマシンにインストールするのですが、Visual Studioの出力は、機械語ではなく、[IL]という中間言語だということです。
この中間言語ファイルの中身は32ビット版/64ビット版共通なのです。ただ違うのはこのファイルのREというヘッダに、[x86]、[x64]あるいは[AnyCPU]の異なる情報が付加されていることです。
ターゲットマシンでこのアプリケーションを実行するとき、.NET実行環境は、[x86]ファイルは32ビット機械語に、[x64]ファイルは64ビット機械語に、[AnyCPU]ファイルは、32ビットOSなら32ビット機械語に、64ビットOSなら64ビット機械語に翻訳しようとします。
ターゲットマシンが32ビットOSのときは、64ビット機械語にすることも、実行することもできませんので、64ビット（x64）指定のアプリケーションは動作しません。
逆に、64ビットマシンでは、32ビットプログラムも64ビットプログラムも動作しますので、上の何れのコンパイル（機械語化）も問題ないように思われますが、ここにも問題があります。
通常私たちが開発するプログラムは、自分のコードだけで完結することはありません。マイクロソフトやサードパーティーの様々なプログラム(ライブラリ、Dll)を利用しながら、アプリケーションを開発していきます。
すべてのライブラリのコンパイルスイッチが、同じ設定であれば問題ないのですが、[x86]と[x64]の混在は許されません。
アプリケーションを[x86]でビルドし、64ビットOSで起動しようとしたとき、ライブラリの一つでも[x64]や[AnyCPU]でビルドされていると動作しません。
すべてのプログラムが[AnyCPU]でビルドされたいれば、問題ないようにおもわれますが、ここにも問題があります。
アプリケーションでWordやExcel等のOfficeを使うことがあります。
殆どすべてのユーザのコンピュータ（ターゲットマシン）には、既にOfficeがインストールされ使われています。64ビットOSでも32版のOfficeをインストールできますし正常に動作します。もしユーザの64ビットOSコンピュータに32ビットOffeceがインストールされていると、問題が生じます。
アプリケーションからこの32ビットOfficeを使いたい場合は、アプリケーションそのものを[x86]でビルドしなければ、いけません。
ところが、
アプリケーションで利用したサードパーティのライブラリが[AnyCPU]や[x64]でビルドされていると、64ビットOSはこの部分を64ビット機械語に翻訳しようとしますので、32ビット/64ビット機械語の混在になり、動作しません。
もう一つ考えられる逃げは、アプリケーションはインストールされているOfficeを使わないで、アプリケーションが必要とする[Runtime]を別途インストールすればいいのではないかということです。マイクロソフトは32ビットおよび64ビット[RunTime]を無償で提供していますので、[x64]あるいは[AnyCPU]でアプリケーションを作成しておいて、必要な[RunTIme]をインストールすれば解決するように思われますが、これができません。
すでに32ビット版のOfficeがインストールされている環境に、64ビット版のOffice RunTimeはインストールできないのです。
結局、
「ターゲットマシンが64ビットOSで、32ビットOfficeがインストールされている環境では、Officeとサードーパーティのライブラリを使ったアプリケーションは動作しない可能性が大きい」というのが結論と思われます。
