x86? x64? 傻傻分不清楚…
摘要提示
- 平台轉換差異: 16→32 與 32→64 的相容機制與限制完全不同，影響程式部署策略。
- WOW 相容層: x64 以 WOW64 在 user mode 提供 32 位元相容，但同一個 process 不能混用 32/64 程式碼。
- 系統路徑分流: x64 系統將 Program Files、System32/SysWOW64、Registry 等劃分兩套，易致路徑/元件混淆。
- .NET 跨平台性: .NET Any CPU 多數情況可跨 x86/x64，但牽涉 COM/原生元件時仍可能在執行期爆雷。
- COM 限制: x86-only 與 x64-only COM 無法在同一個 process 互通，in-process 呼叫必須選邊站。
- 常見缺件: CDO、JET、部分 ODBC、相機 RAW Codec 等常見元件缺 x64 版，迫使應用退回 32 位元。
- Media Encoder 教訓: x64 並不會自動包含 x86 版本，需分別安裝，且兩版行為可能不一致。
- 執行期陷阱: Any CPU 在 x64 會原生以 64 位元執行，直到 runtime 才因缺元件失敗，不易即時定位。
- 解法策略: 將功能切成多個獨立 exe，分別以 x86 或 x64 執行，透過跨程序協作繞過 bitness 衝突。
- 效能觀察: 拆分後可並行運作，實務上仍能高效利用多核心 CPU，達到可接受的效能與穩定性。
全文重點
作者長期在 x86 與 x64 間切換，分享數個在 64 位元環境踩雷的實務心得。首先指出 32→64 的過渡與 16→32 不同：早期靠 v86 與 wowexec 集中執行 16 位元程式；現今的 x64 以 WOW64 在使用者模式提供 32 位元相容層，但同一個 process 無法同時載入 32 與 64 位元程式碼，必須選擇其一。因此只要涉及 in-process COM，就會遇到位元數不相容的硬限制。
在 x64 系統中，系統目錄與註冊機碼會分成兩套（如 Program Files 與 Program Files (x86)、System32 與 SysWOW64），這有助隔離但也增加路徑判斷與部署複雜度。就開發框架而言，.NET 因 CLR 隔離，理論上以 Any CPU 編譯可自動適應平台；但一旦程式使用到沒有對應 x64 版本的 COM/原生元件，問題就會在執行期浮現。作者實際遇到的案例包括：.NET SMTP 包裝使用的 CDO 在 x64 缺乏對應，Any CPU 編譯可通過編譯卻在執行期拋錯，排查困難；另一例是 WPF 影像處理依賴 Canon RAW Codec，而該 Codec 未提供 x64 版，導致應用只能以 x86 模式運行。
後續在處理家中相機 AVI 轉檔流程時，原以為安裝 x64 的 Windows Media Encoder 就能同時提供 x86/x64 元件，結果需分別安裝兩個版本才行，且透過元件自動化轉檔在 x86 版會卡在 100% 不自動結束，但 x64 版正常。進一步嘗試發現 x86 程式不能直接呼叫 x64 COM，若改成 x64 又用不到 Canon RAW Codec，形成兩難。最終的務實解法是將系統拆分為多個獨立可執行檔，各自以合適的位元數執行，再以跨程序方式協作，成功兼顧功能與穩定性。此作法也意外帶來並行效益，能有效吃滿多核心 CPU 的運算資源。文章總結：在 x64 環境中，不要僅依賴 Any CPU 想像「一次搞定」，凡涉及 COM/原生依賴，必須清點元件位元版本、妥善規劃部署與進程邊界，才能避開執行期地雷。
段落重點
緣起與主旨：x86/x64 之間的日常坑
作者經常在 x86 與 x64 環境切換，近期無論工作或個人專案都頻繁遇到 64 位元相關問題，決定記錄心得避免重蹈覆轍。主旨是提醒開發者：即使使用 .NET 且以 Any CPU 編譯，也不代表萬無一失；真正的挑戰是在執行期遇到 32/64 相依的元件不相容。
16 位元到 32 位元 vs 32 位元到 64 位元
回顧歷史，16→32 的轉換主要靠 v86 與 wowexec 提供相容；進入 32→64 時代，Windows 採用 WOW64 在使用者模式提供 32 位元相容層，但規則嚴格：同一個 process 不能混載 32 與 64 位元程式碼。這個改變讓單一進程內使用多個 COM/原生元件時，若位元數不一致將直接失敗，迫使架構設計時需及早規劃邊界。
x64 + WOW：相容機制與限制
WOW64 讓多數 32 位元應用可在 x64 上運作，但它不解決跨位元 in-process 互通的問題。凡是以 COM 方式在同進程內載入的元件，必須與宿主同位元。若應用倚賴的驅動、編解碼器或舊式 COM 僅有 x86 版，就只能讓整個應用維持 x86，或進行架構切分。
系統目錄與註冊表雙軌制
在 x64 Windows，Program Files/Program Files (x86)、System32/SysWOW64 以及 Registry 都有分流與重導機制，方便隔離但也加深部署與偵錯難度。常見誤判包括：以為 System32 一定是 32 位元、或誤將 x86 元件裝到 x64 路徑。這些差異在自動化腳本、外部工具呼叫與元件註冊時尤其容易踩雷。
.NET Any CPU 的盲點
雖然 .NET 靠 CLR 提供跨平台彈性，多數純受管碼能在 x86/x64 間順暢切換；但只要牽涉 COM/原生呼叫，Any CPU 會在 x64 主機上以 64 位元執行，直到 runtime 才因缺少 x64 元件（如 CDO、JET、部分 ODBC）而失敗，問題難以在編譯期暴露。實務建議：對有原生相依的模組，明確指定 x86 或 x64，而非盲用 Any CPU。
實例一：SMTP/CDO 與 Canon RAW Codec
作者在 .NET 使用 SMTP 包裝（底層倚賴 CDO）時，因 CDO 無 x64 版本導致執行期錯誤；同樣地，WPF 影像處理需用到 Canon RAW Codec，而廠商未提供 x64 版，迫使整體改以 x86 執行。這類第三方編解碼器與舊式系統元件，是 x64 遷移最常見的阻礙。
實例二：Media Encoder 32/64 並存與行為差異
處理家用相機 AVI 轉檔時，發現 Windows Media Encoder 並不會隨 x64 自動包含 x86 版，需分別安裝兩個版本。更棘手的是，透過 COM 自動化以 32 位元元件轉檔會卡在 100% 不結束，而 64 位元版運作正常。嘗試讓 x86 程式呼叫 x64 COM 失敗，揭示跨位元 in-process 的硬限制。
最終解法：多進程切分與並行
面對相依元件位元數各異的現實，作者將系統切成多個獨立可執行檔，分別編譯為 x86 或 x64，由外部協作串接流程。此舉避免在同一進程混載不同位元元件，成功通關部署與相容性問題，並帶來意外收穫：多進程得以並行運作，更有效地利用四核 CPU 的運算資源，整體效能可接受。總結而言，在 x64 遷移時應清點原生/COM 相依、明確指定平台目標、規劃進程邊界與部署路徑，才能避開執行期陷阱。
資訊整理
知識架構圖
- 前置知識：學習本主題前需要掌握什麼？
- CPU 與作業系統位元概念（x86/32 位元、x64/64 位元）
- Windows 行程架構與位元相容層（WOW/WOW64）
- .NET 平台目標（AnyCPU/x86/x64）、CLR 與原生程式差異
- COM/In-Process 元件的位元相容性原則
- Windows 檔案系統與登錄在 x64 下的重導（Program Files、System32/SysWOW64、WOW6432Node）
- 核心概念：本文的 3-5 個核心概念及其關係
- 位元相容與隔離：同一個 Process 不能混用 32 與 64 位元 Code（COM In-Process 更嚴格）→ 驅動元件、Codec、COM 需與宿主位元一致
- WOW64 相容層：在 x64 上執行 x86 應用的機制，伴隨檔案/登錄重導 → System32/SysWOW64 與 Program Files/Program Files (x86) 分家
- .NET 的跨位元彈性與陷阱：AnyCPU 在 x64 會以 64 位元執行，但只要涉及特定位元的外部相依（COM、Codec、ODBC/JET），就會在執行期出錯
- 元件供應狀況決定策略：當第三方僅提供 x86（如 CDO、Canon RAW Codec、某些 ODBC/JET）或需分別安裝 x86/x64（如 Media Encoder）時，需調整編譯目標與程序邊界
- 架構拆分以解相容衝突：以多個獨立 .exe 分別在 x86/x64 下執行，透過程序間通訊完成工作流程
- 技術依賴：相關技術之間的依賴關係
- .NET 程式 → CLR 執行位元（取決於 Platform Target 與宿主 OS） → 呼叫 COM/Codec/驅動必須相同位元
- Script（cscript/wscript）→ 需選擇對應位元的宿主（%SystemRoot%\System32 與 %SystemRoot%\SysWOW64 的 cscript.exe 不同位元）
- Media/Codec/ODBC/JET/SMTP(CDO) → 是否提供 x64 版本決定可否在 64 位元 Process 內使用
- 檔案/登錄路徑 → 受 WOW64 重導影響（System32 是 64 位元，SysWOW64 是 32 位元；登錄有 WOW6432Node）
- 應用場景：適用於哪些實際場景？
- 將既有 x86 應用或腳本遷移到 x64 Windows 的相容性評估與改造
- .NET 應用同時使用多個僅支援單一位元的 COM/Codec/驅動
- 自動化轉檔流程（Media Encoder/影像處理）在 x64 環境的組態與分工
- 伺服器（如 IIS）上同機部署 x86 與 x64 相依的元件與服務
- 安裝包與部署腳本需根據位元選擇安裝/呼叫正確版本
學習路徑建議
- 入門者路徑：零基礎如何開始？
- 了解 x86/x64 基本差異、Process 位元不可混用原則
- 認識 Windows 的 Program Files/Program Files (x86)、System32/SysWOW64、登錄 WOW6432Node
- 在 .NET/Visual Studio 中操作 Platform Target（AnyCPU/x86/x64），測試在 x64 OS 的行為
- 進階者路徑：已有基礎如何深化？
- 實驗 WOW64 重導：分別呼叫 System32 與 SysWOW64 的 cscript.exe、觀察 COM 註冊位置
- 練習診斷 COM/Codec 相依：用 Process Explorer/Process Hacker 檢查模組位元；以 corflags、dumpbin 確認組件位元
- 設計在 x64 環境中同時支援 x86-only 與 x64-only 元件的架構（跨進程、多執行檔）
- 實戰路徑：如何應用到實際專案？
- 盤點第三方相依（COM、ODBC/JET、Codec、SMTP/CDO）之位元支援情況，形成支援矩陣
- 選擇 Platform Target 並規劃程序邊界：需要 x86 的部分獨立成可執行檔或服務，透過 IPC/檔案列隊/消息佇列協作
- 部署與測試：在 x64 機器上同時安裝 x86 與 x64 版本（如 Media Encoder），調整腳本與呼叫路徑，驗證端到端流程
關鍵要點清單
- 位元不可混用的進程原則: 同一個 Process 不能同時載入 x86 與 x64 模組（COM In-Process 尤其嚴格） (優先級: 高)
- WOW64 相容層: x64 Windows 以 WOW64 執行 x86 應用並做檔案/登錄重導，帶來路徑與註冊檢視差異 (優先級: 高)
- System32 與 SysWOW64 認知: System32 是 64 位元，SysWOW64 是 32 位元，名稱與實際內容相反易誤用 (優先級: 高)
- Program Files 分家: x64 上有 Program Files（64 位）與 Program Files (x86)（32 位），安裝與呼叫需對齊 (優先級: 中)
- .NET AnyCPU 陷阱: AnyCPU 在 x64 會變 64 位元，若呼叫僅有 x86 的 COM/Codec，將在執行期出錯 (優先級: 高)
- COM 位元相容性: 需安裝並註冊對應位元的 COM；x86 程式不可載入 x64 COM，反之亦然 (優先級: 高)
- 第三方元件供應差異: 部分技術（CDO、JET/某些 ODBC、某些相機 RAW Codec）可能無 x64 版，限制架構選擇 (優先級: 中)
- 腳本宿主位元選擇: 在 x64 機器上應用對應位元的 cscript/wscript（System32 vs SysWOW64）避免找不到元件 (優先級: 中)
- 雙版本安裝需求: 某些 Microsoft 元件（如 Media Encoder）需分別安裝 x86 與 x64 才能被各自位元程式使用 (優先級: 中)
- 架構拆分策略: 將系統拆成多個 .exe，分別以 x86/x64 執行，透過 IPC 協作以繞過位元相容限制 (優先級: 高)
- 依賴盤點與測試: 遷移到 x64 前先盤點並驗證所有外部依賴的位元支援與行為（包含 COM、Codec、ODBC、SMTP） (優先級: 高)
- 登錄重導認知: x64 登錄有 WOW6432Node 分支，x86 與 x64 註冊視圖不同，影響 COM 註冊與查找 (優先級: 中)
- 伺服器配置注意: 在 IIS/服務環境中需要決定 App Pool 是否啟用 32 位元模式以載入 x86 相依 (優先級: 中)
- 例外診斷技巧: 遇到莫名執行期錯誤時，優先檢查位元不相容與 WOW64 重導是否是根因 (優先級: 高)
- 效能與並行: 在拆分後可利用多程序提升並行度（例如影像/轉檔工作吃滿多核），但需平衡 IPC 成本 (優先級: 低)
