並行組件共享實作指南（一）：背景、策略比較與新組件編寫規範

摘要

探討 Windows 2000 / Windows 98 Second Edition 實現並行組件共享的機制，涵蓋新組件建立、DLL/COM 重定向解決版本衝突、編寫/安裝規範與重新打包測試指南。

前言：DLL Hell 的由來

現代 OS 與應用程式由大量共享組件構成。全域共享要求組件絕對向後相容，但實務上極難達成。應用程式可能無意間依賴組件的副作用行為；組件修正錯誤反而導致相依應用程式失效，即經典的「DLL Hell」。

隔離與並行共享

隔離是共享的對立面。選擇性隔離允許同一組件多版本共存，應用程式使用經設計測試的特定版本，不受其他應用程式安裝影響。Windows 2000/98 SE 引入並行共享，透過選擇性隔離大幅緩解 DLL Hell。

兩大並行策略

策略選擇建議

• 部署現有應用遭遇 DLL Hell → 使用 DLL/COM 重定向。
• 開發新應用/組件，預防 DLL Hell → 開發 並行組件。

建立新並行組件

並行組件為普通 COM/Win32 組件，但安裝於應用程式目錄（或子目錄）而非系統目錄。特定應用程式專用，與其他應用隔離。多版本可並行安裝於不同應用目錄，OS 可同時載入。

優勢：應用程式解除安裝時可安全刪除私有組件，不影響他應用。

註冊要求：必須正確向 OS 註冊，確保各版本不衝突（CLSID、ProgID、類型庫、執行緒模型等中繼資料跨版本不變）。

支援平台：Win2000、Win98 SE。舊版 Windows 視為全域共享（向後相容模式），應用程式需動態檢測 OS 版本決定共享策略。

並行組件編寫指南

一般原則

• 勿替換受「系統檔案保護」保護的檔案（.sys, .dll, .exe, .ocx）。
• 全面測試並行有效性，特別是共享區域；OS 不強制並行。
• 版本特定名稱集中定義於 #define，便於遷移版本（如 #define MyRegistryKey "MyAppv1.0.0.0"）。
• 警惕跨程序共享記憶體導致版本間干擾；共享資料結構須設計為並行感知（記憶體對映檔、Mutex、命名管道、硬體驅動）。
• 非持久資料存放 TEMP 目錄；使用者資料與應用程式資料明確分離，勿放全域位置。

增強組件健全性

• GUID 登錄項維護參考計數（RefCount），追蹤安裝/解除安裝次數。
• COM 註冊勿使用絕對路徑，依賴應用程式目錄搜尋順序。
• 變更 COM 中繼資料（執行緒模型等）視為新版本，需更名並指派新 GUID。
• 類型庫內嵌於 DLL，勿用 LoadRegTypeLib（登錄項為全域狀態，引用計數脆弱），改用 LoadTypeLib。
• 避免外部類型庫（OLEAUT 版本管理脆弱）。