為什麼 Windows 11 將 64 位元檔案存放在 System32，卻將 32 位元檔案存放在 SysWOW64

Windows 11 的 System32 包含 64 位元檔案，而 SysWOW64 則包含 32 位元檔案

MS 並未提供 32 位元版本的 Windows 11，但這套作業系統仍必須支援數十年來累積的 32 位元應用程式。其解決方案仰賴兩個系統目錄：System32 用於原生 64 位元檔案，而 SysWOW64 用於 32 位元檔案。當 32 位元應用程式嘗試存取 System32 時，WOW64 檔案系統重新導向器會自動將其導向 SysWOW64。

在執行 Windows 11 26H2 的電腦上，這兩個目錄都包含名為 kernel32.dll 的檔案。這些檔案的大小不同，因為其中一個是為 64 位元應用程式設計，另一個則供 32 位元軟體使用。

在 Windows 11 26H2 中，System32 與 SysWOW64 都有 Kernel32.dll，但 64 位元與 32 位元版本的檔案大小不同

如果 MS 能像 Apple 一樣終止對 32 位元軟體的支援，Windows 或許就不再需要這套相容性架構。然而，現有 32 位元應用程式數量龐大，使得這項轉換困難許多。

為什麼 System32 包含 64 位元檔案

在 16 位元 Windows 時代，系統檔案存放於 C:\Windows\System。當 32 位元 Windows 問世時，MS 為 32 位元檔案新增了 C:\Windows\System32，這也解釋了該目錄名稱的由來。

等到 64 位元 Windows 開發時，許多應用程式已將 System32 路徑寫死在程式碼中，而不是透過 GetSystemDirectory 函式取得。MS 資深工程師 Raymond Chen 解釋，這些應用程式重新編譯成 64 位元程式後，仍會繼續在 System32 中尋找檔案，但此時它們預期在該處找到的是 64 位元檔案。

批次檔也造成了類似的相容性問題。如果 System32 繼續存放 32 位元工具，執行 System32\reg.exe 的指令碼將會修改 32 位元登錄檢視，而不是預期的 64 位元版本。

因此，MS 決定讓 System32 包含與作業系統原生架構相符的檔案。其「檔案系統重新導向器」文件指出，在 64 位元 Windows 上，%windir%\System32 目錄保留給 64 位元應用程式使用。

MS 建立 64 位元版本時，大多數 DLL 的名稱也維持不變。因此，kernel32.dll 這個遵循舊式 MS-DOS 命名慣例的名稱，在兩個位置都仍稱為 kernel32.dll。於是，32 位元版本便需要使用另一個獨立目錄。

Chen 指出，System32 中的「32」如今只不過是名稱的一部分，已無法準確描述其內容。他表示，在理想的設計中，這個資料夾或許應該命名為 SysExec，因為它會提供適合目前執行程式的檔案。

WOW64 代表「64 位元 Windows 上的 32 位元 Windows（Windows 32-bit on Windows 64-bit）」。這是 MS 為 32 位元應用程式提供的相容層。SysWOW64 中的「64」指的是主機作業系統，儘管該目錄本身存放的是 32 位元檔案。諷刺的是，64 位元應用程式並不使用名稱中含有「64」的系統資料夾。

Windows 11 如何將 32 位元應用程式重新導向至 SysWOW64

32 位元處理程序無法載入 64 位元 DLL 來執行，64 位元處理程序也無法載入 32 位元 DLL。若沒有重新導向，向 System32 要求 kernel32.dll 的 32 位元應用程式將會收到不相容的檔案。

在 x64 Windows 上，每當 32 位元應用程式要求存取受保護的 System32 路徑時，WOW64 都會以透明方式重新導向相關的檔案系統要求。應用程式通常不會察覺路徑已遭變更。

若要示範此行為，可以從 C:\Windows\SysWOW64\cmd.exe 開啟 32 位元命令提示字元。在該視窗中，echo %PROCESSOR_ARCHITECTURE% 會傳回 x86，而標準的 64 位元命令提示字元則會顯示 AMD64。在兩個視窗中執行 dir C:\Windows\System32\kernel32.dll，即使輸入的是相同路徑，也會顯示不同的檔案大小，因為 32 位元處理程序會被重新導向至 SysWOW64 中的版本。

32 位元命令提示字元顯示 x86，並在要求存取 System32 時存取 SysWOW64 版本的 kernel32.dll

就連當時任職於 MS Visual Studio 團隊的 Matt Pietrek 也遇過這種行為。他在 2006 年的一篇 MSDN Magazine 文章中提到，自己曾從 32 位元命令提示字元列出兩個目錄中的 kernel32.dll，結果看起來完全相同，一開始讓他感到相當困惑。

WOW64 的功能不僅限於檔案系統重新導向。它透過登錄重新導向器，在 HKEY_LOCAL_MACHINE\Software\Wow6432Node 下為 32 位元應用程式提供獨立的登錄檢視。它也會將這些應用程式的 %ProgramFiles% 環境變數設為 Program Files (x86)。

Windows 11 上的 32 位元應用程式會在 WOW6432Node 下取得獨立的登錄檢視

MS 指出，使用者帳戶控制有一項不尋常的例外狀況。如果開啟重新導向的檔案會觸發 UAC 提示，系統便不會進行重新導向，Windows 反而會啟動 64 位元版本。因此，開發人員應視情況明確指定 SysWOW64 路徑，或以系統管理員身分執行 32 位元應用程式。

使用虛擬 Sysnative 目錄

Sysnative 是只有 32 位元應用程式才能使用的虛擬目錄。它實際上並不存在於 C:\Windows 下，64 位元應用程式也無法存取。在 64 位元檔案總管的網址列輸入 C:\Windows\Sysnative 會出現錯誤，但從 32 位元命令提示字元執行 dir C:\Windows\Sysnative\cmd.exe 則可正常運作。

Sysnative 可供 32 位元應用程式使用，但無法透過 64 位元檔案總管存取

開發人員可呼叫 Wow64DisableWow64FsRedirection 函式來停用重新導向，但這麼做會影響目前執行緒上的每項檔案操作。MS 警告，停用檔案系統重新導向可能導致 DLL 載入失敗。

Chen 將 Sysnative 形容為「針對局部問題的局部解決方案」。他先前曾建議開發人員不要與模擬器對抗，並建議在需要原生 64 位元操作時，由 32 位元安裝程式啟動 64 位元安裝程式。許多相容性問題都是因為 32 位元應用程式試圖表現得像 64 位元處理程序而產生。

六個 System32 資料夾不受 WOW64 重新導向影響

MS 指出，有六個 System32 子目錄可供 32 位元應用程式直接存取，而不會遭到重新導向。豁免清單曾隨時間變更。例如，在 Windows Vista、Windows XP、Windows Server 2003 與 Windows Server 2008 上，driverstore 仍會被重新導向。

MS 並未說明每個目錄獲得豁免的原因。不過，其中部分目錄包含 32 位元與 64 位元應用程式都必須以一致方式存取的共用資料，例如 drivers\etc 下的 hosts 檔案。

Windows 11 Arm 版正在移除 SysArm32

在 Snapdragon X 筆電等採用 Arm 架構的電腦上，32 位元 x86 應用程式同樣會使用 SysWOW64。過去，32 位元 Arm 應用程式會被重新導向至名為 SysArm32 的第三個目錄。

根據 MS 的實作文件，在 Arm64 系統上，WOW64 會透過名為 xtajit.dll 的模擬器轉譯 x86 程式碼。相比之下，x64 處理器能以原生方式執行 32 位元程式碼，並由 Wow64Cpu.dll 管理不同執行模式之間的切換。

MS 的 Arm 開發人員文件目前指出，Arm 電腦已不再支援 32 位元 Arm 應用程式。先前存放在 SysArm32 目錄中的系統二進位檔也正在移除。標準 x86 應用程式無論是 32 位元或 64 位元版本，仍可透過 Prism 模擬執行；Prism 已於去年加入 AVX 與 AVX2 支援。

相容性優先於更清楚的命名

MS 原本可以在 20 年前重新命名 System32，但這麼做會導致許多既有應用程式無法運作。因此，該公司選擇圍繞既有目錄名稱建立重新導向器、虛擬別名與一系列豁免規則。這反映出 MS 一貫以相容性為優先的做法，就如同為舊版軟體保留 Windows 95 堆積管理員等元件。

並非所有應用程式都能順利撐過轉移至 64 位元 Windows 的過程，3D 彈珠台就是一個著名案例。雖然 SysExec 之類的名稱會更清楚，但過時的目錄名稱所造成的傷害，仍遠小於大規模的應用程式與安裝程式故障。