題 為什麼64位Windows需要單獨的“Program Files(x86)”文件夾?


我知道在64位版本的Windows上,“Program Files”文件夾用於64位程序,“Program Files(x86)”文件夾用於32位程序,但是 為什麼這甚至是必要的?

“必要的”,我並不是說“為什麼微軟沒有做出任何其他設計決定?”因為他們當然可以。相反,我的意思是,“為什麼,考慮到目前的64位Windows設計,32位程序必須有一個獨立的64位程序頂級文件夾?”換句話說,“如果我以某種方式避免重定向機制並迫使所有內容安裝到真實中,會出現什麼問題 C:\Program Files\?“

超級用戶和其他地方有很多問題斷言“一個用於32位程序,一個用於64位程序”,但我找不到任何理由。根據我的經驗,它沒有 似乎 重要的是32位程序是否安裝在正確的位置。

Windows是否以某種方式與“Program Files(x86)”中運行的程序不同?是否有描述顯示“Program Files(x86)”中安裝的程序與“Program Files”的不同之處?我認為,如果沒有合法的技術原因,微軟不太可能推出新文件夾。


175
2018-06-27 17:19


起源


我會問,你不會回答你的問題 - 你將如何處理\ program files \ common files? - sgmoore
單行答案(以及評論):既然您可以在不知道其架構的情況下輕鬆地從任何文件夾運行任何應用程序,那麼顯然沒有 義務 這種分離的原因。這是一個方便的問題 支持兩種架構的雙重安裝應用程序。在某些情況下,它會產生影響,因為它們不一定是簡單的重新編譯。主要問題是32位應用程序無法加載64位dll,因此通常無法在同一位置安裝這兩個版本。另一種方法是為每個應用程序提供兩個“bin”文件夾。 - Sklivvz
@Synetech我甚至在(x86)下安裝程序只是為了擁有x64二進製文件..有時候很糟糕。 - sinni800
我一直想知道為什麼微軟沒有把64位程序放在“Program Files(x64)”而不是“將”遺留的“Program Files目錄”移動到Program Files(x86) - LawrenceC
關於64 / 32bit差異化的真正混亂是/ Windows / System32包含64位內容,而/ Windows / SysWOW64包含32位內容...... - poke


答案:


簡短回答:確保傳統的32位應用程序繼續以與以往相同的方式工作,而不會對64位應用程序施加醜陋的規則,從而造成永久性混亂。

沒有必要。它比其他可能的解決方案更方便,例如要求每個應用程序創建自己的方式將32位DLL和可執行文件從64位DLL和可執行文件中分離出來。

主要原因是使得甚至不知道64位系統的32位應用程序“只是工作”,即使64位DLL安裝在應用程序可能看起來的位置。 32位應用程序將無法加載64位DLL,因此需要一種方法來確保32位應用程序(可能早於64位系統,因此不知道64位文件)即使存在)也不會找到64位DLL,嘗試加載它,失敗,然後生成錯誤消息。

對此最簡單的解決方案始終是單獨的目錄。真正唯一的選擇是要求每個64位應用程序在32位應用程序看不到的地方“隱藏”其可執行文件,例如 bin64 該應用程序內的目錄。但這會在64位系統上造成永久性的醜陋,只是為了支持遺留應用程序。


89
2018-06-27 18:18



他們沒有必要通過這些環節來允許同一系統上的32位和16位程序。我不記得曾見過 ProgramFiles (16) 或者其他一些。此外,32位程序究竟如何“找到64位DLL並嘗試加載它”?什麼程序圍繞尋找隨機DLL %programfiles%?如果是共享DLL,則它進入WinSxS;如果它不共享,則由程序員來管理自己的DLL。關於它的部分是為了方便程序員而做的。 - Synetech
IIRC Win3.1沒有程序文件目錄(或大多數應用程序忽略它);因此,不會有任何遺留的win16應用程序在程序文件中尋找東西。相反,IIRC共享庫通常是在windows文件夾本身的某個地方進行的。具有windows \ system和windows \ system32的Win32是一個神器。 - Dan Neely
Windows 3.1不支持長文件名,因此它無法擁有“程序文件”文件夾。 - Darth Egregious
@JarrodRoberson:恰恰相反,這是因為微軟非常重視向後兼容性。 - David Schwartz
@Jarrod:實際上,正如每個開發人員都知道的那樣,微軟重視兼容性 太 高度。從字面上看,他們擁有的每個API都有他們拒絕刪除的遺留方法,並且經常 嚴重 他們拒絕修復的錯誤,因為他們害怕破壞為該API編寫的舊程序。大多數API都是如此,但對於微軟現存的任何地方都沒有。 - BlueRaja - Danny Pflughoeft


它允許您安裝應用程序的32位和64位版本,而不會覆蓋自身。


在第二天看到這個答案和評論帖後,我意識到我的答案中可能存在重大疏忽。我錯誤地假設了編程背景,當我談論的時候  在我的評論中,我不是指用戶,而是程序員。

我不為微軟工作,我不知道是什麼 真實 這些文件夾背後的推理是,但我認為有這些文件夾的原因是如此明顯,我沒有任何問題爭論它。

所以讓我們分解吧!

  1. 文件夾太棒了!

    讓我們就某事達成一致。文件夾很棒!我們不需要它們,我們有足夠的文件名將每個文件放在硬盤的根目錄上,為什麼要有文件夾呢?

    好吧,他們幫助我們訂購我們的東西。訂購東西很棒。它有助於我們更輕鬆地處理事情。在使用需要結構的機器時,這尤其有用。

  2. 分離數據和邏輯非常棒!

    編程中經常出現的範例是將數據與邏輯分開。你想要一個部分 知道 怎麼樣 做某事 而你想要另一部分 可以做點什麼


65
2018-06-27 17:31



那是原因嗎?我不能只安裝應用程序 C:\Program Files\App32 和 C:\Program Files\App64? - Stephen Jennings
@StephenJennings:但這需要你手動做出決定。它現在的工作方式是該過程是自動的,因為Windows知道應用程序調用時要提供的文件夾 SHGetSpecialFolderPath 確定安裝位置。 - Der Hochstapler
@Synetech:為什麼安裝到 %PROGRAMFILES% 首先?為什麼不將32位版本放在用戶桌面上,將64位放入回收站?僅僅因為它可以完成,並不意味著它是一個好主意。對不起,我沒有按照你的推理。 - Der Hochstapler
@Synetech:是的,你確實給出了一個很好的例子來說明它是如何完成的。如何做到的另一個非常好的例子是它的方式 是 實際上現在正在完成。簡單地將文件寫入%PROGRAMFILES%並確定它將最終出現在正確的文件夾中是一回事。檢查自己是哪個文件夾 正確 一個是另一個。如果你實際上沒有看到前一種方法的好處,那麼我將無法說服你。問題是為什麼有2個文件夾。我認為我的答案在這方面是完全合理的。 - Der Hochstapler
@OliverSalzburg,不太好。問題是為什麼有兩個文件夾 需要,不是為什麼那裡 是。事實上,他甚至加粗了它: 為什麼這甚至是必要的? 你沒有解釋它為什麼 必要 我給出的例子(甚至你自己的諷刺例子)只是表明它沒有 有 按照它的方式完成。 - Synetech


TL; DR:

總而言之,不,不是 必要;他們 可以 使用單個文件夾,不,Windows不會以不同的方式呈現從一個位置或另一個位置運行的程序。


好吧,每個人似乎都在拋出他們的意見,所以我會折騰我的2¢。其他人已經猜測了原因 為什麼 微軟選擇為32位和64位版本的程序創建單獨的頂級文件夾,所以我將留下那部分(最好的原因是David的解釋是為了方便程序員)。當然,即便如此,它也沒有完全解決直接問題 為什麼這甚至是必要的?,答案可能是: 不是

相反,我將解決問題的主體

Windows是否以某種方式與“Program Files(x86)”中運行的程序不同?

不是,但程序的位置 能夠 影響行為,但不會影響你的想法。

當您運行程序時,Windows會設置一個運行它的環境(我的意思是在內存,尋址等方面,而不僅僅是環境變量)。此環境取決於可執行文件的內容(32位和64位程序在內部不同)。在64位系統上運行32位程序時,它在32位子系統中運行,該子系統模擬32位環境。它被稱為 了WoW64 (WoW64代表 Windows 64位Windows並且類似於使用Linux在XP中運行16位應用程序的方式 NTVDM

當您運行具有或不具有管理員權限的程序時,它會影響它的運行方式,但會影響位置 應該 不影響它(雖然有一些位置依賴的例子,例如一些驅動程序)。

(我使用的是另一台電腦,所以我不能依靠我的瀏覽器歷史記錄來回溯我的步驟,但有一天在回答時 這個SU問題 我結束了 這個問題 這讓我很開心 Google PROCESSOR_ARCHITEW6432導致 這個問題 和 這個微博的帖子。)

在此過程中的某個地方,我讀了一篇關於envirnoment變量如何的StackOverflow文章 %processor_architecutre%  根據您運行命令提示符的位置,給出不同的結果 (我會盡力找到確切的報價)。

答案結果證明是否運行了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位版本的程序也不能這樣做。就像大衛所說的那樣,如果程序員保持獨立(例如,使用變量使其看起來只有一組文件等),那對程序員來說就更容易了。


15
2018-06-27 19:23



復仇投票! Muahahaha! 嘆 - Synetech
投票奇怪:\。 BTW好解釋+1。 - avirk


另一個原因是大多數程序過去常常使用%PROGRAMFILES%這樣的環境變量指向程序的安裝位置。對於64位程序,它會進入正常位置。對於32位程序,它會將其重定向到新程序 Program Files (x86) 夾。

雖然,至少對於Visual Studio中新的.Net內容,他們現在擁有App.Local變量,可以消除對此的全部需求。


11
2018-06-27 17:36



這並不能解釋它。誰正在使用環境變量,為什麼它會關心程序是32位還是64位? - Synetech
@Synetech - 程序的作者使用環境變量。至於它關心的原因是因為對dll的引用。您無法在64位進程內加載32位dll,反之亦然。 - Ramhound
怎麼做 %programfiles%, %programfiles(x86)%, 要么 %programw6432% 在那裡有所作為?任何共享DLL都進入單個WinSxS目錄,任何非共享DLL都與可執行文件一致。這只是因為某些原因你安裝了同一程序的32位和64位版本,即便如此,你仍然要保留帶有32位可執行文件的32位DLL和帶有64位DLL的32位DLL 64位可執行文件。你可以這樣做: %programfiles%\CoolApp\bin\32和%programfiles%\ CoolApp \ bin \ 64`,為什麼單獨的頂級文件夾? - Synetech
@Synetech當然可以; %programfiles%已經有一段時間了。如果您在64位計算機上安裝32位程序,有一個地方會導致該32位應用程序出現問題。儘管如此,可以將%programfile%重定向到32位應用程序的(x86)版本,以及64位非x86版本。 - Andy
如果沒有隱式重定向,我認為人們不會那麼困惑 - kommradHomer


Microsoft從32位到64位的轉換解決方案一直是為大多數32位應用程序添加傳統支持。換句話說,大多數32位應用程序將在64位操作環境中運行。請記住,在64位體系結構上運行的其他操作系統根本無法加載或運行32位應用程序。

為了幫助簡化轉換,Microsoft已指定默認情況下,所有32位應用程序都應加載到Program Files(x86)文件夾中,而不是與常規Program Files文件夾中的真正64位應用程序混合使用。

資源 

“如果我以某種方式避免重定向機制並強制將所有內容安裝到真正的C:\ Program Files \?那會怎麼樣?” 

沒有。這兩個程序目錄僅用於組織,或者將具有兩個版本的程序保持為32位和64位版本,例如Internet Explorer。但是你可以在“Program Files”中安裝一個32位程序,在“Program Files x86”中安裝一個64位程序,程序將運行相同的程序。

維基 說:

某些應用程序安裝程序會拒絕安裝路徑位置中的空間。對於32位系統,Program Files文件夾的短名稱是 PROGRA〜1。對於64位系統,64位Program Files文件夾的短名稱是Progra~1(與32位系統相同);而現在是32位程序文件(x86)文件夾的短名稱 PROGRA〜2


8
2018-06-28 16:28



呵呵。好文章。對該文章的評論聽起來與此處的評論完全相同。更糟糕的是,這篇文章來自兩年多以前,它只是表明這個問題並不新鮮,如果它仍然無法得到權威性的回答,那麼我想它永遠不會(除非Windows團隊的某些人加入)。哦,好吧,我想我們都應該停止擔心並學會愛炸彈,呃,我的意思是和它一起生活。 +1用於指出文章,並表明這個問題已經存在了很長時間。 - Synetech
@Synetech謝謝!是的,放置文章鏈接背後的想法與你得到的相同。這是一個非常古老的問題,但IDK為什麼人們還沒有得到它。但是,MS應該為此問題編寫KB或文檔:) - avirk
是的,他們應該,特別是因為不僅僅是開發人員要求,即使是普通用戶也不知道。不幸的是,微軟的文檔通常不太好。 - Synetech
@Synetech呀! MS文檔大部分時間都很糟糕。但是,他們也寫了一些好文章,我很確定它們是可數的;) - avirk


原因是為開發人員將程序升級到64位更容易。在以32位模式編譯時,它們不必編寫任何自定義代碼來檢查一個目錄中的程序,而在64位模式下編譯時,它們不必編寫另一個目錄中的程序。他們只是檢查 C:\Program Files,並且在32位模式下運行時,會自動更改為 C:\Program Files (x86) 通過64位Windows。同樣,註冊表項在32位和64位程序之間隔離。

這可以防止不知情的開發人員發生衝突,他們只是將編譯模式更改為64位而不需要太多考慮,並且阻止了希望用戶能夠安裝他們的32位和64位版本的開發人員的大量工作。軟件同時。


但是為什麼任何程序都希望同時安裝這兩個版本呢?一個例子:Photoshop和IE的擴展名是原生的.dll。您不能在同一進程中混合使用32位和64位代碼,因此32位版本的插件不能與64位版本一起使用,反之亦然。因此,Photoshop / IE  允許安裝兩個版本,或冒著破壞現有插件的巨大基礎的風險。


6
2018-06-27 18:48



+1至少你解決了為什麼普通用戶會同時擁有這兩個版本的基本問題。 - Synetech


在“Program Files(x86)”上運行的程序使用 WOW64 子系統(Windows 64位上的Windows 32位是一組驅動程序和API,旨在通過x64體系結構系統運行x32應用程序):

WoW64子系統包含一個輕量級兼容層   在所有64位版本的Windows上都有類似的接口。它旨在   創建一個32位環境,提供所需的接口   在64位系統上運行未修改的32位Windows應用程序。   從技術上講,WoW64是使用三個動態鏈接庫實現的   (DLL)中:

  • Wow64.dll,Windows NT內核的核心接口,可在32位和64位調用之間進行轉換,包括指針和調用   堆棧操作
  • Wow64win.dll,為32位應用程序提供適當的入口點
  • Wow64cpu.dll,負責將處理器從32位切換到64位模式

64位系統需要“模擬”32位應用程序,這就是Windows需要“隔離”兩個Program Files文件夾的原因。


5
2018-06-27 17:32



但為什麼它必須把它放在不同的文件夾中? Windows已經完全能夠通過查看PE頭來確定可執行文件的體系結構。為什麼加載可執行文件時不能加載適當的環境? - Synetech
我認為這只是微軟的一個選擇,可以在打開程序時輕鬆向用戶展示他們想要的兩個程序版本的架構。我的意思是,如果沒有這兩個文件夾,並且它對用戶是透明的(如果它自動切換),他們不知道是否運行32或64位應用程序,甚至,他們不知道打開哪個程序如果在64位上運行.. - Diogo
64位版本的IE因其糟糕而聞名。 - Samuel Edwin Ward
MS建議使用office32,除非您使用的數據集大到足以超出內存限制。我認為有必要重新編譯二進制插件以使用office64;結合在正常使用情況下不給予任何好處是決定的背後。 - Dan Neely
我想你會發現顯式安裝到Program Files(x86)文件夾中的64位程序可以正常工作(在大多數情況下,反之亦然)。 Windows不使用文件夾位置來確定如何處理可執行文件。 - Harry Johnston


有趣的是,這里和互聯網上的答案有很大差異。找到這個重要問題的準確答案一直是一個挑戰。互聯網上似乎有相當多的虛假信息,導致混亂。

我已經進行了大量的研究,得出了以下結論,我認為這是準確的:

  • 存儲應用程序的位置沒有區別。在運行時,Windows將確定應用程序是32位還是64位,並自動使用相應的DLL和註冊表部分。

這會自動發生,並且與應用程序的存儲位置無關。具有單獨的32位和64位文件夾沒有速度,可靠性或其他功能優勢。

默認分離為兩個文件夾('Program Files'和'Program Files(x86)')的唯一原因是,如果你有兩個版本的同一個程序(一個32位和64位版本),它提供了一個保持重疊文件分離的簡單方法。即使在這種情況下,只要所有文件名都是唯一的,它們實際上可以存在於同一文件夾中而沒有任何後果。

對上述結論有一個警告,那就是編碼不良的應用程序。如果應用程序有任何硬編碼的路徑,它將只使用該路徑。通常,路徑永遠不應該硬編碼到應用程序中,但偶爾程序員會犯這個錯誤。在這種情況下,程序將使用硬編碼路徑;安裝應用程序的目錄不會影響它實際查找文件的位置。


5
2017-10-16 19:57