小村軟體有限公司
日本語 English 한국어 繁體中文 العربية
聯絡我們
選單

COM / ActiveX / OCX 是什麼 - 差異與關係一次整理

· · COM, ActiveX, OCX, OLE, Windows 開發, Legacy 技術

COM／ActiveX／OCX 這 3 個單字，在 Windows 的 legacy 案子裡幾乎都會成套出現。

  • 廠商寄來 .ocx
  • Access 或 VB6 畫面上放著奇怪的元件
  • 別人剛剛說完「這是 COM」，轉眼又說「是 ActiveX 啦」
  • 緊接著 regsvr32、32bit／64bit、IE 模式等字眼一起湧上來

這條流程，基本上對話路面就會突然變泥濘。

原因是這些詞彙很相近，歷史上也大量重疊。
但在實務上，只要能把這幾個分清楚，調查、遷移、解釋的難度都會明顯下降。

本文會按照「差異與關係看得出來的順序」來整理 什麼是 COM、什麼是 ActiveX、什麼是 OCX。
特別會釐清 哪個是底層、哪個是元件、哪個是檔案。

1. 先下結論（一句話）

先給一個粗但好用的講法：

  • COM 是底層。它是 Windows 上元件之間互動的 binary 契約
  • ActiveX 是基於 COM 的元件脈絡，尤其常指「可嵌入宿主使用的 control」
  • OCX 是 ActiveX control 實作常見的檔案，以副檔名形式出現
  • 也就是說 COM = 機制、ActiveX = 元件的脈絡、OCX = 檔案，這樣記就好整理得多
  • 「ActiveX = 老 IE 上危險的那個東西」這個印象，只對一半。ActiveX 並非瀏覽器專用
  • 「OCX = ActiveX」在口語裡幾乎被當同義詞，但嚴格來說是把概念與副檔名混在一起
  • 現在新開發時不會拿它當主角，但既有 Windows 應用、Office、Access、裝置 SDK、內部 Web 中還會遇到

簡單說，先把下列 3 件事分開來看：

  1. 這是 COM 的話題嗎
  2. 這是 ActiveX control 的話題嗎
  3. 還是只是 看到 .ocx 檔案就這樣叫

把這 3 件事分清楚，迷霧會消散很多。

2. 本文所說的 COM / ActiveX / OCX

實務中這三個詞常常被混用，所以先固定一下本文的用法：

  • COM：Windows 的元件模型本身。介面、GUID、註冊、呼叫的底層
  • ActiveX：以 COM 為基礎的可嵌入 control 或其使用脈絡。實務上常指 ActiveX control
  • OCX：ActiveX control 實作常見的副檔名，.ocx

補充一下，歷史上 ActiveX 這個詞曾用得更廣。 但現在實務上遇到 ActiveX 讓人頭痛的地方，多半落在 control、嵌入、宿主、瀏覽器、註冊 這一帶。

所以本文基本上把 ActiveX 當成 ActiveX control 的同義詞 來處理。

3. 先用一張圖收攏

3.1. 關係圖

先用一張圖看全貌比較快：

flowchart LR
    COM["COM<br/>binary 契約的底層"] --> OLE["OLE / Automation<br/>嵌入、自動化的機制"]
    OLE --> AX["ActiveX<br/>以 COM 為基礎的 control 脈絡"]
    AX --> CTRL["ActiveX control"]
    CTRL --> OCX["OCX (.ocx)<br/>常見的實作檔案形式"]

    HOST["宿主／容器<br/>IE / Access / VB6 / MFC / WinForms"] --> CTRL

這張圖的重點是：COM 與 ActiveX 不是同一個詞。

  • COM 是底層
  • OLE／Automation 是嵌入與自動化的機制
  • ActiveX 是在其上的 control 脈絡
  • OCX 是 control 實作常見的檔案

所以當別人問「ActiveX 是不是就是 COM」，答案是 底層是 COM，但 ActiveX 並不等於 COM。

3.2. 最精簡的名詞整理

詞 第一印象
COM 機制、契約、底層
ActiveX 以 COM 為基礎的嵌入式元件脈絡
ActiveX control 真的放上宿主的元件本身
OCX ActiveX control 常見的副檔名
OLE／Automation 嵌入、自動化、整合的機制

最精簡的記法：

  • COM 是機制
  • ActiveX 是元件的脈絡
  • OCX 是檔案

4. 什麼是 COM

4.1. 一句話說

COM 是 Component Object Model 的縮寫，是 Windows 上元件之間互動的 binary 契約。

這裡說的 binary 契約，指的不是原始碼或語言規範上的約定，而是 在編譯後的層級也能維持的介面約定。 C++ 寫的元件能被其他語言或其他應用使用，就是因為這個契約。

用實務感覺來說，COM 與其說是 一種方便函式庫的發佈方式，不如說是 把實作藏起來，只靠契約對接的機制。

典型的 COM 元素例如：

  • 以 IUnknown 管理參考計數
  • 以 QueryInterface 找介面
  • 以 IID、CLSID 這類 GUID 做識別
  • 以 DLL 做 in-proc 使用
  • 以 EXE 做 out-of-proc 使用

簡言之，COM 是 Windows 元件化文化的底層。

4.2. COM 的核心要點

只看基本，COM 的核心是：

  • 以介面為中心
    • 先決定要公開什麼，再談實作
  • 以 GUID 識別
    • 類別與介面都有唯一識別碼
  • 宿主與實作分離
    • 呼叫方不必知道內部實作
  • 能跨行程
    • 不只同一行程，跨行程也能當元件用

這些就是為什麼 COM 不只是「老東西」的原因。 它在相當早期就已經把 以契約為基礎再利用 這件事做得夠紮實。

5. 什麼是 ActiveX

5.1. 一句話說

ActiveX 可以理解成：以 COM 為基礎的 可重用軟體元件，特別是 嵌入到宿主或容器中使用的 control。

實務上提到 ActiveX，多半說的就是 ActiveX control。 例子有按鈕、表格、圖表、日曆、檢視器、設備連線元件等。

所以 ActiveX 不是「一個獨立、高大上的巨大技術」，而是 在某個宿主中嵌入、工作的元件。這樣理解比較不容易偏。

5.2. ActiveX 並非瀏覽器專用

「ActiveX = Internet Explorer 那個」的印象相當強烈。這句話不算錯，但 僅僅這樣不夠。

ActiveX control 也被用在：

  • Access 表單
  • VB6 應用
  • MFC 的容器
  • Office / VBA 周邊
  • 從 WinForms 透過 COM 包裝器使用
  • IE 或相容運維脈絡

也就是說，ActiveX 是 Windows 應用本身長期使用的嵌入式元件技術，並非只在瀏覽器。

這點不理解，會把內部 Web 上的 ActiveX 與 Access 畫面裡的 ActiveX 看成兩回事。 實際上這兩者都相當接近 COM 家族。

6. 什麼是 OCX

6.1. 一句話說

OCX 是 ActiveX control 實作常用的副檔名。 在 Windows 現場看到 .ocx，相當高的機率是 嵌入式 control 類的 COM 元件。

常見情境：

  • 廠商 SDK 的發布物
  • VB6／Access／MFC 的舊專案
  • 安裝器裡會被註冊的檔案
  • 需要 regsvr32 的元件

這裡的重點是：OCX 是檔案形式，不是概念本身。 所以如果要簡單回答 OCX 是什麼，答案就是 實務上遇到 ActiveX control 的實體時，很常見的檔案。

6.2. 和 .dll 有什麼不同

這也是容易混亂的地方：

  • .ocx 相當強地暗示著「這是 ActiveX control」
  • .dll 可能是普通函式庫、COM server，也可能是 ActiveX 周邊的相依 DLL

所以看到 .ocx 基本上就是 ActiveX 那一路，但光看到 .dll 則還無法判斷是什麼。

實務上常見的組合：

  • vendorcontrol.ocx
  • vendorhelper.dll
  • vendorcore.dll

主角是 OCX，DLL 在旁邊輔助。

所以如果被問「OCX 是不是 DLL 的一種」，感覺上算接近，但在調查情境中建議 把角色分開看。

7. 差異整理成表

詞 身分 實務常見相關字 常見實體
COM 元件模型、binary 契約底層 IUnknown、QueryInterface、CLSID、IID、Apartment .dll、.exe、登錄資訊
ActiveX 以 COM 為基礎的 control 脈絡 容器、嵌入、property、事件 ActiveX control
ActiveX control 實際被放到宿主的可重用元件 表格、日曆、檢視器、設備連線 .ocx、.dll
OCX ActiveX control 常見的副檔名 regsvr32、工具箱、32bit／64bit xxx.ocx
OLE／Automation 嵌入與自動化的機制 Office 整合、屬性頁、automation 各種以 COM 為基礎的功能

用這張表記憶的話就是：

  • COM 是地基
  • ActiveX 是蓋在地基上的元件文化
  • OCX 是現場會撿到的檔案

8. 實際被用在哪裡

因為瀏覽器那段記憶太強，ActiveX／OCX 常被誤認為「古早 Web 技術」。 但它其實被用在更廣的地方：

  • 桌面應用
    • VB6
    • MFC／C++
    • Access 表單
    • Office／VBA 周邊
  • 瀏覽器／公司內部 Web
    • 在 IE 裡內嵌的檢視器
    • 簽章元件
    • 檔案傳輸元件
    • 周邊設備連線元件
  • 現有 .NET 應用
    • 從 WinForms 包裝、沿用既有 ActiveX control
    • 把既有 COM 資產當 UI 元件延命使用

這裡重點是：ActiveX 不是「網路專屬」的技術。 只是它在 IE 上名聲太大，讓人誤以為只是 Web 技術；實際上看成 Windows 的嵌入式元件技術 比較貼近實務。

9. 為什麼容易被混淆

9.1. 三個詞不在同一層，卻一起出現

  • COM 是 底層 的事
  • ActiveX 是 元件脈絡 的事
  • OCX 是 檔案 的事

本來就不是同一層的東西，但實務上常同時冒出來，對話很容易糊成一團。

9.2. ActiveX 一詞用得稍廣

COM 的意義還算固定。 ActiveX 則不論歷史上或實務上，使用範圍都稍微廣一些。

不同人可能在指：

  • control 本身
  • .ocx 檔案
  • 在 IE 上跑的舊元件
  • 一般以 COM 為基礎的嵌入式元件

這時對話就更泥濘。

9.3. 看到 .ocx 就想全部叫 ActiveX

這心情能理解，日常對話通常也沒事。

但在遷移或調查情境下，還是要分開看：

  • 它是 UI 元件嗎
  • 跑在哪個宿主上
  • 需不需要註冊
  • 32bit／64bit 怎麼配
  • 有沒有瀏覽器相依

如果不先分清楚，後面就會實實在在地摔一跤。

10. 在現今實務上該怎麼看

看到 COM／ActiveX／OCX 不必馬上全盤否定；但把它們一視同仁也危險。

瀏覽器側的 ActiveX 相依

這一塊應該先用嚴格一點的角度看：

  • 已不屬於現代瀏覽器開發主流
  • 在相容運維脈絡下 IE 模式會被提出，但它是 為了後向相容的橋，不是新前提
  • 以它為新系統前提並不推薦

也就是說，Web 端的 ActiveX 應該從「怎麼脫離」的角度想，而不是「怎麼延命」。

桌面端的 ActiveX／OCX 相依

這一塊可以務實地判斷：

  • 在既有宿主中穩定運行
  • 發佈對象範圍明確
  • 廠商或自家的維運前景有保障
  • 註冊、相依 DLL、bitness 的前提都搞得清楚

條件齊備的話，繼續使用 完全是合理選項。

反之，若出現：

  • 想在 64bit 行程直接載入 32bit OCX
  • 想只把周邊改成 .NET
  • 每次部署與註冊都翻車
  • 還殘留瀏覽器相依

就該分開考慮 留、包、換 的策略。

所以在今天的實務中，並不是「有 ActiveX 就是錯」，而是 邊界要切在哪裡。 與其把它當古老技術，不如當成 既有系統的接合面 來看，比較好處理。

11. 常見誤解

誤解 1：COM = ActiveX

不是。 COM 是底層，ActiveX 是在其上的 control 脈絡。

誤解 2：ActiveX = Internet Explorer

不是。 它在 IE 上出名是事實，但 ActiveX 並不是瀏覽器專屬。

誤解 3：ActiveX = OCX

實務上幾乎被當同義詞用，但嚴格來說不同。 ActiveX 是脈絡或元件的事，OCX 是實際會看到的副檔名。

誤解 4：OCX 不就是 DLL 嗎

粗略說是接近，但在調查情境下不要這樣粗略。 光看 .dll 看不出角色，但 .ocx 已經很有 control 的味道。

誤解 5：COM 是已經死掉的技術

至少在 Windows 世界這樣說太粗糙。 它在檯面上沒那麼顯眼，但在設計與互通的語境中仍然出現。

12. 調查時的 checklist

看到 COM／ActiveX／OCX，先依下列順序確認會比較好整理：

  1. 這是什麼元件
    • UI control？
    • 檢視器？
    • 設備連線？
    • Office／Access 整合？
  2. 跑在哪裡
    • Access／VBA？
    • VB6／MFC？
    • WinForms？
    • IE／IE 模式？
  3. 檔案與識別碼是什麼
    • .ocx / .dll / .exe
    • ProgID
    • CLSID
    • Type Library
  4. 註冊與部署怎麼做
    • 要不要 regsvr32
    • 有沒有相依 DLL
    • 要不要管理員權限
  5. bitness 對得上嗎
    • 32bit？
    • 64bit？
    • 需要跑在同一行程嗎
  6. 未來打算怎麼處理
    • 就這樣保留
    • 做邊界包起來
    • 直接替換

不先做這些，直接喊「有 ActiveX 所以全面重寫」，多半會整齊踩上舊雷。 沒必要跑去地雷區做足底健康法。

13. 總結

最粗但最實務的講法：

  • COM 是底層
  • ActiveX 是以 COM 為基礎的嵌入式元件脈絡
  • OCX 是 ActiveX control 實作常見的檔案

也就是說：

  • COM 在講機制
  • ActiveX 在講元件
  • OCX 在講檔案

把這 3 件事分清楚，下列就會明顯好判斷：

  • 這只是個 .ocx
  • 還是整個 COM 的問題
  • 是瀏覽器相依的 ActiveX
  • 還是桌面上可以保留的元件

legacy 技術之所以難，不是因為名字老，而是 底層、元件、檔案常常在同一段對話裡出現。 一旦把結構看清楚，問題其實相當可處理。

14. 參考資料

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

ActiveX / OCX 現在如何處理 - 保留・包裝・取代的判斷表

整理在實務專案中遇到 ActiveX 或 OCX 時的判斷流程，從 UI 部件、機器控制、報表、瀏覽器依賴到 32bit 與 64bit 的牆壁，依照保留・包裝・取代三種選項列出對照表與決策流程，並說明註冊發佈與 STA 等容易絆倒的細節，幫讀者選出最低成本的下一步。

閱讀文章

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽