64ビットWindows版のChromium系ブラウザー、ついに64ビットプログラム標準の場所へインストールされるようになる見込み 40
ストーリー by hylom
ついに 部門より
ついに 部門より
headless曰く、
64ビットWindows版のGoogle Chromeは長年にわたって32ビットプログラム標準の場所にインストールされていたが、ついに変わるようだ（Ghacks、Softpedia）。
64ビットWindows版のGoogle Chromeはリリースされた2014年以来、64ビットプログラム用の「C:\Program Files」ではなく、（ユーザー別フォルダーにインストールされる場合を除き）32ビットプログラム用の「C:\Program Files（x86）」以下にインストールされていた。Microsoft Edgeを含むChromium系ブラウザーも同様に「C:\Program Files（x86）」以下にインストールされる。
この問題についてChromiumチームでは2014年当時上げられたバグ報告に対し、「現時点では意図的なものであり、将来的には移動する」と説明していた。その後も同じ問題に関するバグ報告がたびたび上げられるものの放置されていたが、5月になって修正に着手。6月6日のコミットはWindows 7の「mini_installer_tests」が失敗するとして取り消されたが、6月10日には修正版がコミットされている。
この変更が提供される時期やバージョンは不明だが、いずれは64ビット版のChromium系ブラウザーすべてが「C:\Program Files」以下にインストールされるようになるとみられる。ただし、既存のインストールフォルダーが変更されることはなく、「C:\Program Files」以下に移動したい場合はいったんアンインストールしてからインストールしなおす必要があるとのことだ。
そもそも何で「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に入れるとしてしまった方が良いのか。
うーん、なんというか、あまりすっきりしない仕様だなぁ。
Re:そもそも何で「Program Files」と「Program Files（x86）」に分けたん (スコア:1)
同じ実行ファイル名やライブラリでx86とx64版を共存させたいからでは。
ビルドでx86/x64を切り替えるのは簡単だけど、ライブラリのファイル名まで切り替えるのは、余計なコスト掛かりますし。
Re: (スコア:0)
どちらで動作するか自動判断するんじゃなかったかな。
Re: (スコア:0)
決定的な理由は知らないけど、
1環境に32/64ビット版双方のアプリケーションをインストールしたい需要はあったなあ。プラグインが32bit版しか無いとかで。
それが同じパスだったらマズいし、OSで場所が規定されていないのも宜しくないかな。
Re: (スコア:0)
同一アプリで32bit版と64bit版があるケースを想定しているんじゃないかな。
PowerShellとか両方あるよ。これは32bitライブラリも利用できるようにするのが目的だね。
例えばAccessのOLEDBプロバイダは32bit版しかないので、これを使いたいときは32bit版PowerShellを使ったりする。
Re:そもそも何で「Program Files」と「Program Files（x86）」に分けたん (スコア:1)
64bit版Officeをインストールするという選択肢。
# 再開発が嫌だから32bitを使い続けてるっていう所はそれなりにある模様。悩ましい…
Re:そもそも何で「Program Files」と「Program Files（x86）」に分けたん (スコア:1)
デフォルトは64bit版 [microsoft.com]になってるので、そろそろ両対応が当たり前になるかなぁ。
Re: (スコア:0)
でもお前（PowerShell）System32以下に居るじゃねえか
Re: (スコア:0)
64bit版 Powershell は、System32、32bit版 poweershellは SysWOW64の下
ちゃんとルール通りに分かれてますけど何が問題？
64bit版が System64にならずSystem32のままで 32bitが SysWOW64なのは、128bit化したときどうすんだろうという気はするけど。
Re: (スコア:0)
Re: (スコア:0)
ワロタ
Re: (スコア:0)
ビルゲイツやリーナストーバルズって随分長生きなんですね
ユーザー別フォルダーの必要性は？ (スコア:0)
ユーザー別フォルダーにインストールされたりするのは
いったい何の必要性があるんだろう？
本体がどこにあるか探してユーザディレクトリにあった時は？？？ってなったわ。
Re:ユーザー別フォルダーの必要性は？ (スコア:1)
自分用のプログラムやスクリプトは~/binに置くしな
くだらないプログラムを/usr/binの下に置いてみんなの$PATH汚す必要ないし
# ところで/usr/binにtestなんてテストプログラム置いたの誰?
Re:ユーザー別フォルダーの必要性は？ (スコア:1)
[ なんていうリダイレクト失敗したままのファイルも残ってるんだよなぁ。
# zshユーザーなので、消されて困りません。
Re: (スコア:0)
リダイレクト失敗してできたと思われる1や2は見たことがある。
Re: (スコア:0)
そのコメントはずれているとは思うが
-x
というファイルができていて消し方を考えた事はある
Re: (スコア:0)
~/.binがいい
普段見えなくても困らないものは隠したい
だれだよ~/にsnap作ったやつは．snapだろ
Re: (スコア:0)
最近は ~/.local/bin が主流ですよ
Re: (スコア:0, 既出)
# ところで/usr/binに[なんてファイル置いたの誰？ タイプミスかなんか？
# 消し消し。
Re: (スコア:0)
……しまった……既出だ……
せっかくなので経験談。自分がやったわけじゃないけど、それ消したせいでシステムの起動の時にエラーメッセージが大量に出て、こりゃなんだと大変困惑するはめになった。
Re: (スコア:0)
そんなやつに共用マシンの suの帽子をかぶらせるのはどうなの？
Re: (スコア:0)
普通に考えたら、管理者権限を渡されていないユーザにもインストールさせたい、という意図だろうに。
セキュリティ？管理ポリシー？ 知らんがな by G
Re: (スコア:0)
「セキュリティ」もいろんな側面から考える必要があるわけで、企業の管理者の言う「セキュリティ」と、それ以外は相容れないことの方が多い。
SSLの盗聴や告知せずに行われるロギング等の「操作する者」が知らぬ場所で行われる秘密の侵害は「脅威である」とする考え方も多い。
情シスの担当者が全能の神の如く振る舞ってもよしと考えているのは古典的な日本企業くらい。
Re: (スコア:0)
別にGoogleがやらんでも、素のWindowsの一般ユーザは
ローカルユーザ権限の範囲内なら好きに実行ファイルをユーザフォルダに置いて実行できる。
それ封じる手段を何らか講じるならChromeも封じられる。
変な方法で実行できる実行ファイルを制限して、
それでもユーザフォルダ内のChromeは許可したい時くらいじゃね？困るのは。
Re: (スコア:0)
自分しか使わないちょっとしたツール入れるのにわざわざ管理者権限とか無駄じゃん？
// Google Chromeがそれに該当するとは思わないが。
Re: (スコア:0)
管理者権限不要でインストールできるメリットがある。
VSCodeも途中から一般権限でインストールできるインストーラーができた。
Re: (スコア:0)
インストールというよりアップデートを頻繁に行うから、でしょうね
そもそも (スコア:0)
任意の場所にインストールできるようにしてよ
Re: (スコア:0)
ポータブル版とかで
Re: (スコア:0)
昔から要望出てると思うのですが、Cドライブ以外にインストールさせない根拠はなんでしょうね。
Re: (スコア:0)
OSとして一式入ってくるコンポーネント毎にインストール先分けたりは普通しない。
OSが入ってるパーティションが原則Cドライブになる(PC98系除く)。
ユーザが入れるアプリでは任意の場所を指定すれば良い。
Program FilesがCドライブにほぼ固定なのは必然。
ChromeがランチャはProgram Files、本体はAppDataなのは、多分、
ブラウザ起動したいアプリはディレクトリ決め打ちで発見可能で、
ユーザ権限でも適宜アップデートする為にAppData採用てだけかなと。
AppDataはユーザプロファイルの配置変えれば動かせるハズ。
Re: (スコア:0)
その「ユーザが入れるアプリ」であるChromeがCドライブ固定なのが不満っていう話だと思うんですが。
そもそもC:\Program Filesって、自分で入れるアプリとはちょっと毛色が違うものが色々入っていて（IEとかJavaとか）、見通し悪いんですよね。スペースが入っているのもアプリによっては誤動作するし。
また、小さなアプリではWindows再インストールしても再インストール不要なものも多いので、そういうものは再インストール時にも残しておきたい。なので自分は可能な限りD:¥Apliに入れています。