COM、OLE、ActiveX的的確確是一路貨色！！！雖然說的有些武斷，但我只是將人們對COM、OLE、ActiveX最廣泛的理解表達出來，三者之間還是很大區別的，具體淵源後面講。

一、元件（Component）和物件（Object）之間的區別。

網上找的：元件是一個可重用的模組，它是由一組處理過程、資料封裝和使用者介面組成的業務物件 （Rules Object）。元件看起來像物件，但不符合物件的學術定義。它們的主要區別是：

1）元件可以在另一個稱為容器（有時也稱為承載者或宿主）的應用程式中使用，也可以作為獨立過程使用；

2）元件可以由一個類構成，也可以由多個類組成，或者是一個完整的應用程式；

3）元件為模組重用，而物件為程式碼重用。

以我自己理解，兩者最大的區別就是第三點，前兩個區別只能說是抽象的層次不一樣，都是過程和資料的封裝而已。或者換個說法更清楚：元件是編譯好的程式的重用，物件是沒編譯的程式碼的重用！！呵呵，不知道這麼說對不對，但是最起碼好理解吧。

二、淵源

純粹的資料交換（剪下板）有很多弊端，比如需要解析格式，無法同步資料等等，於是OLE出現了，物件的連結與嵌入（Object Linking and Embedded，OLE）的誕生把原來應用程式的資料交換提高到“物件交換”，這樣程式間不但獲得資料也同樣獲得彼此的應用程式物件，並且可以直接使用彼此的資料內容，其實OLE以前就是Microsoft的複合文件技術，它的最初版本只是瞄準複合文件。以我個人理解，OLE所謂的封裝就是告訴呼叫者：我有哪些資料、什麼程式可以操作這些資料。而其他程式只要使用OLE技術，就可以方便的獲取資料，或者呼叫相應的程式操作資料。但是早期的OLE有自己的弊端，業界一直在抱怨它的緩慢和龐大，於是COM應運而生。

COM（Component Object Module，物件元件模型）的基本出發點是，讓某個軟體通過一個通用的機構為另一個軟體提供服務。COM是應OLE的需求而誕生的，它的第一個使用者卻是OLE2（新版OLE），所以雖然COM是OLE的基礎，但OLE的產生卻在COM之前。採用了COM技術的OLE，除了技術上可以讓物件模型完全獨立於程式語言之外，我自己認為最關鍵的一點就是：Microsoft藉此“染指”通用平臺技術。網上一句話說的很好：“可以將COM看作是某種（軟體）打包技術”，其實COM就是如此工作的，通過COM就可以訪問程式提供的功能，訪問程式管理的資料。COM雖然起源於 複合文件，但卻可有效地適用於許多軟體問題，它畢竟是處在底層的基礎技術。用一句話來說，COM是獨立於語言的元件體系結構，可以讓元件間相互通訊。

COM並不是產品，它需要一個商標名稱。而那時Microsoft的市場專家們已經選用了OLE作為商標名稱，所以使用COM技術的都開始貼上了 OLE的標籤。雖然這些技術中的絕大多數與複合文件沒有關係。Microsoft 的這一做法讓人產生這樣一個誤解OLE是僅指複合文件呢？還是不單單指複合文件？其實OLE是COM的商標名稱，自然不僅僅指複合文件。而隨著 Internet的發展，在1996年春，Microsoft改變了主意，選擇ActiveX作為新的商標名稱。ActiveX是指寬鬆定義的、基於COM的技術集合，而OLE仍然僅指複合文件。當然，ActiveX最核心的技術還是COM。ActiveX和 OLE的最大不同在於，OLE針對的是桌面上應用軟體和檔案之間的整合，而ActiveX則以提供進一步的網路應用與使用者互動為主。

可以這麼理解，COM是個技術名詞，是基礎，OLE和ActiveX則是商標品牌，可以看做是基於COM技術開發的一種技術標準，且ActiveX是OLE的升級。

儘管 ActiveX 和 OLE 都基於COM，但它們為程式設計師提供的卻是截然不同的服務。COM提供的是低階的物件捆綁機制，該機制支援物件之間的互動通訊。OLE使用COM來提供低階的應用服務，例如採用連線和嵌入機制，支援使用者建立複合文件。與之不同，ActiveX提供更精細的結構，用以支援在網路站點上嵌入控制元件，以及對事 件的互動反應。優化ActiveX，目的是為了提高時間和空間效率，而優化OLE，是為了便於終端使用者的使用和整合臺式系統的應用程式。

到這裡，大家應該對ActiveX、OLE和COM三者的關係有了一個比較明確的認識，COM才是最根本的核心技術，所以下面的重點COM。讓物件模型完全獨立於程式語言，這是一個非常新奇的思想。這一點從C++和Java的物件概念上，我們就能有所瞭解。但所謂COM物件究竟是什麼呢？為了便於理解，可以把COM看作是某種（軟體）打包技術，即把它看作是軟體的不同部分，按照一定的面向物件的形式，組合成可以互動的過程和以組支援庫。COM物件可以用C++、Java和VB等任意一種語言編寫，並可以用DLL或作為不同過程工作的執行檔案的形式來實現。使用COM物件的瀏覽器，無需關心物件是用什麼語言寫的，也無須關心它是以DLL還是以另外的過程來執行的。從瀏覽器端看，無任何區別。這樣一個通用的處理技巧非常有用。例如，由使用者協調執行的兩個應用，可以將它們的共同作業部分作為COM物件間的互動來實現（當然，現在的OLE複合文件也能做到）。為在瀏覽器中執行從Web伺服器下載的程式碼，瀏覽器可把它看作是COM物件，也就是說，COM技術也是一種打包可下載程式碼的標準方法（ActiveX控制元件就是執行這種功能的）。甚至連應用與本機OS進行互動的方法也可以用COM來指定，例如在Windows和Windows NT中用的是新API，多數是作為COM物件來定義的。可見，COM雖然起源於複合文件，但卻可有效地適用於許多軟體問題，它畢竟是處在底層的基礎技術。用一句話來說，COM是獨立於語言的元件體系結構，可以讓元件間相互通訊。隨著計算機網路的發展，COM進一步發展為分散式元件物件模型，這就是DCOM，它類似於CORBA的ORB，本文對此將不再做進一步的闡述。通過上面的講述相信大家一定對ActiveX、OLE和COM/DCOM的關係有了一個清楚的瞭解。

三、字尾名

ActiveX，OLE是基於COM的一種應用，其檔案字尾一般以dll和ocx結尾；ocx作為一種特殊的dll檔案，是有互動介面的視覺化控制元件，定義了控制元件的屬性和方法，定義控制元件可引發的事件的響應，我們通常說的.DLL為字尾名的檔案是一個包含方法和資料的模組集合。副檔名為 .ocx的檔案型別也是 DLL，儘管副檔名已改變。COM一般字尾名也是dll。

////////////////////////////////////////////////////////////////////////////////////

從體系結構角度講，OLE和ActiveX都是建立在COM技術之上的，而.NET框架發展自COM技術，一定程度上汲取了COM的優點，並克服了其主要缺點。

從時間的角度講，在這四者中，首先出現的其實是OLE技術，然後是COM技術，然後是ActiveX，最後是.NET。

OLE技術的萌芽

作為COM技術前身的OLE，其最初含義是指在程式之間連結和嵌入物件資料（Object Linking and Embedding）。它提供了建立混合文件的手段（資深Windows3.X使用者可能記得當初在Word6.0中插入一個圖形的新奇和喜悅，有關複合文件，後面文章詳細講述），使得那些沒有太多專業知識的使用者能夠很容易地協調多個應用程式完成混合文件的建立。

1991年制定的OLE1.0規範主要解決多個應用程式之間的通訊和訊息傳遞問題，微軟希望第三方開發商能夠遵守這個規範，以使在當時的Windows平臺上的應用程式能夠相互協調工作，更大的提高工作效率。然而事與願違，只有很少的軟體開發商支援它。

為什麼會這樣呢？原因要從頭說起，最初的OLE1.0的實現基於一種叫做動態資料交換（Dynamic DataExchange，DDE）的通訊協議，理論上說，它可以讓應用程式之間自動獲取彼此的最新資料。但是DDE非常之慢，並且編寫出能工作的DDE程式碼是一件相當困難的工作，另外DDE也並不太健壯和靈活[1]。

總之，OLE技術急需要一套更好的框架才能繼續發展，這也就促成了後來COM技術的誕生

成也OLE 敗也OLE

微軟於1993年釋出了新的規範——OLE2.0，它在原有的基礎上完善並增強了以下各方面的效能：

1．OLE自動化：一個程式有計劃地控制另一個程式的能力。

2．OLE控制元件：小型的元件程式，可嵌入到另外的程式，提供自己的專有功能。

3．OLE文件：完善了早期的混合文件功能，不僅支援簡單鏈接和嵌入，還支援在位啟用、拖放等功能。

強大的功能使得很多的開發商開始支援新的OLE技術，微軟在OLE2.0中使用了一個稱為COM（Component ObjectModel，即元件物件模式）的新規範做為基礎。COM相比DDE來說更小，更快，也更加強壯和靈活。

正是這樣，同早期使用DDE的功能薄弱的OLE1.0相比，OLE2.0得到了更多軟體廠商的支援。許多程式設計人員編寫了大量的實現OLE自動化伺服器功能的元件（不一定是EXE檔案），這些元件一般不求功能齊全、強大，而是實現專門的功能，可以被其它程式程式設計控制，由此承襲OLE的名字稱為OLE控制元件。

微軟也籍此贏得了廣大軟體廠商的支援，使OLE技術深入人心。然而由於早期的OLE1.0的糟糕體驗，人們對OLE技術形成了很多成見，導致後來的人們總把在Word中插入圖形當作OLE技術的全部，各類資料在介紹新OLE技術時命名也不統一，造成很大的混亂。

這些都阻礙著OLE的推廣，也使得COM技術的巨大潛力無法施展。

OLE 96——ActiveX框架

1996年，微軟重新制訂了一個關於OLE的規範——OLE96規範。這個規範擴充套件了 OLE控制元件的能力，並貫徹微軟的Internet戰略使它更易於在網路環境中使用。

這一次微軟做足了打算，為了打消人們心中對OLE技術的狹隘成見，打消命名上的混亂，重新給OLE控制元件貼上另一個標籤——ActiveX控制元件。不僅如此，以前的什麼OLE文件也相應稱為ActiveX文件了。總之，為了滿足Internet戰略，微軟把OLE換成了ActiveX，企圖使人們重新看待新的OLE——ActiveX，把它看做網路上的解決軟體元件問題的標準。許多在Windows上同微軟合作得很好的廠商在開發新版本軟體時都開始支援ActiveX技術，例如Delphi、PowerBuild等開發工具。原來同Windows競爭的作業系統也開始支援ActiveX，例如Macintosh，甚至老對手OS/2上也可以使用ActiveX控制元件。

可見，直到1996年，OLE從以往的基於DDE的複合文件技術，化腐朽為神奇般地變成了基於COM的ActiveX技術。此時ActiveX，既是所有以COM為核心的技術總稱。

COM時代的到來

如之前所說，是複合文件技術的需求造就了COM。但正如長距離輸電的需求衍生出了交流電，而交流電的優點並不只是長距離輸電一樣，COM作為一種底層的規範，它的潛力遠不止複合文件技術。他能夠讓不同的程序彼此通訊，呼叫並建立彼此物件的例項，甚至修改它們，一個COM元件（ActiveX控制元件）可由不同語言的開發工具開發以及呼叫，包括C++和VisualBasic或PowerBuilder，甚至一些技術性語言如VBScript。這為大型軟體的開發提供了極大的便利。

如下圖，普通DLL，只有部分語言可以呼叫，很多指令碼語言都無法呼叫，並且提供的是面向過程的介面，介面引數型別不統一，比如有一些結構體作引數、指標作引數甚至C++類物件作引數的函式，在其它沒有指標的語言中呼叫起來很麻煩甚至無法呼叫。

而以COM組建的形式寫出來的DLL可以給幾乎任何語言呼叫，包括指令碼語言，並且提供面向物件的介面，並且介面引數型別一般都是統一的。

弊端漸顯

儘管COM技術如此強大，但它仍有著難以克服的缺陷。一方面，編寫COM元件的技術門檻過高，必須對記憶體模型有深入的理解。另一方面，COM的介面組織形式決定了它的相容性問題，一個介面釋出之後便不能再修改，加一個函式也不行，甚至方法與屬性的順序在釋出之後不能變。這為大型軟體的開發帶來了巨大的壓力。

.NET的到來

2002年微軟釋出了新的.NET框架，這個框架致力於幫助開發者更好的進行敏捷軟體開發、快速應用開發、平臺無關性和網路透明化的軟體開發平臺，它由COM發展而來，汲取了COM的優點，但又完全脫離COM技術的制約，是一套包含了底層執行庫和頂層開發技術的完全獨立的框架。它與COM最本質的區別在於COM元件是非託管物件，這意味著它可以不需要任何環境而直接執行。而.NET元件是託管物件，必須有.NET框架環境才能執行。

原文：

https://blog.csdn.net/just0kk/article/details/50783291