なぜ64ビットWindowsは別の "Program Files（x86）"フォルダを必要とするのですか？
64ビットバージョンのWindowsでは、 "Program Files"フォルダは64ビットプログラム用であり、 "Program Files（x86）"フォルダは32ビットプログラム用であることを私は知っていますが、これはなぜ必要なのですか？
「必要」とは、「マイクロソフトが他の設計上の決定を下すことができなかった理由」を意味するのではありません。もちろん彼らは持っている可能性があります。そうではなく、「64ビットWindowsの現在の設計を考えると、32ビットプログラムに64ビットプログラムとは別の最上位フォルダが必要なのはなぜですか？」別の言い方をすれば、「何らかの理由でリダイレクトメカニズムを避けて、すべてを本物のC:\Program Files\にインストールするように強制した場合、どうなるのでしょうか。」
「1つは32ビットプログラム用、もう1つは64ビットプログラム用」と主張するスーパーユーザーや他の場所に関する多くの質問がありますが、私が見つけることができるものはどれも理由を与えることができません。私の経験では、32ビットプログラムが正しい場所にインストールされているかどうかは関係ありませんseem。
Windowsはどういうわけか "Program Files（x86）"を使い果たしたプログラムに自分自身を異なって提示しますか？ 「プログラムファイル」の代わりに「プログラムファイル（x86）」にインストールされたプログラムの違いを正確に示す説明はありますか？ Microsoftが正当な技術的理由なしに新しいフォルダを導入することはありそうもないと思います。
簡単な答え：従来の32ビットアプリケーションが64ビットアプリケーションに醜いルールを課すことなく以前と同じように機能し続けることを保証するためには、永続的な混乱が生じます。
それは必要ない。 32ビットDLLと実行可能ファイルを64ビットDLLと実行可能ファイルから分離するための独自の方法をすべてのアプリケーションに作成するように要求するなど、他の方法よりもはるかに便利です。
主な理由は、64ビットDLLがアプリケーションに見える場所にインストールされていても、64ビットシステムが存在していてもわからない32ビットアプリケーションを「正常に動作する」ようにすることです。 32ビットアプリケーションでは64ビットDLLをロードできないため、32ビットアプリケーション（64ビットシステムより前のバージョンで、64ビットファイルを使用できない可能性がある）を確実にするための方法が必要でした。 64ビットDLLを見つけられずにロードして失敗し、エラーメッセージを生成しようとしませんでした。
これに対する最も簡単な解決策は一貫して別々のディレクトリです。実際の唯一の代替策は、64ビットアプリケーションごとに、その実行可能ファイルを32ビットアプリケーションでは見えない場所（そのアプリケーション内のbin64ディレクトリなど）に「隠す」ように要求することです。しかしそれは、レガシーアプリケーションをサポートするためだけに64ビットシステムに永続的な醜さを課すでしょう。
アプリケーションを上書きせずに、32ビット版と64ビット版の両方のアプリケーションをインストールできます。
翌日、この回答とコメントスレッドを見て、回答に重大な見落としがある可能性に気付きました。私は誤ってプログラミングの背景を仮定し、コメントで you について話していたとき、ユーザーではなくプログラマーを意味していました。
私はMicrosoftで働いていません。これらのフォルダーの背後にあるreal理由が何なのかわかりませんが、これらのフォルダーを持っている理由は明白なので、私はそれを主張する問題はありません。
それでは分解しましょう！
フォルダは素晴らしいです！
何かに同意しましょう。フォルダーは素晴らしいです！それらは必要ありません。すべてのファイルをハードドライブのルートに配置するのに十分なファイル名があるので、なぜフォルダーがあるのでしょうか。
まあ、彼らは私たちのものを注文するのに役立ちます。そして、注文品は素晴らしいです。物事をより簡単に処理するのに役立ちます。これは、構造が必要なマシンで作業するときに特に役立ちます。
データとロジックを分離するのは素晴らしいことです！
プログラミングでよく見られるパラダイムは、データをロジックから分離することです。 が知っている1つの部分が欲しいhow何かをするで、別の部分が欲しい何かできるwith = 。
これはファイルシステムにもあります。
アプリケーション用のフォルダー（ロジック）と貴重品用のフォルダー（データ）があります。
論理
%WINDIR%%PROGRAMFILES%%PROGRAMFILES(x86)%
データ
%PROGRAMDATA%%HOMEDRIVE%%HOMEPATH%
したがって、フォルダは素晴らしいようで、プログラムを独自の小さなフォルダに入れるのが理にかなっています。しかし、なぜ2つあるのでしょうか？インストーラーにそれを処理させ、すべてを1つの
Programsフォルダーに入れてみませんか？インストーラーは魔法ではありません
今日では、小さなプログラムを使用して大きなプログラムをインストールすることがよくあります。これらの小さなプログラムを installers と呼びます。
インストーラーは魔法ではありません。それらはプログラマーによって書かれる必要があり、そこにある他のアプリケーションのようなアプリケーションです（バグがある可能性があります）。それでは、想像上のプログラマーが現在のシステムに直面する必要がある状況を見てみましょうwithとwithout：
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を使用して正しいパスを取得します）。
すべてがその場所を見つける自動的にで、パターンはインストールするすべてのアプリケーションと同じです。一貫性は理にかなっています
学ぶ何かをするとき、それは通常、観察された行動が一貫していたことを意味します。それ以外の場合は、観察して学ぶことは本当にありません。
これは、小さなファイルシステムにも当てはまります。 同じものを同じフォルダに常に入れるのは理にかなっています。そうすれば、何かを探しているときにどこを探すべきかがわかります。
32/64アプリケーションを区別するシステムは、この目標をさらに促進します。アプリケーションは、名前の競合、バイナリのロード動作、およびセキュリティ（ある程度）を避けるために2つの場所に分かれています。
まだわかりません。これは役に立たないようです
忘れないでください。人は信じられないほど愚かです。これには、ユーザー、スーパーユーザー、特にプログラマーが含まれます。
これが、システムを使用可能にするために file system redirection のようなものが必要な理由です。
プログラマーはそこに入って、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ビットです。
ええ、でもすべてのアプリケーションが好きです！
- bothディーゼルとガスを車に入れるとどうなりますか？
- 同じラインでboth交流と直流を使用しようとするとどうなりますか？
- both私の猫と魚を同じ水槽に入れておくとどうなりますか？
一部の質問には回答が不要です。実行することを意図したものではありません。実行しないでください。ここで得られるものは何もありません。そのような変更が引き起こす可能性のある問題の量は、誰かがこれで目にする可能性のある利点を上回りますalways。
TL; DR：
要約すると、いや、それは必要ではありません。それらはcould単一のフォルダを使用していますが、いいえ、Windowsは、ある場所から実行されているプログラムとは異なる形で表示されません。
まあ、誰もがこれについて意見を投げているようですので、私は私の2¢を投げます。 whyについての理由をすでに推測している人もいますが、マイクロソフトはプログラムの32ビットバージョンと64ビットバージョンに別々の最上位フォルダーを作成することを選択したため、その部分は残しておきます（最良の理由デビッドの説明はプログラマーの便宜を図っています）。もちろん、それでも、直接的な質問にはまったく対応していませんなぜこれが必要なのですか？、これに対する答えはおそらく次のとおりです：nots。
代わりに、質問の本文を取り上げます
Windowsは、「Program Files（x86）」を使い果たしたプログラムとはどういうわけか、それ自体を異なって提示しますか？
実際はそうではありませんが、プログラムの場所canは動作に影響しますが、あなたが考える方法には影響しません。
プログラムを実行すると、Windowsはそれを実行する環境を設定します（環境変数だけでなく、メモリ、アドレス指定などの面でも意味があります）。この環境は、実行可能ファイルの内容に依存します（32ビットプログラムと64ビットプログラムは内部的に異なります）。 64ビットシステムで32ビットプログラムを実行する場合、32ビット環境をエミュレートする32ビットサブシステムで実行されます。これは WoW64 （WoW64は Windows 64-bit上のWindows ）を表し、_で16ビットアプリを実行する方法に似ています。XP NTVDM を使用します。
管理者権限の有無にかかわらずプログラムを実行すると、実行方法に影響しますが、場所shouldは影響しません（たとえば、一部のドライバのような場所の依存関係の例もあります）。
（私は別のコンピューターを使用しているので、ブラウザの履歴に頼って自分のステップをバックトラックすることはできませんが、先日 このSUの質問 に答えている間に this SO質問 に起因する Google PROCESSOR_ARCHITEW6432 につながる this SO question および このMicrosoftブログ投稿 =。）
途中のどこかで、環境変数%processor_architecutre%コマンドプロンプトの実行場所に応じて異なる結果を得る方法についてStackOverflowの投稿を読みました（正確な引用符を見つけようとします） ）。
答えは、コマンドプロンプトの32ビットバージョンと64ビットバージョンのどちらが実行されたか（つまり、System32\またはSysWoW64\から）であることが判明しました。つまり、場所と思われるはプログラムの動作に影響しますが、それはプログラムのバージョンが異なるためであり、Windowsがフォルダを特別な方法で処理するためではありません。
実行可能ファイルの内容によって32ビットか64ビットかが決まるため、これは理にかなっています。したがって、同じプログラムの32ビットと64ビットの両方のコピーを置くことができます（たとえば、foobar32.exeとfoobar64.exe）同じフォルダー内で、それらを実行すると、それらは正しくロードされます（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ビットアプリケーションをまったくロードまたは実行できないことに注意してください。
移行を容易にするために、マイクロソフトでは、通常のProgram Filesフォルダ内の本当の64ビットアプリケーションと混在させるのではなく、すべての32ビットアプリケーションをデフォルトでProgram Files（x86）フォルダにロードするように指定しました。
"リダイレクションの仕組みをどうにか避けて、すべてを本物のC：\ Program Files \にインストールするように強制するとどうなりますか？"
何もない。 2つのプログラムディレクトリは、整理用、またはInternet Explorerのように2つのバージョンが32ビット版と64ビット版が別々になっているプログラムを保存するためのものです。しかし、32ビットプログラムを「Program Files」に、64ビットプログラムを「Program Files x86」にインストールすることができます。プログラムが同じように動作することは起こりません。
Wiki はこう言います：
一部のアプリケーションインストーラは、インストールパスの場所内のスペースを拒否します。 32ビットシステムの場合、Program Filesフォルダの短縮名はProgra〜1です。 64ビットシステムの場合、64ビットProgram Filesフォルダの短縮名はProgra〜1です（32ビットシステムと同じ）。 32ビットプログラムファイル（x86）フォルダーの短い名前は今すぐプログラム〜2です。
その理由は、開発者にとってプログラムを64ビットに簡単にアップグレードできるようにするためです。 32ビットモードでコンパイルするときは1つのディレクトリに、64ビットモードでコンパイルするときは別のディレクトリにプログラムをチェックするためのカスタムコードを記述する必要はありません。彼らはC:\Program Filesをチェックするだけで、32ビットモードで実行している場合、これは64ビットWindowsによって自動的にC:\Program Files (x86)に変更されます。同様に、レジストリエントリは32ビットプログラムと64ビットプログラムの間で分離されています。
これは、あまり気にすることなくコンパイルモードを64ビットに変更するだけの未知の開発者による競合を防ぎ、32ビット版と64ビット版の両方をインストールできるようにしたい開発者にとっての膨大な作業を防ぎます。同時にソフトウェア。
しかし、なぜ両方のバージョンを同時にインストールできるようにしたいプログラムがあるのでしょうか。 1つの例：PhotoshopとIEはネイティブ.dllの拡張子を持っています。同じプロセスで32ビットと64ビットのコードを混在させることはできないため、32ビットバージョン用のアドオンを64ビットバージョンと一緒に使用することはできません。逆も同様です。したがって、Photoshop/IEは両方のバージョンをインストールできるようにするか、既存のアドオンの巨大な基盤を壊す危険性があります。
こことインターネットでの答えがかなり異なることは興味深いです。この重要な質問に対する正確な答えを見つけることは困難でした。インターネット上にかなりの誤った情報が提示されているように見え、混乱を招きます。
私はかなりの量の調査を行い、以下の結論を導き出しました。
- アプリケーションが格納されている場所に違いはありません。実行時に、Windowsはアプリケーションが32ビットと64ビットのどちらであるかを判断し、適切なDLLとレジストリセクションを自動的に使用します。
これは自動的に行われ、アプリケーションの保存場所とは無関係です。速度、信頼性、または32ビットと64ビットの別々のフォルダを持つことによる機能上の利点はありません。
2つのフォルダ（ 'Program Files'と 'Program Files（x86）'）にデフォルトで分離されている唯一の理由は、同じプログラム（32ビット版と64ビット版）の2つのバージョンがある場合、重なっているファイルを分けるための簡単な方法。この場合でも、すべてのファイル名が一意である限り、それらは実際には何の影響もなく同じフォルダに存在する可能性があります。
上記の結論には注意が必要ですが、それはコード化が不十分なアプリケーションの1つです。アプリケーションにパスがハードコードされている場合、そのパスのみが使用されます。原則として、パスはアプリケーションにハードコーディングされるべきではありませんが、ときどきプログラマーがこの間違いを犯すでしょう。この場合、プログラムはハードコードされたパスを使用します。アプリケーションがインストールされているディレクトリは、実際にファイルを探す場所には影響しません。
「Program Files（x86）」上で実行されるプログラムは、 WOW64 サブシステムを使用します（Windows 32ビット上のWindows 32ビットは、ドライバーとAPIのセットです。 x64アーキテクチャシステム上でx32アプリケーションを実行するように意図されている）
WoW64サブシステムは、すべての64ビットバージョンのWindowsで同様のインターフェイスを持つ軽量の互換性レイヤから構成されています。 64ビットシステム上で未修正の32ビットWindowsアプリケーションを実行するために必要なインタフェースを提供する32ビット環境を作成することを目的としています。技術的には、WoW64は3つのダイナミックリンクライブラリ（DLL）を使用して実装されています。
- Wow64.dll、32ビットと64ビットの呼び出し（ポインタと呼び出しスタックの操作を含む）を変換するWindows NTカーネルへのコアインターフェイス
- 32ビットアプリケーション用の適切なエントリポイントを提供するWow64win.dll
- プロセッサを32ビットモードから64ビットモードに切り替えるWow64cpu.dll。
64ビットシステムでは32ビットアプリケーションを「エミュレート」する必要があるため、Windowsが2つのProgram Filesフォルダを「分離」する必要があるのはそのためです。
私はここで混乱を信じることはできません..まず第一に私はフルタイムの開発者です。
MSは、DLLが、古い32ビットアプリケーションと新しい64ビットアプリケーションの両方で使用される場合を解決するためにこれを行いました。古いメソッドを変更することはできません（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ビットプログラムを使って作業しているときだけそれに対処する必要があります。そして私は64ビットで32ビットバージョンと同じアプリケーションを実行する能力を持つことを好むのです。 64ビットでコンパイルする必要がある32ビットアプリケーションで作業しているときは、コンパイラにそのように指示するだけです。 DLL名と他のすべてのものは変わりません。
これがWindows 95/98に存在しなかった理由は、それらのシステムが32ビットランタイムをシミュレートしたためです。本物の32ビットオペレーティングシステムではありません。それは "thunking"という名前の何かで32ビットの実行を偽造しました。
これは良い定義です。 http://searchwinit.techtarget.com/definition/thunk
フォルダを分けることで、ネイティブの64ビットアプリケーションと、 WoW64 を必要とするものを区別することができます。
これは、 @ OliverSalzburg がすでに指摘しているように、64ビットと32ビットの両方のWebブラウザをインストールする場合に便利です。いくつかのプラグインとアドオンは2つのうちの1つのみで利用可能かもしれませんので。
フォルダを分割する必要がある場合は、 レジストリリダイレクト などの手法を使用して、この分割を自動的にします。
インストーラーが、例えば RegQueryValueEx を使用してレジストリを読み取ることによってプログラムファイルフォルダーを決定しようとしたとします。
いずれにせよ、それはレジストリキーを読み込もうとします
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
これは通常C:\Program Filesを指しています。
ただし、インストーラが32ビットアプリケーションの場合、レジストリリダイレクトによってレジストリキーが生成されます。
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion
通常はC:\Program Files (x86)を指します。
これらのspecificフォルダー名が使用された理由は、この選択をした人々しか回答できません。必要に応じて、いつでもデフォルトフォルダの名前を変更できます。
Windowsはどういうわけか "Program Files（x86）"を使い果たしたプログラムに自分自身を異なって提示しますか？
疑わしい。ほとんどのインストーラはあなたがカスタムインストールフォルダを選択することを許可しています、それでそれは本当に問題ではありませんプログラムがインストールされる/。
まったく必要ありません。たとえば、作業中のコンピュータでは、IT部門がインストールしたアプリケーションと区別するために、各アプリケーションをフォルダC:\MyPrograms\にインストールします。
もちろん、これは私が1つのアプリケーションの両方のバージョン（32と64ビット）をインストールするのを防ぎます、しかしこれは私の場合問題ありません。
プログラムを起動するたびに、常に最初にDLL C:\Windows\System32\ntdll.dllが実行されます。このDLLは、プログラムが32ビットアプリケーションか64ビットアプリケーションかを決定します。それに応じて、あなたはすでにいくつかの答えで言及されているWoW64にリダイレクトされます。