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

COM / ActiveX / OCX 這 3 個詞，在 Windows 的舊系統案子裡幾乎都是成套出現。

• 廠商寄來一個 .ocx
• Access 或 VB6 的畫面上放著來路不明的元件
• 剛聽到「這是 COM」，下一句就變成「這是 ActiveX 吧」
• 接著 regsvr32、32bit / 64bit、IE 模式這些詞一起湧上來

走到這一步，對話通常就對不上了。原因是這些術語彼此很接近，歷史上的重疊也很大。 反過來說，只要能把這幾個分開理解，調查、遷移與說明的難度都會差很多。

flowchart TB
    accTitle: 對話對不上的結構
    accDescr: COM、ActiveX、OCX 這些相近的術語在同一個現場一起出現時對話就會對不上，但只要分清楚哪個是底層、哪個是元件、哪個是檔案，調查、遷移與說明都會變得容易的圖。
    mix["3 個詞一起冒出來"] --> lost["對話對不上"]
    split["分成底層、元件、檔案"] --> clear["調查、遷移與說明都變輕鬆"]

圖 1: 這篇文章的目的只有一個：分清楚「哪個是底層、哪個是元件、哪個是檔案」。

本文會依照能看出差異與關係的順序，梳理 什麼是 COM、什麼是 ActiveX、什麼是 OCX。 特別要講清楚的是 哪個是底層、哪個是元件、哪個是檔案。

目錄

1. 先給結論（一句話）
2. 本文所說的 COM / ActiveX / OCX
3. 先用一張圖整理
   • 3.1. 關係圖
   • 3.2. 術語的最短整理
4. 什麼是 COM
   • 4.1. 一句話說明
   • 4.2. COM 裡重要的東西
   • 4.3. 術語的一行筆記
5. 什麼是 ActiveX
   • 5.1. 一句話說明
   • 5.2. ActiveX 不是瀏覽器專用
6. 什麼是 OCX
   • 6.1. 一句話說明
   • 6.2. 和 .dll 有什麼不同
7. 用表格整理差異
8. 過去用在哪些地方
9. 為什麼容易混淆
10. 現在的實務該怎麼看待
11. 常見的誤解
12. 調查時的檢查重點
13. 總結
14. 參考資料

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 18 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

1. 先給結論（一句話）

先給一個粗略但派得上用場的講法。

• COM 是底層。它是 Windows 上元件彼此往來所依據的二進位契約
• ActiveX 是以 COM 為基礎的元件脈絡，尤其常以嵌入宿主使用的控制項形式出現
• OCX 是 ActiveX 控制項常見的實作檔案，以副檔名的形式遇到
• 也就是說，用 COM = 機制、ActiveX = 元件的脈絡、OCX = 檔案 這種程度來理解就會清楚很多
• 「ActiveX = 舊瀏覽器上那個危險的東西」這個印象對了一半，另一半不夠。ActiveX 並不是瀏覽器專用
• 「OCX = ActiveX」在口語裡幾乎被當成同義詞，但嚴格來說是把概念和副檔名混在一起
• 現在不會把它擺在新開發的主位，不過既有的 Windows 應用程式、Office、Access、設備 SDK、公司內部 Web 裡還是會遇到

一開始就從把這 3 件事分開來看著手。

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

只要這裡分得開，迷霧就會散掉不少。

flowchart TB
    accTitle: 一開始要先分開的 3 個問題
    accDescr: 從分辨眼前談的是 COM 這個機制、還是 ActiveX 控制項這個元件、還是只是看到 ocx 檔案就這樣叫開始著手的圖。
    q{"現在談的到底是什麼"}
    q --> a["COM = 機制的話題"]
    q --> b["ActiveX = 元件脈絡的話題"]
    q --> c["OCX = 檔案的話題"]

圖 2: 猶豫的時候就回到這 3 選 1。COM 是機制，ActiveX 是元件的脈絡，OCX 是檔案。

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

這 3 個詞在實務上常常草率地混住在一起。 所以本文先把意義固定下來。

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

稍微補充一下，歷史上 ActiveX 這個詞曾經有一段時期用得更寬。 不過現在實務上講 ActiveX 會出問題的地方，多半集中在 控制項、嵌入、宿主、瀏覽器、註冊 這一帶。

所以本文基本上也把 ActiveX 當成偏向 ActiveX 控制項的話題 來談。

flowchart TB
    accTitle: ActiveX 這個詞的範圍與本文的焦點
    accDescr: 歷史上 ActiveX 這個詞曾經用得更寬，但現在實務上會出問題的是控制項、嵌入、宿主、瀏覽器與註冊一帶，所以本文把焦點鎖定在偏向控制項的話題上的圖。
    word["ActiveX 這個詞"] --> wide["歷史上也有更寬的意思"]
    word --> now["現在會出問題的是控制項周邊"]
    now --> focus["本文以控制項這一側為主"]
    now -.-> items["嵌入、宿主、瀏覽器、註冊"]

圖 3: 承認這個詞在歷史上的寬度，同時把焦點固定在實務上會出問題的「控制項這一側」。

3. 先用一張圖整理

3.1. 關係圖

先用一張圖看整體會比較快。如果所在環境顯示不出圖，圖正下方的條列寫的是同樣的內容，可以直接讀那裡。

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

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

圖 4: 以 COM 為底層，OLE / Automation、ActiveX、OCX 層層疊上去，宿主再載入控制項的關係圖。

這裡重要的是 COM 和 ActiveX 不是同一個詞 這一點。

• COM 是底層
• OLE / Automation 是為了嵌入與自動化而存在的機制
• ActiveX 是在其上被使用的控制項脈絡
• OCX 是那個控制項實作常見的檔案

所以被問到 ActiveX 就是 COM 嗎，答案會是 底層是 COM，但 ActiveX 不是 COM 本身。

3.2. 術語的最短整理

如果要用最短的方式記，這樣就夠了。

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

4. 什麼是 COM

4.1. 一句話說明

COM 是 Component Object Model 的縮寫，是 Windows 上元件彼此往來所依據的 二進位契約。

這裡說的二進位契約，指的不是原始碼的方便性或語言規格，而是 編譯之後的形式仍然守得住約定的介面。 用 C++ 做出來的元件可以從別的語言或別的應用程式使用，靠的就是這份契約。

貼近實務感覺來說，COM 與其說是 一種方便的函式庫散發方式，不如說是 隱藏實作、只用契約來串接的機制。

舉例來說，下面這些就是 COM 的典型（每個詞的意思在 4.3 各用一行整理）。

• 由 IUnknown 提供的參考計數
• 由 QueryInterface 進行的介面探詢
• 以 IID、CLSID 這類 GUID 為基礎的識別
• 透過 DLL 的處理程序內使用
• 透過 EXE 的處理程序外使用

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

flowchart TB
    accTitle: 二進位契約這個想法
    accDescr: COM 不看原始碼或語言規格的方便性，而是用編譯之後仍然守得住的約定也就是二進位契約來串接元件，所以用 C++ 做出來的元件可以從別的語言或別的應用程式使用的圖。
    part["元件〔隱藏實作〕"] --> contract["二進位契約〔對外公開的約定〕"]
    contract --> user["別的語言、別的應用程式"]
    contract -.-> note["編譯之後約定依然守得住"]

圖 5: COM 的核心是「隱藏實作，只用契約來串接」。所以元件才能跨越語言被使用。

4.2. COM 裡重要的東西

只抓基本的話，COM 裡下面這幾點很重要。

• 以介面為中心
  • 先決定要公開什麼，才談實作
• 用 GUID 識別
  • 讓類別與介面能被唯一識別
• 宿主與實作分離
  • 呼叫端不需要知道內部實作
• 可以跨處理程序
  • 不只同一個處理程序，也能當成別的處理程序裡的元件來用

這幾點就是 COM 不會只被當成一個老技術的原因。 從相當早的年代開始，它就穩穩地帶著 以契約為基礎來重複使用的設計。

flowchart TB
    accTitle: COM 裡重要的 4 根支柱
    accDescr: 以介面為中心的設計、用 GUID 做唯一識別、宿主與實作分離、可以跨處理程序這 4 點，讓 COM 成為以契約為基礎的重複使用設計的圖。
    com["COM 的基本"] --> p1["以介面為中心"]
    com --> p2["用 GUID 識別"]
    com --> p3["宿主與實作分離"]
    com --> p4["可以跨處理程序"]

圖 6: 撐起 COM 的 4 根支柱。從很早的年代就帶著以契約為基礎的重複使用設計。

4.3. 術語的一行筆記

談 COM 的時候，下面這些詞會不加說明地飛過來。這裡當成概念的入口，先各用一行抓住就好。想再往設計層面的趣味走的讀者，可以看 什麼是 COM - Windows COM 的設計為何至今依然優美。

本文只做到概念的整理，不深入各項目的細節。等到需要談實作的時候，把這張表裡的詞直接當成搜尋關鍵字，就比較容易先鎖定可疑範圍。

flowchart TB
    accTitle: 以 IUnknown 為底層的基本動作
    accDescr: 身為所有 COM 介面底層的 IUnknown，具備用 QueryInterface 詢問別的介面、用 AddRef 與 Release 增減參考計數、歸零時釋放元件這些基本動作的圖。
    iu["IUnknown〔一切的底層〕"] --> qi["用 QueryInterface 詢問"]
    qi --> got["有的話就傳回指標"]
    iu --> rc["用 AddRef 與 Release 管理數量"]
    rc --> zero["歸零就釋放元件"]

圖 7: 位在術語表中心的 IUnknown 那 3 個方法，分成「詢問」與「計數」兩件工作。

5. 什麼是 ActiveX

5.1. 一句話說明

ActiveX 理解成以 COM 為基礎的 可重複使用軟體元件，尤其是 嵌入宿主或容器裡使用的控制項，會比較好懂。

實務上講 ActiveX，相當高的機率談的是 ActiveX 控制項。 例如按鈕、表格、圖表、日曆、檢視器、設備介接元件這類東西。

與其把 ActiveX 當成 獨自站著、架子很大的龐大技術，不如把它看成 嵌在某個宿主裡工作的元件，比較不容易失準。

flowchart TB
    accTitle: 嵌在宿主裡工作的元件
    accDescr: 實務上講 ActiveX 相當高的機率談的是 ActiveX 控制項，也就是按鈕、表格、圖表、檢視器、設備介接元件這類嵌在宿主或容器裡工作的元件的圖。
    host["宿主 / 容器"] --> ctrl["ActiveX 控制項"]
    ctrl --> ex1["表格或日曆"]
    ctrl --> ex2["檢視器或設備介接元件"]
    ctrl -.-> note["不是獨自站著的龐大技術"]

圖 8: 把 ActiveX 當成「嵌進去才工作的元件」來看，就不容易失準。

5.2. ActiveX 不是瀏覽器專用

ActiveX = Internet Explorer 那個東西 的印象相當強。 這並沒有錯，但 不只是這樣。

列一下 ActiveX 控制項一路被用在哪些地方。

• Access 表單
• VB6（Visual Basic 6.0）應用程式
• MFC（Microsoft Foundation Class 函式庫）的容器
• Office 與 VBA 周邊
• 從 WinForms 使用的 COM 包裝層
• Internet Explorer 以及它的相容運作脈絡

也就是說，ActiveX 是 不限於瀏覽器，在 Windows 應用程式這一側也長期被使用的元件技術。

不理解這一點，就會把公司內部 Web 上找到的 ActiveX，和埋在 Access 畫面裡的 ActiveX 看成兩種東西。 實際上兩者都是相當靠近 COM 的親戚。

flowchart TB
    accTitle: ActiveX 控制項一路被用在哪些地方
    accDescr: Access 表單、VB6 應用程式、MFC 的容器、Office 與 VBA 周邊、從 WinForms 使用的 COM 包裝層以及 Internet Explorer，說明 ActiveX 不是瀏覽器專用而是在 Windows 應用程式這一側也長期被使用的圖。
    ax["ActiveX 控制項"] --> d["Access、VB6、MFC"]
    ax --> o["Office 與 VBA 周邊"]
    ax --> w["WinForms 的 COM 包裝層"]
    ax --> ie["Internet Explorer 系"]
    ie -.-> myth["出名的只有這裡"]

圖 9: 只是在 IE 上比較顯眼，實際用過的地方大半在 Windows 應用程式那一側。

6. 什麼是 OCX

6.1. 一句話說明

OCX 是 實作 ActiveX 控制項時常用的副檔名。 在 Windows 的實務現場看到 .ocx，第一個可以懷疑的就是 嵌入式控制項那一類的 COM 元件。

會冒出來的場合大致是這幾種。

• 廠商 SDK 的散發檔案
• VB6 / Access / MFC 的舊專案
• 安裝程式裡要註冊的檔案
• 需要 regsvr32 的元件

要記住的是 OCX 是檔案的形式，不是概念本身 這一點。 所以要草率地回答 OCX 是什麼，答案就是 常以 ActiveX 控制項實體身分遇到的檔案。

6.2. 和 .dll 有什麼不同

這裡也很容易混淆。

• .ocx 相當強烈地暗示它是 ActiveX 控制項
• .dll 可能是一般的函式庫，可能是 COM 伺服器，也可能是 ActiveX 周邊的相依 DLL

看到 .ocx 幾乎就能先鎖定「偏向 ActiveX 的話題」，但只看到 .dll 還不知道它是什麼身分。

實務上常見的是像這樣排在一起，

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

也就是 主角是 OCX，旁邊由 DLL 支撐 的樣子。

所以被問到 OCX 算不算 DLL 的一種，感覺上是接近的，但在調查的場合 把角色分開來看 比較安全。

flowchart TB
    accTitle: 副檔名能透露的資訊差距
    accDescr: ocx 強烈暗示它是 ActiveX 控制項，dll 則還分不出是一般函式庫、COM 伺服器還是相依 DLL，實務上常見主角 OCX 由旁邊的 DLL 支撐的組合的圖。
    q{"副檔名是什麼"}
    q -->|".ocx"| ax["幾乎可以鎖定在偏 ActiveX 這一側"]
    q -->|".dll"| unk["還不知道是什麼身分"]
    unk --> roles["是函式庫、COM 伺服器還是相依項"]
    ax -.-> pair["主角 OCX 由旁邊的 DLL 支撐的形式"]

圖 10: .ocx 可以先鎖定範圍，.dll 則在查清角色之前不知道是什麼身分。

7. 用表格整理差異

如果要靠這張表來記，先這樣就好。

• COM 是基礎工程
• ActiveX 是疊在其上的元件文化
• OCX 是在現場撿到的檔案

8. 過去用在哪些地方

ActiveX / OCX 因為瀏覽器的記憶太強，很容易被看成 舊時代的 Web 技術。 不過實際上它用得更廣。

具體來說是這些地方。

• 桌面應用程式
  • VB6
  • MFC / C++
  • Access 表單
  • Office 與 VBA 周邊
• 瀏覽器與公司內部 Web
  • 嵌在 Internet Explorer 裡的檢視器
  • 簽章元件
  • 檔案傳輸元件
  • 周邊設備介接元件
• 既有的 .NET 應用程式
  • 從 WinForms 包起來使用的既有 ActiveX 控制項
  • 把既有 COM 資產當成 UI 元件延續使用的情況

繞了一圈，還是回到 ActiveX 不是網際網路專用 這件事。 只是因為在 IE 上太搶眼才看起來像 Web 技術，實際上把它看成 Windows 的嵌入式元件技術，在實務上比較貼切。

flowchart TB
    accTitle: 外界印象與實際情況的落差
    accDescr: 因為在 IE 上太搶眼，ActiveX 很容易被看成舊時代的 Web 技術，但實際上桌面應用程式、公司內部 Web、既有 .NET 應用程式都在用，本質是 Windows 的嵌入式元件技術的圖。
    look["在 IE 上搶眼的記憶"] --> web["看起來像舊時代的 Web 技術"]
    real["實際使用的地方"] --> r1["桌面應用程式"]
    real --> r2["瀏覽器與公司內部 Web"]
    real --> r3["既有的 .NET 應用程式"]
    r1 -.-> truth["實際上是 Windows 的嵌入式元件技術"]

圖 11: 「舊時代的 Web 技術」這種印象，和「Windows 的嵌入式元件技術」這個實際情況之間的落差。

9. 為什麼容易混淆

9.1. 詞彙的層級不同，卻出現在同一段對話裡

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

層級本來就不同，實務上卻在同一個現場同時冒出來，對話自然容易變得一團亂。

9.2. ActiveX 這個詞的範圍稍微寬一點

COM 的意思相對固定。 相對地，ActiveX 不論在歷史上或實務上，用得都稍微寬一點。

不同的人指的可能是，

• 控制項本身
• .ocx 檔案
• 在 IE 上跑的舊元件
• 以 COM 為基礎的嵌入式元件的統稱

到底是哪一個，人跟人之間會錯開。 到這個時候，對話已經對不上了。

9.3. 一看到 .ocx 就想把全部都叫成 ActiveX

這種心情可以理解。 平常這樣講大致上也通。

不過在遷移或調查的場合，

• 它是不是 UI 元件
• 它在哪個宿主上跑
• 需不需要註冊
• 32bit / 64bit 的狀況是什麼
• 有沒有瀏覽器相依性

不分開來看的話，後面一定會出事。

flowchart TB
    accTitle: 造成混淆的 3 個理由
    accDescr: 層級不同的話題出現在同一段對話、ActiveX 這個詞的範圍稍寬、一看到 ocx 就想把全部都這樣叫，這 3 點造成混淆的圖。
    r1["層級不同的話題出現在同一段對話"] --> mixup["對話變得一團亂"]
    r2["ActiveX 這個詞範圍很寬"] --> mixup
    r3["看到 ocx 就全部這樣叫"] --> mixup
    mixup -.-> risk["在遷移與調查的場合會出事"]

圖 12: 混淆的真面目，是底層、元件、檔案這 3 個不同層級同時出現在同一個現場。

10. 現在的實務該怎麼看待

首先，找到 COM / ActiveX / OCX 並不代表要立刻全盤否定。 但是把全部都用同樣的認真程度對待，也很危險。

瀏覽器側的 ActiveX 相依性

這一側優先用比較嚴格的眼光看會比較安全。

• 它不是現代瀏覽器開發的主流
• 在相容運作的脈絡下會談到 IE 模式，但這比較適合看成 為了向下相容而搭的橋
• 不建議把它握成新專案的前提技術

判斷時也需要時間軸。IE11 桌面應用程式已經退役，現在剩下的立足點是 Microsoft Edge 的 IE 模式。關於這個 IE 模式，Microsoft 提出的方針是 至少支援到 2029 年，若要終止則提前 1 年公告。也就是說，2029 年不是「可以放著不管到那時候的期限」，而是 要在那之前拆完的期限，應該從那裡倒推回來安排。拆除的步驟本身另外寫在 擺脫 IE 模式依賴系統的實務指南 裡。

Web 側的 ActiveX 與其想「怎麼延續使用」，不如想「要從哪裡開始拆」，這樣比較實際。

flowchart TB
    accTitle: 瀏覽器側 ActiveX 的時間軸
    accDescr: IE11 桌面應用程式已經退役，剩下的立足點是 Edge 的 IE 模式，Microsoft 提出至少支援到 2029 年並在終止時提前 1 年公告的方針，因此 2029 年不是可以放著不管的期限而是要倒推安排的拆完期限的圖。
    ie11["IE11 桌面版已經退役"] --> iem["剩下的立足點是 Edge 的 IE 模式"]
    iem --> y2029["至少支援到 2029 年"]
    y2029 --> plan["當成拆完的期限倒推安排"]
    y2029 -.-> notice["若要終止會提前 1 年公告的方針"]

圖 13: 2029 年不是寬限，而是截止日。瀏覽器側要用「從哪裡開始拆」來思考。

桌面側的 ActiveX / OCX 相依性

這一側可以判斷得更務實一些。

• 在既有宿主裡穩定運轉
• 散發對象有限
• 廠商維護或自家維護有著落
• 註冊、相依 DLL、位元數的前提都掌握得住

這些條件都齊的話，保留 是很正常的判斷。

另一方面，

• 想把 32bit OCX 直接載進 64bit 那一側
• 只想把周邊改成 .NET
• 每次散發與註冊都出包
• 還留著瀏覽器相依性

這種情況下，把 保留 / 包起來 / 取代 分開考慮比較安全。

現在的實務要問的不是 是不是因為是 ActiveX 所以就是壞的，而是 要把邊界劃在哪裡。 與其看成老技術，不如當成 既有系統的接合面，會比較好處理。

flowchart TB
    accTitle: 桌面側的判斷會怎麼分岔
    accDescr: 穩定運轉、散發範圍有限、維護有著落、前提都掌握這些條件都齊的話保留是很正常的判斷，若有位元數衝突、周邊要改成 .NET、散發出包或瀏覽器相依，就把保留、包起來、取代分開考慮的圖。
    q{"條件是否都齊了"}
    q -->|"穩定運轉且前提都掌握"| keep["保留也是很正常的判斷"]
    q -->|"有卡關的地方"| split["把保留、包起來、取代分開"]
    split -.-> view["當成接合面思考要把邊界劃在哪"]

圖 14: 桌面側要分開認真程度來判斷。要問的不是好壞，而是邊界的位置。

11. 常見的誤解

誤解 1：COM = ActiveX

不對。 COM 是底層，ActiveX 是在其上被使用的控制項脈絡。

誤解 2：ActiveX = Internet Explorer

不對。 它在 IE 上出名確實是事實，但 ActiveX 不是瀏覽器專用。

誤解 3：ActiveX = OCX

實務上這兩個詞用得相當接近，但嚴格來說不一樣。 ActiveX 談的是脈絡或元件，OCX 則是以副檔名形式遇到的實體。

誤解 4：OCX 不就是普通的 DLL 嗎

草率地說是接近的，不過在調查的時候最好別這麼草率。 光看 .dll 讀不出角色，.ocx 則帶著相當偏向控制項的味道。

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

至少在 Windows 的世界裡，這樣講太粗暴了。 它只是從舞台前緣往後退了一點，在設計與互通的脈絡裡現在仍然會出現。

flowchart TB
    accTitle: 常見誤解該怎麼糾正
    accDescr: COM 不是 ActiveX 本身而是底層、ActiveX 不是 IE 專用、ActiveX 與 OCX 是概念與檔案的差別、COM 不是死掉的技術，整理這些誤解該怎麼糾正的圖。
    m1["COM = ActiveX ?"] --> a1["COM 是底層，兩者不同"]
    m2["ActiveX = IE 專用 ?"] --> a2["桌面上仍在服役"]
    m3["ActiveX = OCX ?"] --> a3["概念與檔案的差別"]
    m4["COM 死了 ?"] --> a4["互通的場合現在也會出現"]

圖 15: 這 5 個誤解都來自同一個地方：把層級的差別混在一起。

12. 調查時的檢查重點

找到 COM / ActiveX / OCX 之後，照下面的順序逐一查看，就不容易迷路。

1. 它是什麼元件
   • 是 UI 控制項嗎
   • 是檢視器嗎
   • 是設備介接嗎
   • 是 Office / Access 介接嗎
2. 它在哪裡執行
   • 是 Access / VBA 嗎
   • 是 VB6 / MFC 嗎
   • 是 WinForms 嗎
   • 是 IE / IE 模式嗎
3. 檔案與識別碼是什麼
   • .ocx / .dll / .exe
   • ProgID
   • CLSID
   • Type Library
4. 註冊與散發是怎麼處理的
   • 需不需要 regsvr32
   • 有沒有相依 DLL
   • 需不需要系統管理員權限
5. 位元數是否一致
   • 是 32bit
   • 是 64bit
   • 需不需要在同一個處理程序裡執行
6. 未來要怎麼處理
   • 就這樣保留
   • 劃出邊界包起來
   • 換掉

12.1. 要用什麼工具去查

上面 6 點講的是「看什麼」，所以也把「開哪裡」一併列出來。不知道這些的話，就算有檢查清單，第一步就會卡住。

不看這些就直接喊 因為有 ActiveX，所以全部重新實作 往前衝，會把過去的陷阱漂亮地踩一遍。 先把上面 6 點與工具的對照關係填完，再去決定第 10 章的「保留 / 包起來 / 取代」比較安全。

flowchart TB
    accTitle: 調查的順序
    accDescr: 依序查看是什麼元件、在哪裡執行、檔案與識別碼是什麼、註冊與散發怎麼處理、位元數是否一致，然後再決定保留、包起來還是取代的圖。
    s1["先看是什麼元件"] --> s2["再看在哪裡執行"]
    s2 --> s3["清查檔案與識別碼"]
    s3 --> s4["確認註冊與散發"]
    s4 --> s5["確認位元數"]
    s5 --> s6["決定保留、包起來還是取代"]

圖 16: 不要一開始就衝去重新實作，照這個順序填完再決定方針比較安全。

13. 總結

要用最草率、但在實務上派得上用場的方式講 COM / ActiveX / OCX 的差異，就是這樣。

• COM 是底層
• ActiveX 是以 COM 為基礎的嵌入式元件脈絡
• OCX 是 ActiveX 控制項常見的檔案

只要能把這 3 個分開來想，

• 這只是單純的 .ocx 嗎
• 這是 COM 整體的問題嗎
• 這是瀏覽器相依的 ActiveX 嗎
• 這是在桌面上可以保留的元件嗎

就會變得清楚很多。

舊技術之所以難，不是因為名字老，而是因為 底層、元件、檔案會出現在同一段對話裡 才顯得麻煩。 不過只要看得見結構，它意外地會變成一個處理得動的問題。

14. 參考資料

• 什麼是 COM - Windows COM 的設計為何至今依然優美
• ActiveX / OCX 現在該怎麼處理 - 保留、包裝、取代的判斷表
• 元件物件模型 (COM) - Microsoft Learn
• ActiveX 控制項 - Win32 apps - Microsoft Learn
• ActiveX Controls - MFC - Microsoft Learn
• ActiveX Control - Access VBA - Microsoft Learn
• 什麼是 Internet Explorer (IE) 模式 - Microsoft Learn
• IE 與 Edge 的生命週期 FAQ - Microsoft Learn（至少支撐 IE 模式到 2029 年的方針）
• regsvr32 - Windows 命令 - Microsoft Learn
• CLSID 機碼 - Win32 apps - Microsoft Learn
• 登錄檔重新導向器 - Win32 apps - Microsoft Learn
• 在 Internet Explorer 模式 (IE 模式) 中使用 DevTools - Microsoft Learn

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

整理諮詢這個主題時常見的問題。

OCX 檔案是什麼？

OCX 是實作 ActiveX 控制項時常用的副檔名。在 Windows 的實務現場看到 .ocx，第一個可以懷疑的就是嵌入式控制項那一類的 COM 元件。它常出現在廠商 SDK 的散發檔案、VB6 / Access / MFC 的舊專案、安裝程式裡需要註冊的檔案，以及需要 regsvr32 的元件裡。先記住 OCX 是檔案的形式而不是概念本身，就不容易混淆。

COM 和 ActiveX 有什麼不同？

COM 是 Windows 上元件彼此往來所依據的二進位契約，也就是底層。ActiveX 則是以 COM 為基礎的可重複使用軟體元件，尤其常指嵌入宿主或容器裡使用的控制項這個脈絡。用「COM = 機制、ActiveX = 元件的脈絡、OCX = 檔案」來理解，整體會清楚很多。ActiveX 的底層是 COM，但 ActiveX 並不是 COM 本身。

ActiveX 是 Internet Explorer 專用的技術嗎？

不是。它在 IE 上出名確實是事實，但 ActiveX 控制項也長期用在 Access 表單、VB6 應用程式、MFC 的容器、Office 與 VBA 周邊，以及從 WinForms 透過 COM 包裝層使用等 Windows 應用程式這一側。與其看成瀏覽器專用技術，在實務上把它當成 Windows 的嵌入式元件技術會更貼切。另外，瀏覽器側的 ActiveX 相依性，現在與其想「怎麼延續使用」，不如從「要從哪裡開始拆掉」來思考比較實際。

OCX 和 DLL 有什麼不同？

.ocx 這個副檔名相當強烈地暗示它是 ActiveX 控制項，而 .dll 可能是一般的函式庫，可能是 COM 伺服器，也可能是 ActiveX 周邊的相依 DLL。實務上常見的樣子是 vendorcontrol.ocx 當主角，vendorhelper.dll 之類的 DLL 在旁邊支撐。如果問 OCX 算不算 DLL 的一種，感覺上是接近的，但在調查與遷移的場合，把角色分開來看比較安全。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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