x64 programming #1: 環境變數及特殊目錄..
摘要提示
- SpecialFolder 差異: x86 與 x64 平台下 Environment.SpecialFolder 的 ProgramFiles/CommonProgramFiles 會指向不同路徑
- 環境變數差異: PROCESSOR_ARCHITECTURE、ProgramFiles/ProgramFiles(x86)/ProgramW6432 等環境變數在 x86/x64 下值不同
- 路徑寫死風險: 在程式中硬編碼如 C:\Program Files\ 容易在 x64 相容模式下出錯
- WOW64 重新導向: x64 上執行的 32 位程式會在檔案系統與登錄機碼遭到自動重新導向
- System32 與 SysWOW64: x64 環境中 32 位程式對 system32 的存取會被導向到 syswow64（對應 32 位版本）
- API/檔案載入差異: 載入 DLL/EXE 或系統檔案時才會觸發 system32→syswow64 的導向
- 雙版本並存: x64 系統為相容性同時保留 32/64 位元檔案，導致系統磁碟占用更大
- 程式實務建議: 應透過 API 取得路徑/變數，避免自行拼接路徑
- 偵錯觀察重點: 同名路徑在不同位元模式下實際落點與顯示值可能不同，需以實際載入鏈路驗證
- 官方文件參考: 建議閱讀 MSDN「Programming Guide for 64-bit Windows」作為正確指引
全文重點
本文以實測範例展示在 x64 Windows 上，應用程式以 x86 或 x64 模式執行時，系統特殊目錄與環境變數的差異，並說明 WOW64 相容層的重新導向機制可能帶來的迷惑與陷阱。作者先以 C# 列舉 Environment.SpecialFolder，發現 ProgramFiles 與 CommonProgramFiles 的實際路徑會隨編譯目標改變：x86 模式下指向 C:\Program Files (x86) 與其 Common Files；改為 x64/Any CPU 後則指向 C:\Program Files 與 C:\Program Files\Common Files。這說明若在程式中將 Program Files 類路徑寫死，於 x64 相容情境下很可能失準。
接著列印所有環境變數，對照 x86 與 x64 執行結果。關鍵變數如 PROCESSOR_ARCHITECTURE 在 x86 模式為 x86，x64 模式為 AMD64；ProgramFiles/ProgramFiles(x86)/ProgramW6432/CommonProgramFiles/… 等一系列變數在兩種位元模式下值各異，提供判斷或正確定位安裝/資料路徑的依據。特別是 ProgramW6432 與 PROCESSOR_ARCHITEW6432 這類僅在 WOW64 情境中出現的變數，能幫助 32 位程式在 x64 系統上定位 64 位的 Program Files 或辨識宿主架構。
文中指出多處系統資源會在 x64 上對 32 位程式進行轉譯或重新導向，包括 Win32 API、Registry、檔案系統。作者特別討論了 c:\Windows\system32 的特殊性：雖然 32 位程式在 x64 上讀取/載入 system32 下的系統元件（DLL/EXE）時會被導向到 c:\Windows\syswow64（即 32 位版本的系統檔），但在一般列路徑或某些檔案操作時看到的仍可能是 system32 路徑，且以檔案總管觀察會顯示檔案確實存在於 system32，這造成表象與實際載入目標不一致的錯覺。真正影響相容與正確性的，是載入流程是否經由 WOW64 導向至對應位元的系統檔案。
在實務上，這些差異意味著：不要在程式中自行拼接或硬寫系統路徑（如 Program Files 或 system32），而應透過 .NET 的 Environment.SpecialFolder、Environment.GetEnvironmentVariables，或對應的 Win32 API/Installer 機制取得正確路徑。此外，若需與系統元件互動，必須意識到 WOW64 的重導規則：32 位應用載入系統 DLL/EXE 時會落到 syswow64 版本；登錄也有 HKLM\Software 與 WOW6432Node 之分。由於 x64 為相容性保留兩套 32/64 檔案與設定，系統體積難免膨脹。
最後，作者強調自己的測試屬「土法煉鋼」，真正應遵循的是微軟官方文件 MSDN「Programming Guide for 64-bit Windows」，其篇幅不長，卻系統性地闡明 64 位 Windows 的開發規則與最佳實務，能避免憑印象或道聽途說造成的開發偏誤。下一篇則預告將討論 IIS6 與 x64 的相容與「靈異事件」。
段落重點
序言：從路徑差異開啟 x64 相容議題
作者說明在轉向 x64 開發的過程中遇到許多相容問題，決定從最常見的「目錄路徑」談起。點出若在程式中硬寫像 C:\Program Files\ 的路徑，在 x64 上以 x86 相容模式執行時將產生錯誤或指向錯誤位置，為下文的實測鋪陳動機。
列舉 Environment.SpecialFolder：x86 vs x64 的 ProgramFiles 差異
以 C# 列舉 Environment.SpecialFolder 並印出實際路徑。結果顯示在 x86 目標上，ProgramFiles 與 CommonProgramFiles 會指向 C:\Program Files (x86)\ 與其 Common Files；改為 x64/Any CPU 時則指向 C:\Program Files\ 與 C:\Program Files\Common Files。其他使用者相關資料夾（桌面、文件、AppData 等）一致，但這兩個與安裝位置密切相關的資料夾在兩種位元模式下不同，突顯不可硬寫路徑，應使用 API 取得。
列舉環境變數：識別位元架構與安裝路徑的可靠方式
再輸出所有環境變數，比對 x86 與 x64 情況。關鍵差異包括 PROCESSOR_ARCHITECTURE（x86 vs AMD64）、ProgramFiles/ProgramFiles(x86)/ProgramW6432、CommonProgramFiles/… 及 PROCESSOR_ARCHITEW6432 等。這些變數在 WOW64 情境中提供 32 位程式定位 64 位 Program Files 的能力，亦可用來判斷當前進程/系統架構。實務上應讀取這些變數或使用對應 API，而非硬寫安裝與系統路徑。
WOW64 重新導向：檔案系統與登錄的雙生世界
作者提醒在 x64 上跑 32 位程式時，Win32 API、登錄（Registry）與檔案系統會發生重新導向，以維持相容。以 system32 為例：文件指出 32 位程式對 c:\Windows\system32 的存取會導向 c:\Windows\syswow64（其中存放 32 位元 DLL/EXE）。然而一般列印路徑或檔案總管觀察仍可能顯示為 system32，且在某些檔案操作下似乎也寫入了 system32。關鍵在於當程式「載入」系統 DLL/EXE 或需要系統元件時，WOW64 才會將請求導向到 syswow64 的 32 位版本，造成表象與實際載入目標的落差。
實務建議與官方資源：避免憑印象，依 API 與文件行事
總結實務建議：不要自行拼接系統路徑；使用 Environment.SpecialFolder、環境變數與官方 API 取得正確位置；了解 WOW64 在檔案與登錄的導向規則，以避免載入錯誤位元的元件。指出 x64 系統為相容性保留 32/64 兩套資源，導致系統體積增加屬正常現象。最後推薦閱讀 MSDN「Programming Guide for 64-bit Windows」，內容簡潔但能提供正確框架，避免以零散測試或片面經驗作為判斷依據，並預告後續將分享 IIS6 與 x64 的相關問題。
資訊整理
知識架構圖
- 前置知識：
- Windows 檔案系統與目錄結構（Program Files、System32、用戶資料夾）
- x86 與 x64 架構差異、WOW64 相容層的基本概念
- .NET 中 Environment 類別（SpecialFolder、GetEnvironmentVariables）
- Windows 環境變數的用途與常見鍵名
- 核心概念：
- 位元數與路徑/變數的關聯：同一台 x64 Windows，上述路徑與變數會隨「進程位元數」不同而有所差異
- WOW64 重新導向：檔案系統與登錄在 x86 進程下會被導向至 32 位元對應位置
- Program Files 分流：Program Files 與 Program Files (x86)、Common Files 分別對應 64/32 位應用安裝位置
- System32 與 SysWOW64：名稱與內容相反直覺（System32 放 64 位、SysWOW64 放 32 位）
- 正確存取方式：避免硬編碼，使用 API（Environment.SpecialFolder、環境變數）與官方文檔規範
- 技術依賴：
- .NET Framework 的 Environment.SpecialFolder 和 Environment.GetEnvironmentVariables
- Windows WOW64 子系統決定的檔案/登錄重新導向規則
- Visual Studio 平台目標設定（x86、x64、Any CPU）影響進程位元數
- Windows 系統目錄與已安裝元件之位元數版本
- 應用場景：
- 安裝器與更新器決定安裝路徑（32/64 位）
- 應用程式存取系統檔案、呼叫 DLL/EXE（確認載入位元數）
- 讀寫使用者與共用設定資料夾（Documents、AppData、ProgramData）
- 跨位元互操作、偵錯 x86 程式在 x64 系統上的行為
學習路徑建議
- 入門者路徑：
- 了解 x86 vs x64 與 WOW64 的基本差異
- 練習使用 Environment.SpecialFolder 取得標準資料夾，而非硬編碼路徑
- 使用 Environment.GetEnvironmentVariables 觀察 x86 與 x64 進程的差異
- 進階者路徑：
- 深入閱讀 MSDN「Programming Guide for 64-bit Windows」
- 實作在 x64 系統中同一段程式碼以 x86/x64 兩種平台目標執行並比較輸出
- 學會辨識與處理 System32/SysWOW64 導向、登錄 Wow6432Node 導向
- 實戰路徑：
- 在安裝器與應用程式中，統一以 API 取路徑與變數；針對外部元件載入判斷位元數
- 測試檔案/登錄存取在 x86 與 x64 目標的實際行為，並建立自動化檢查
- 建置 Any CPU 策略：必要時提供雙位元部署或以位元橋接技術處理
關鍵要點清單
- 不要硬編碼路徑：使用 Environment.SpecialFolder 取得標準資料夾，避免直接寫 C:\Program Files 等（優先級: 高）
- 進程位元數決定結果：同一台機器上，x86/x64 進程得到的 ProgramFiles/常用資料夾路徑不同（優先級: 高）
- WOW64 檔案導向：x64 上的 x86 進程對 System32 的存取會導向到 SysWOW64（優先級: 高）
- System32 與 SysWOW64 內容：System32 多為 64 位元檔案，SysWOW64 為 32 位元版本（優先級: 高）
- Program Files 分流：Program Files 指向 64 位，Program Files (x86) 指向 32 位安裝位置（優先級: 高）
- 關鍵環境變數（x64 進程）：PROCESSOR_ARCHITECTURE=AMD64、ProgramFiles=64 位、ProgramFiles(x86)=32 位（優先級: 中）
- 關鍵環境變數（x86 進程於 x64）：PROCESSOR_ARCHITECTURE=x86、PROCESSOR_ARCHITEW6432=AMD64、ProgramW6432=64 位 Program Files（優先級: 高）
- CommonProgramFiles 對應：同樣分為 64 位與 (x86) 兩個位置，依進程位元數/變數名取用（優先級: 中）
- AppData 與 ProgramData：使用 ApplicationData、LocalApplicationData、CommonApplicationData 取得正確位置（優先級: 中）
- 外部 DLL/EXE 載入：確保載入之元件與進程位元數一致，否則會失敗或被導向（優先級: 高）
- Visual Studio 平台目標：x86、x64、Any CPU 會直接影響上述行為與輸出結果（優先級: 高）
- 登錄重新導向：x86 進程會使用 Wow6432Node 分支，需依位元數判斷讀寫位置（優先級: 中）
- 測試策略：在 x64 系統中，同程式以 x86 與 x64 兩種目標測試，驗證路徑/變數/載入行為（優先級: 高）
- MSDN 指南為權威：參考 Programming Guide for 64-bit Windows，避免道聽塗說（優先級: 高）
- 磁碟空間考量：x64 系統會同時保有 32/64 位元檔案，磁碟占用較大（優先級: 低）
