アカウント名:
パスワード:
Linuxのユーザランドも「/lib64」とかあるからかな。
Program Filesについてはなんとなくじゃないかなぁ。Windows直下にはSystem32とSysWOW64があって、こちらは明確に64bitと32bitに分けられているけど(こっちの方がlib64とかに近い考えのような気がする)、Program Filesについては明確なガイダンスとかが無いような気がする。# 32bit、64bitはそれぞれProgram Files (x86)、Program Filesに入れなければ正しく動作しないなんて誤った解説してるところがあるけど。
まぁ、でもOSネイティブビット版はProgram Filesで、それ以外は(x86)付きの方へってのは分類されてるような気がしてすっきりするという気分的な問題(?)はあるかもしれない。
system32はapplication dllを置く場所じゃないので。で、3rd party のappが program filesにある別の3rd partyのdllを使いたくなることはよくあるので、x86/x64でprogram filesを分けて、32bit appにredirection simを挟むのは必要な措置。
同じアプリ同じバージョンの 32bit版と64bit版を両方インストールするためですし、Windowsの場合、過去の資産を利用する頻度が高い都合上、そうなるケースは非常に多いのです。
Program Files (x86)と異なり、Program FilesではUAC仮想化が効かないという違いがある。(XP x64というニッチを無視すれば)x64版はVistaで初めて登場したものであり、x64アプリの後方互換性を考慮する必要はないという理屈による。
UAC仮想化は、Win95になった時点で行儀が悪いので絶対やっちゃ駄目と言われたのに、Win3.1までの流儀をそのまま維持してるような本当に酷いアプリを動作させるためだけの物だからな。さすがに、x64で組むような動かそうとするアプリで必要とすることはなかろう。
ソフトウェアが正しく動作しないのとは少し違うけど，32bit ソフトウェアから 64bit ソフトウェアを呼び出す（例えば右クリックの送るとか）とWindows が勝手に「Program Files」というパスを「Program Files (x86)」というパスに書き換えてしまうので，64 bit ソフトウェアの呼び出しが失敗するというクソみたいな仕様はある。
32bitアプリケーションからProgram Filesディレクトリの場所を発見するためにレジストリの値(か環境変数)を参照して返す値が「Program Files (x86)」になっている。と言うのが正しいかなぁ。# そこ書き換えれば32bitだろうが64bitだろうが同じ場所ってできそうだけど不具合起きそうだなぁ。別に32bitアプリケーションを64bitのフォルダに入れてはならないという制限は無いようだけど、API呼び出しで特殊パスは勝手に書き換えられる(あるいは32bitなのだからこっちだよねという押しつけ)ので謎現象に悩まされたくないから32bitはProgram Files (x86)で64bitはProgram Filesに入れるとしてしまった方が良いのか。うーん、なんというか、あまりすっきりしない仕様だなぁ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
そもそも何で「Program Files」と「Program Files（x86）」に分けたんかな (スコア:2)
Linuxのユーザランドも「/lib64」とかあるからかな。
Re:そもそも何で「Program Files」と「Program Files（x86）」に分けたん (スコア:1)
Program Filesについてはなんとなくじゃないかなぁ。
Windows直下にはSystem32とSysWOW64があって、こちらは明確に64bitと32bitに分けられているけど(こっちの方がlib64とかに近い考えのような気がする)、Program Filesについては明確なガイダンスとかが無いような気がする。
# 32bit、64bitはそれぞれProgram Files (x86)、Program Filesに入れなければ正しく動作しないなんて誤った解説してるところがあるけど。
まぁ、でもOSネイティブビット版はProgram Filesで、それ以外は(x86)付きの方へってのは分類されてるような気がしてすっきりするという気分的な問題(?)はあるかもしれない。
Re:そもそも何で「Program Files」と「Program Files（x86）」に分けたん (スコア:1)
system32はapplication dllを置く場所じゃないので。
で、3rd party のappが program filesにある別の3rd partyのdllを使いたくなることはよくあるので、x86/x64でprogram filesを分けて、32bit appにredirection simを挟むのは必要な措置。
Re: (スコア:0)
同じアプリ同じバージョンの 32bit版と64bit版を両方インストールするためですし、Windowsの場合、過去の資産を利用する頻度が高い都合上、そうなるケースは非常に多いのです。
Re: (スコア:0)
Program Files (x86)と異なり、Program FilesではUAC仮想化が効かないという違いがある。(XP x64というニッチを無視すれば)x64版はVistaで初めて登場したものであり、x64アプリの後方互換性を考慮する必要はないという理屈による。
Re: (スコア:0)
UAC仮想化は、Win95になった時点で行儀が悪いので絶対やっちゃ駄目と言われたのに、Win3.1までの流儀をそのまま維持してるような本当に酷いアプリを動作させるためだけの物だからな。
さすがに、x64で組むような動かそうとするアプリで必要とすることはなかろう。
Re: (スコア:0)
ソフトウェアが正しく動作しないのとは少し違うけど，
32bit ソフトウェアから 64bit ソフトウェアを呼び出す（例えば右クリックの送るとか）と
Windows が勝手に「Program Files」というパスを「Program Files (x86)」というパスに書き換えてしまうので，
64 bit ソフトウェアの呼び出しが失敗するというクソみたいな仕様はある。
Re:そもそも何で「Program Files」と「Program Files（x86）」に分けたん (スコア:1)
32bitアプリケーションからProgram Filesディレクトリの場所を発見するためにレジストリの値(か環境変数)を参照して返す値が「Program Files (x86)」になっている。と言うのが正しいかなぁ。
# そこ書き換えれば32bitだろうが64bitだろうが同じ場所ってできそうだけど不具合起きそうだなぁ。
別に32bitアプリケーションを64bitのフォルダに入れてはならないという制限は無いようだけど、API呼び出しで特殊パスは勝手に書き換えられる(あるいは32bitなのだからこっちだよねという押しつけ)ので謎現象に悩まされたくないから32bitはProgram Files (x86)で64bitはProgram Filesに入れるとしてしまった方が良いのか。
うーん、なんというか、あまりすっきりしない仕様だなぁ。