64ビットWindowsに個別の「Program Files（x86）」フォルダーが必要なのはなぜですか？

64ビットバージョンのWindowsでは、「Program Files」フォルダーは64ビットプログラム用であり、「Program Files（x86）」フォルダーは32ビットプログラム用であることを知っていますが、なぜこれが必要なのですか？

「必要」とは、「Microsoftが他の設計上の決定を下すことができなかったのはなぜですか」という意味ではありません。もちろん、彼らが持つことができたからです。むしろ、「64ビットWindowsの現在の設計を考えると、32ビットプログラムには64ビットプログラムとは別の最上位フォルダーが必要なのはなぜですか」という意味です。別の言い方をすれば、「リダイレクトメカニズムをどうにかして回避し、すべてを強制的に本物にインストールするとC:\Program Files\どうなるのでしょうか？」

スーパーユーザーやその他の場所には、「1つは32ビットプログラム用、1つは64ビットプログラム用」と主張する多くの質問がありますが、理由はわかりません。私の経験から、32ビットプログラムが正しい場所にインストールされているかどうかは問題ではないようです。

Windowsは、「Program Files（x86）」を使い果たしたプログラムとはどういうわけか、それ自体を異なって提示しますか？「Program Files」ではなく「Program Files（x86）」にインストールされたプログラムの違いを正確に示す説明はありますか？Microsoftが正当な技術的理由なしに新しいフォルダを導入することはまずないと思います。

簡単な答え：従来の32ビットアプリケーションが、永続的な混乱を引き起こす64ビットアプリケーションにonいルールを課すことなく、従来と同じように機能し続けることを保証するため。

それは必要ない。すべてのアプリケーションが32ビットDLLおよび実行可能ファイルを64ビットDLLおよび実行可能ファイルから分離する独自の方法を作成する必要があるなど、他の可能なソリューションよりも便利です。

主な理由は、64ビットDLLがアプリケーションが見える場所にインストールされていても、64ビットシステムが存在することすら知らない32ビットアプリケーションを「動作させる」ことです。32ビットアプリケーションは64ビットDLLをロードできないため、32ビットアプリケーション（64ビットシステムより前の日付であり、したがって64ビットファイルがわからない可能性があることを確認する方法が必要でした。存在する場合でも）64ビットDLLを見つけられず、ロードしようとして失敗し、エラーメッセージを生成します。

これに対する最も簡単な解決策は、一貫して別々のディレクトリです。本当に唯一の選択肢は、すべての64ビットアプリケーションに、bin64そのアプリケーション内のディレクトリなど、32ビットアプリケーションが見えない場所で実行可能ファイルを「隠す」ことです。しかし、それは、レガシーアプリケーションをサポートするためだけに、64ビットシステムに永続的なさを課します。

アプリケーションを上書きせずに、アプリケーションの32ビットバージョンと64ビットバージョンの両方をインストールできます。

翌日、この回答とコメントスレッドを見た後、回答に重大な見落としがある可能性があることに気付きました。私は誤ってプログラミングの背景を仮定し、私のコメントであなたについて話していたとき、私はユーザーではなくプログラマーを意味していました。

私はマイクロソフトのために働いておらず、これらのフォルダーの背後にある本当の理由が何であるか見当がつきませんが、これらのフォルダーを持っている理由は私がそれを主張する問題がないほど明白だと思います。

それでは分解しましょう！

1. フォルダは素晴らしいです！

   何かに同意しましょう。フォルダーは素晴らしいです！それらは必要ありません。すべてのファイルをハードドライブのルートに配置するのに十分なファイル名があるので、なぜフォルダーがあるのでしょうか。

   まあ、彼らは私たちのものを注文するのに役立ちます。そして、注文品は素晴らしいです。物事をより簡単に処理するのに役立ちます。これは、構造が必要なマシンで作業するときに特に役立ちます。

2. データとロジックを分離するのは素晴らしいことです！

   プログラミングでよく見られるパラダイムは、ロジックからデータを分離することです。あなたは1つのパートたい知っているどのように何かをするために、あなたが他の部品たい何かを行うことができてを。

   これはファイルシステムにもあります。

   アプリケーション用のフォルダー（ロジック）と貴重品用のフォルダー（データ）があります。

   論理

   • %WINDIR%
   • %PROGRAMFILES%
   • %PROGRAMFILES(x86)%

   データ

   • %PROGRAMDATA%
   • %HOMEDRIVE%%HOMEPATH%

   したがって、フォルダは素晴らしいようで、プログラムを独自の小さなフォルダに入れるのが理にかなっています。しかし、なぜ2つあるのでしょうか？インストーラーにそれを処理させ、すべてを1つのProgramsフォルダーに入れてみませんか？

3. インストーラーは魔法ではありません

   今日では、小さなプログラムを使用して大きなプログラムをインストールすることがよくあります。これらの小さなプログラムをインストーラーと呼びます。

   インストーラーは魔法ではありません。それらはプログラマーによって書かれる必要があり、他のアプリケーションと同様のアプリケーション（バグの可能性がある）です。それでは、架空のプログラマが直面しなければならない状況を見てみましょうととせずに、現在のシステム：

   1 Program Filesフォルダー

   開発者は2つのインストーラーを管理しています。1つは32ビット版で、もう1つは彼のアプリケーションの64ビット版です。32ビットインストーラーが書き込みC:\Program Files\App\、64ビットインストーラーが書き込みC:\Program Files\App\sixtyfour\ます。

   2プログラムファイルフォルダー

   開発者は1つのインストーラーを保守します。インストーラは常にに書き込みます%PROGRAMFILES%し、（あなたが実際にこれらのケースのための環境変数を使用していない、あなたが使用したい応じてパスを展開するオペレーティングシステムに依存SHGetKnownFolderPathをしてFOLDERID_ProgramFiles正しいパスを取得するため）。
   すべてが自動的に場所を見つけ、パターンはインストールするすべてのアプリケーションと同一です。

4. 一貫性は理にかなっています

   何かを学ぶとき、それは通常、観察された行動が一貫していたことを意味します。それ以外の場合は、観察して学ぶことは本当にありません。

   同じことは、小さなファイルシステムにも当てはまります。常に同じものを同じフォルダに入れるのは理にかなっています。そうすれば、何かを探しているときにどこを見るべきかがわかります。

   32/64アプリケーションを区別するシステムは、この目標をさらに促進します。アプリケーションは、名前の競合、バイナリのロード動作、およびセキュリティ（ある程度）を避けるために2つの場所に分けられます。

まだわかりません。これは役に立たないようです

忘れないでください。人々は非常に愚かです。これには、ユーザー、スーパーユーザー、特にプログラマーが含まれます。

これが、システムを使用可能にするためにもファイルシステムのリダイレクトなどが必要な理由です。

プログラマーはそこに入り、ロードしようとしますC:\Windows\system32\awesome.dllが、32ビットシステムで実行しているか64ビットシステムで実行しているかは気にしません。64ビットDLLをロードしようとすると、単にクラッシュします。一部のプログラマは、Office DLLを使用したいのですが、問題はありません。C:\Program Files\Microsoft\Office\14.0\wizards.dll...そして別のクラッシュ！

32ビットアプリケーションによるこれらすべての要求は、アプリケーションのクラッシュを回避するために、32ビットの対応するものにリダイレクトされます。

このようなシステムを構築するには、いくつかの固定フォルダー名が必要です。このリダイレクトをサポートするフォルダー構造がない場合、どのように機能させますか？

さて、今私はそれを得る。しかし、なぜ使用しないのC:\Program Files\x86\ですか？

今、私たちは哲学的になっています...

リダイレクトメカニズムをどうにかして回避し、すべてを強制的に実際にインストールした場合、何が問題になりC:\Program Files\ますか？

ほとんどの場合、何もありません（他のアプリケーションがそのアプリケーションの固定された場所に依存しない限り）。

WOW64の機構のフックにCreateProcess、それが32または64ビットであるかどうかを決定するために実行可能なイメージに（実行可能ファイルのフォルダ名を確認するよりも、より洗練された）より高度なチェックを実行します。

ええ、でもすべてのアプリケーションが好きです！

• 車にディーゼルとガスの両方を入れるとどうなりますか？
• 同じラインで交流と直流の両方を使用しようとするとどうなりますか？
• 私は続ける場合はどうなるでしょう、両方同じ水槽の中で私の猫と私の魚を？

一部の質問には回答が不要です。実行することを意図したものではありません。実行しないでください。ここで得られるものは何もありません。このような変更が引き起こす可能性のある問題の量は、誰かがこれで目にする可能性のある利点を常に上回るでしょう。

TL; DR：

要約すると、いや、それは必要ではありません。彼らは可能性があり、単一のフォルダを使用している、といや、Windowsの1つの場所または別から実行されているプログラムとは異なっ自体を提示していません。

まあ、誰もがこれについて彼らの意見を投げているようですので、私は私の2¢を投げます。他の人は、 Microsoftが32ビット版と64ビット版のプログラム用に別々のトップレベルのフォルダを作成することを選んだ理由についてすでに推測しているので、その部分は残しておきます（最良の理由は、それがプログラマの利便性）。もちろん、それでも、なぜこれが必要なのかという直接的な質問にはまったく対応していませんか？、これに答えはおそらくです：それはありません。

代わりに、質問の本文を取り上げます

Windowsは、「Program Files（x86）」を使い果たしたプログラムとはどういうわけか、それ自体を異なって提示しますか？

実際はそうではありませんが、プログラムの場所は動作に影響を与える可能性がありますが、あなたが考える方法には影響しません。

プログラムを実行すると、Windowsはそれを実行する環境を設定します（環境変数だけでなく、メモリ、アドレス指定などの点で）。この環境は、実行可能ファイルの内容に依存します（32ビットプログラムと64ビットプログラムは内部的に異なります）。64ビットシステムで32ビットプログラムを実行すると、32ビット環境をエミュレートする32ビットサブシステムで実行されます。これはWoW64と呼ばれ（WoW64はWindows 64ビット上のWindowsを表します）、NTVDMを使用してXPで16ビットアプリを実行する方法に似ています。

管理者権限の有無にかかわらずプログラムを実行すると、実行方法に影響しますが、場所はプログラムに影響しません（たとえば、一部のドライバーのような場所の依存関係の例があります）。

答えながら（他の日、私は別のコンピュータを使用していますので、私は私のステップを後戻りするために私のブラウザの履歴に頼ることはできませんが、このSUの質問私はで終わったこのSO質問に私を引き起こしたGoogleのPROCESSOR_ARCHITEW6432につながり、このSO質問とをこのMicrosoftブログ投稿。

途中のどこかで%processor_architecutre% 、コマンドプロンプトを実行した場所に応じて環境変数が異なる結果を与える方法についてStackOverflowの投稿を読みました（正確な引用符を見つけようとします）。

答えは、コマンドプロンプトの32ビットバージョンと64ビットバージョンのどちらが実行されたSystem32\か（つまり、またはSysWoW64\）によるものであることが判明しました。つまり、場所はプログラムの動作に影響を与えるように見えますが、それはWindowsが特別な方法でフォルダを処理するためではなく、プログラムの異なるバージョンがあるためです。

実行可能ファイルの内容が32ビットか64ビットかを指示するため、これは理にかなっています。したがって、同じプログラム（foobar32.exeおよびなどfoobar64.exe）の32ビットと64ビットの両方のコピーを同じフォルダーに、それらを実行すると、それらは正しくロードされます（64ビットバージョンはネイティブに実行され、32ビットバージョンはWoW64エミュレーションレイヤーで実行されます）。

FreePascalを使用すると、DOSバージョンとWindowsバージョンの両方をインストールでき、同じフォルダーに保存されます%programfiles%\FreePascal。これは、（実行可能ファイルを保つことによって異なるアーキテクチャを管理し.exe、.sys、.dll、.ovrなど、ソース・ファイル、）これはまた、32ビットとするために行われなかったことを技術的な理由はありませんが、別のフォルダに、など）及び写真のようにリソースファイルを共有しますプログラムの64ビットバージョン。デビッドが言ったように、プログラマーが別々に保たれていると簡単です（つまり、変数を使用して、ファイルのセットが1つしかないように見せることなど）。

もう1つの理由は、ほとんどのプログラムが％PROGRAMFILES％などの環境変数を使用して、プログラムがインストールされた場所を指すために使用されることです。64ビットプログラムの場合、通常の場所に移動します。32ビットプログラムの場合、新しいProgram Files (x86)フォルダーにリダイレクトされます。

ただし、少なくともVisual Studioの新しい.Netの場合は、App.Local変数を使用して、この必要性を完全に排除しています。

この32ビットから64ビットへの移行に対するマイクロソフトのソリューションは、ほとんどの32ビットアプリケーションのレガシーサポートを追加することでした。つまり、ほとんどの32ビットアプリケーションは64ビットオペレーティング環境で機能します。64ビットアーキテクチャで動作する他のオペレーティングシステムは、32ビットアプリケーションをまったくロードまたは実行できないことに注意してください。

移行を容易にするために、Microsoftは、通常、すべての32ビットアプリケーションを、通常のProgram Filesフォルダー内の真の64ビットアプリケーションと混合するのではなく、Program Files（x86）フォルダーにロードするように指定しています。

ソース

「リダイレクトメカニズムをどうにかして回避し、すべてを強制的に実際のC：\ Program Files \にインストールするとどうなるのでしょうか？」

なし。2つのプログラムディレクトリは、組織専用であるか、Internet Explorerのように、32ビット版と64ビット版の2つのバージョンを持つプログラムを別々に保持するためのものです。ただし、32ビットプログラムを「Program Files」にインストールし、64ビットプログラムを「Program Files x86」にインストールすると、プログラムは同じように実行されます。

Wikiによると：

一部のアプリケーションインストーラーは、インストールパスの場所内のスペースを拒否します。32ビットシステムの場合、Program Filesフォルダーの短縮名はProgra〜1です。64ビットシステムの場合、64ビットProgram Filesフォルダーの短縮名はProgra〜1（32ビットシステムと同じ）です。一方、32ビットProgram Files（x86）フォルダーの短縮名はProgra〜2です。

その理由は、開発者がプロ​​グラムを64ビットに簡単にアップグレードできるようにするためです。32ビットモードでコンパイルする場合は1つのディレクトリで、64ビットモードでコンパイルする場合は別のディレクトリでプログラムをチェックするためのカスタムコードを記述する必要はありません。単にチェックするだけでC:\Program Files、32ビットモードで実行するとC:\Program Files (x86)、64ビットWindowsによって自動的に変更されます。同様に、レジストリエントリは32ビットプログラムと64ビットプログラムの間で分離されます。

これにより、あまり考慮せずにコンパイルモードを64ビットに変更するだけで開発者が知らない間に競合が発生するのを防ぎ、ユーザーが32ビットと64ビットの両方のバージョンをインストールできるようにしたい開発者の膨大な作業を防ぎます同時にソフトウェア。

しかし、なぜ両方のバージョンを同時にインストールできるようにするプログラムがあるのでしょうか？1つの例：PhotoshopとIEには、ネイティブ.dllの拡張子があります。同じプロセスで32ビットと64ビットのコードを混在させることはできないため、32ビットバージョンのアドオンを64ビットバージョンで使用することはできません。逆の場合も同様です。したがって、Photoshop / IE は両方のバージョンのインストールを許可するか、既存のアドオンの膨大なベースを壊す危険性があります。

「Program Files（x86）」で実行されるプログラムは、WOW64サブシステムを使用します（Windows 64ビット上のWindows 32ビットは、x64アーキテクチャシステムでx32アプリケーションを実行するためのドライバーとAPIのセットです）。

WoW64サブシステムは、すべての64ビットバージョンのWindowsで同様のインターフェイスを持つ軽量の互換性レイヤーで構成されています。64ビットシステムで変更されていない32ビットWindowsアプリケーションを実行するために必要なインターフェイスを提供する32ビット環境を作成することを目的としています。技術的には、WoW64は3つのダイナミックリンクライブラリ（DLL）を使用して実装されます。

• Wow64.dll、Windows NTカーネルへのコアインターフェイスで、ポインターとコールスタックの操作を含む32ビットと64ビットの呼び出しを変換します。
• 32ビットアプリケーションに適切なエントリポイントを提供するWow64win.dll
• Wow64cpu.dll。32ビットモードから64ビットモードへのプロセッサの切り替えを処理します。

64ビットシステムでは、32ビットアプリケーションを「エミュレート」する必要があります。これが、Windowsが2つのProgram Filesフォルダーを「分離」する必要がある理由です。

こことインターネットでの答えがかなり異なることは興味深いことです。この重要な質問に対する正確な答えを見つけることは困難でした。インターネット上にはかなりの誤った情報が表示されており、混乱を招いているようです。

私はかなりの量の研究を行ってきましたが、次の結論を導き出しました。

• アプリケーションが保存される場所に違いはありません。実行時に、Windowsはアプリケーションが32ビットか64ビットかを判断し、適切なDLLおよびレジストリセクションを自動的に使用します。

これは自動的に行われ、アプリケーションの保存場所とは無関係です。個別の32ビットフォルダーと64ビットフォルダーを使用しても、速度、信頼性、またはその他の機能上の利点はありません。

デフォルトで2つのフォルダー（「プログラムファイル」と「プログラムファイル（x86）」）に分離されている唯一の理由は、同じプログラムの2つのバージョン（32ビットバージョンと64ビットバージョン）がある場合、重複するファイルを別々に保つ簡単な方法。この場合でも、すべてのファイル名が一意である限り、実際には同じフォルダ内に存在しても問題はありません。

上記の結論には注意点があり、それはコーディングが不十分なアプリケーションの1つです。アプリケーションにパスがハードコーディングされている場合、そのパスのみが使用されます。原則として、パスをアプリケーションにハードコーディングすることはできませんが、プログラマがこの間違いを犯すことがあります。この場合、プログラムはハードコードされたパスを使用します。アプリケーションがインストールされているディレクトリは、実際にファイルを探す場所には影響しません。

フォルダを分離することにより、WoW64を必要とするネイティブの64ビットアプリケーションとトーを分離することができます。

@OliverSalzburgがすでに指摘したように、これは便利です。たとえば、一部のプラグインとアドオンは、Webブラウザの64ビットと32ビットの両方をインストールできる場合があるためです。二つ。

フォルダを分離する必要があるため、レジストリのリダイレクトなどの技術を使用して、この分離が自動的に行われます。

インストーラーがRegQueryValueExなどを使用してレジストリを読み取ることにより、プログラムファイルフォルダーを決定しようとするとします。

いずれにしても、レジストリキーを読み取ろうとします

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

通常はを指しC:\Program Filesます。

ただし、インストーラーが32ビットアプリケーションである場合、レジストリリダイレクトによりregitryキーが発生します

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

代わりに読み取られC:\Program Files (x86)ます。通常はを指します。

これらの特定のフォルダ名が使用された理由は、この選択をした人によってのみ答えられます。必要に応じて、デフォルトのフォルダー名をいつでも変更できます。

Windowsは、「Program Files（x86）」を使い果たしたプログラムとはどういうわけか、それ自体を異なって提示しますか？

疑わしい。ほとんどのインストーラーでは、カスタムインストールフォルダーを選択できるため、プログラムのインストール先は実際には関係ありません。

ここでの混乱は信じられません。まず、私はフルタイムの開発者です。

MSは、古い32ビットアプリケーションと新しい64ビットアプリケーションの両方でDLLが使用されるケースを解決するためにこれを行いました。古いメソッド（System32、Program Filesなど）を変更できませんでした。再コンパイルできない古いプログラムが破損する可能性があるためです。

そのため、MSは64ビットの特定のプログラム、アセンブリ、およびライブラリを保存するフォルダーを作成し、新しいプログラムが適切なライブラリにリンクできるようにし、古いプログラムが通常どおり動作するようにしました。

現状では、.Net DLLは同じマシン上で他のバージョンと共存できます。たとえば、Library.1.0.1、Library.1.0.2、Library 1.1.0などを使用できます。これは特定のビットサイズ（32または64）専用です。個別のフォルダーを使用しない場合、すべてのアセンブリに32ビット版と64ビット版が必要です。これにより、同じアセンブリの複数のバージョンが既に含まれているディレクトリが著しく混乱します。

これはすべて開発者のものです。ユーザーとしては、Windows 7 64で32ビットプログラムを使用している場合にのみ対処する必要があります。また、32ビットバージョンと同じアプリケーションを64ビットでも実行できることを好みます。64ビットでコンパイルする必要がある32ビットアプリケーションで作業している場合、コンパイラーに指示するだけです。DLL名と他のすべては同じままです。

これがWindows 95/98に存在しなかった理由は、これらのシステムが32ビットランタイムをシミュレートしたためです。正規の32ビットオペレーティングシステムではありませんでした。「サンク」という名前の何かで32ビット実行を偽装しました。

ここに良い定義があります：http : //searchwinit.techtarget.com/definition/thunk

まったく必要ありません。たとえば、作業中のコンピューターでは、各アプリケーションをフォルダーC:\MyPrograms\にインストールして、IT部門によってインストールされたアプリケーションから分離します。

もちろん、これにより、1つのアプリケーションの両方のバージョン（32ビットと64ビット）をインストールできなくなりますが、これは私の場合は問題ありません。

プログラムを起動するたびに、常に最初のDLL C:\Windows\System32\ntdll.dllが実行されます。このDLLは、プログラムが32ビットアプリケーションか64ビットアプリケーションかを判断します。それに応じて、WoW64すでにいくつかの回答で言及されているリダイレクトされます。