COM對象是建立在二進制可執行代碼級的基礎上，而C++等語言中的對象是建立在源代碼級基礎上的，因此COM對象是語言無關的。這壹特性使用不同編程語言開發的組件對象進行交互成為可能。
在Microsoft Windows系統平臺上，COM技術被應用於系統的各個層次，從底層的COM對象管理到上層的應用程序交互都用到了COM標準。
概述
COM既提出了組件之間進行交互的規範，也提供了實現交互的環境， 因為組件對象之間交互的規範不依賴於任何特定的語言，所以COM也可以是不同語言協作開發的壹種標準。
OLE技術以COM規範為基礎，OLE充分發揮了COM標準的優勢，使Windows操作系統上的應用程序具有極強的可交互性。如果沒有OLE的支持，Windows操作系統則會遜色很多。
但是，COM規範並不局限於OLE技術，實際上，OLE技術只是COM的壹個應用而已，這幾年，OLE技術在進行網絡互連是顯示出了很大的局限性，而COM則表現出了極強的適應能力。
COM標準包括規範和實現兩大部分，規範部分定義了組件和組件之間通信的機制，這些規範不依賴於任何特定的語言和操作系統，只要按照該規範，任何語言都可以使用; COM標準的實現部分是COM庫，COM庫為COM規範的具體實現提供了壹些核心服務。
COM是面對對象的軟件模型，因而對象是他的基本要素之壹。類似於C++中對象的概念，對象是某個類(class)的壹個實例;而類則是壹組相關的數據和功能組和在壹起的壹個定義。使用對象的應用(或另壹個對象)成為客戶，有時也成為對象的用戶。
接口是壹組邏輯上相關的函數集合，其函數也被稱為接口成員函數。對象通過接口成員函數為客戶提供各種形式的服務。
在COM模型中，對象本身對於客戶來說是不可見的，客戶請求服務時，只能通過接口進行。每壹個接口都由壹個128位的全局唯壹標識符(GUID,Globally Unique Identifier)來標識。客戶通過GUID獲得接口的指針，在通過接口指針，客戶就可以調用其相應的成員函數。
壹般來說，接口是不變的，只要客戶期望的接口在組建對象中還存在，它就可以繼續使用該接口所提供的服務。對象可以支持多個接口，因此對組件對象的升級可通過增加接口的辦法實現，這樣得到的新接口可以不影響老接口的使用。
客戶如何來標識COM對象呢？與接口類似，每個對象也用壹個128位GUID來標識，稱為CLSID(class identifier,類標識符或類ID)，用CLSID標識對象可以保證(概率意義上)在全球範圍內的唯壹性。
只要系統中含有這類COM對象的信息，並包括COM對象所在的模塊文件(DLL或EXE文件)以及COM對象在代碼中的入口點，客戶程序就可以由此CLSID來創建COM對象。
那麽客戶怎麽使用COM對象所提供的服務呢？客戶獲得的又是什麽呢？
實際上，客戶成功創建對象後，它得到的是壹個指向對象某個接口的指針，因為COM對象至少實現壹個接口，所以客戶就可以調用該接口提供的所有服務。
但是COM對象可以有自己的狀態，正是這種狀態才使客戶感覺到COM對象的存在。如果客戶同時擁有兩個相同CLSID的對象，則兩個對象可以有不同的狀態，客戶完全不必關心COM對象是怎麽實現的，以及兩個對象的狀態數據之間有什麽關系(數組或者鏈表)。當然，COM對象也可以是無狀態的，這種COM對象以提供功能服務為主，可以用來代替傳統的API函數接口，使得應用程序編程接口更為有序，組織層次性更強。
COM本身除了規範之外，也有實現的部分，其中包括壹些核心的系統級代碼，也正是這部分核心代碼，才使得對象和客戶之間可通過接口在二進制代碼級進行交互 。
在Microsoft Windows操作系統環境下，這些庫以.dll文件的形勢存在，其中包括以下內容:
(1) 提供了少量的API函數實現客戶和服務端COM應用的創建過程。在客戶端，主要是壹些創建函數;而在服務器端，提供壹些對象的訪問支持。
(2) COM通過註冊表查找本地服務器即EXE程序，以及程序名與CLSID的轉換等。
(3) 提供了壹些標準的內存控制方法，使應用控制進程中內存的分配。
COM庫壹般不在應用程序層實現，而在操作系統層次上實現，因此壹個操作系統只有壹個COM庫實現。而且COM庫的實現必須依賴於具體的系統平臺，尤其是系統底層的壹些標準。
COM庫可以保證所有的組件按照統壹的方式進行交互操作，而且它使我們在編寫COM應用時，可以不用編寫為進行COM通信而必需的大量基礎代碼，而是直接利用COM庫提供的API進行編程，從而大大加快了開發的速度。例如，現在COM庫的版本都支持遠程組件即分布式COM，我們不用編寫任何網絡或者RPC(remote procedure call)的代碼，就可以實現在網絡上進行程序之間的通信。
如果我們用面向對象語言來實現COM對象，則很自然可以用類類定義對象。在C語言中，對象的概念可能變成壹個邏輯概念，如果兩個對象同時存在，則在接口實現中必須明確知道所進行的操作是針對哪個對象的，這個過程可由COM接口的定義保證。
COM規範使用GUID來標識COM對象的思想源於OSF(Open Software Foundation)采用的UUID(Universallz Unique Identifier), UUID被定義為DCE(Distributed Computing Environment)的壹部分，主要用於表識RPC通信的雙方。
除了封裝性和重用性，C++對象還有壹個重要特性是多態性。正是C++對象的多態性，才體現了C++語言用類描述事物的高度抽象的特征;COM對象也 具有多態性，但這種多態性需要通過COM對象所具有的接口才能體現出來，就像C++對象的多態性需要通過其(virtual)函數才能體現壹樣。
從API到COM接口
假如我們要實現壹個字處理應用系統，它需要壹個查字典的功能，按照組件化程序設計的方法，自然應該把查字典的功能放到壹個組件(.dll)程序中實現。如果以後字典程序的查找算法或者字典庫改變了，只要應用程序和組件之間的接口不變，則新的組件程序仍然可以被應用系統使用。這就是采用組件程序帶來的靈活性。
為了把應用系統和組件程序連接起來，又能使它們協同工作，最簡單的做法就是先定義壹組查字典的函數，而且這組函數盡可能壹般化，不要加入特定的與字典庫相關的知識。
函數
功能說明
Initialize
初始化
LoadLibrary
裝入字典庫
InsertWord
插入壹個單詞
DeleteWord
刪除壹個單詞
LookupWord
查找單詞
RestoreLibrary
把內存中的字典庫存入指定的文件中
FreeLibrary
釋放字典庫
平面型的API接口層可以很好地把兩個程序連接起來，但存在以下壹些問題：
(1) 當API函數非常多時，使用會非常不方便，需要對函數進行組織。
(2) API函數需要標準化，按照統壹的調用方式進行處理，以適應不同的語言編程實現。參數的傳遞順序，參數類型，寒暑返回處理都需要標準化。
COM定義了壹套完整的接口規範，不僅可以彌補以上API作為組件借口的不足，還充分發揮了組件對象的優勢，並實現了組件對象的多態性。
接口定義和標識
從技術上講，接口是包含了壹組函數的數據結構，通過這組數據結構，客戶代碼可以調用組件對象的功能。接口定義了壹組成員函數，這組成員函數是組件對象暴露出來的所有信息，客戶程序利用這些函數或的組件對象的服務。
客戶程序用壹個指向接口數據機構的指針來調用接口成員函數。接口指針實際上又指向另壹個指針，這第二個指針指向壹組函數，稱為接口函數表(虛函數表)，接口函數表中每壹項為4個字節長的函數指針，每個函數指針與對象的具體實現連接起來。通過這種方式，客戶只要獲得了接口指針，就可以調用到對象的實際功能。
對於壹個接口來說，他的虛函數表vtable是確定的，因此接口的成員函數個數是不變的，而且成員函數的先後順序也是不變的;對於每個成員函數來說，其參數和返回值也是確定的。
在壹個接口的定義中，所有這些信息都必須在二進制壹級確定，不管什麽語言，只要能支持這樣的內存結構描述，也就是能夠支持“structure“或“record“類型，並且這種類型能夠包含雙重的指向函數指針表的成員，則它就可以支持接口的描述，從而可以用於編寫COM組件或者使用COM組件。
接口描述語言IDL
COM規範在采用OSF的DCE規範描述遠程調用接口IDL的基礎上，進行擴展形成了COM接口的描述語言。
COM規範使用的IDL接口描述語言不僅可用於定義COM接口，同時還定義了壹些常用的數據類型，也可以描述自定義的數據結構，對於接口成員函數，我們可以指定每個參數的類型，輸入輸出特性，甚至支持可變長度的數組的描述。IDL支持指針類型，與C/C++很類似。
Microsoft Visual C++提供了MIDL工具，可以把IDL接口描述文件編譯成C/C++兼容的接口描述頭文件(.h)。
IUnknown的定義(IDL):
interface IUnknown
{
HRESULT QueryInterface([in] REFIID iid, [out] void **ppv);
ULONG AddRef(void);
ULONG Release(void);
}
IUnknown的定義(C++):
class IUnknown
{
Public:
virtual HRESULT _stdcall QueryInterface([in] REFIID iid, [out] void **ppv)=0;
virtual ULONG _stdcall AddRef(void)=0;
virtual ULONG _stdcall Release(void)=0;
}
進程內組件
因為進程內組件和客戶程序運行在同壹個進程地址空間中，所以壹旦客戶程序與組件程序建立起通信關系之後，客戶程序得到的接口指針指向組件程序中接口的vtable，這個vtable包含了所有成員函數地址，客戶代碼可以直接調用這些成員函數，所以其效率非常高。
因為DLL程序是在運行時刻被客戶裝入到內存中的，所以DLL模塊本身也是獨立的，它並不依賴於客戶程序。
在C++語言中，為了使編制的DLL程序更為通用，壹般指定DLL的引出函數使用_stdcall調用習慣，如果使用了_cdecl調用習慣，則有些編程語言環境就不能使用這些DLL程序。C++編譯器為DLL程序的每個引出函數生成了壹個修飾名，這些修飾名對於不同的編譯器並不兼容，因此，從通用性角度出發，我們在每個函數定義前加上extern ?C“ 說明符。在Visual C++ 開發環境中，下面的說明語句可以很好的說明壹個引出函數：
extern ? C“ int _stdcall MyFunction(int n);
為了編制DLL程序，我們可以按照這樣的步驟：
(1) 創建壹個DLL工程
(2) 對每個引出函數，使用extern ? C“說明符，以及_stdcall修飾符，如上面對MyFunction函數的說明。
(3) 按照傳統的編程方法，我們還應該編寫壹個DEF文件，用來描述DLL程序的模塊信息。在Win32平臺上，我們可以不使用DEF文件，而是直接在函數說明時使用_declspec(dllexport)說明符，例如：
extern ? C“_declspec(dllexport) int _stdcall MyFunction(int n);
按照這樣的方法建立起來的DLL模塊可以被其他程序調用，因為C++連接器會把所有引出函數的信息連接到最終的目標代碼中。
從客戶程序壹方來看，有三個系統函數可用於操作DLL程序，LoadLibrary, GetProcAddress, 和FreeLibrary。
壹般地，對於DLL程序的使用過程按照這樣的步驟進行：
首先，客戶程序使用LoadLibrary函數裝入DLL，該函數返回模塊的實例句柄，供以後操作該模塊使用。
然後，客戶程序可以調用GetProcAddress函數獲得DLL中引出的函數的地址，我們既可以按函數的序號(在DEF文件中指定)也可以按函數的名字來獲取引出函數的地址，因為客戶程序和DLL程序在相同的內存地址空間中，所以客戶程序可以直接調用這些引出函數。
最後FreeLibrary，把DLL程序卸出內存，以便釋放資源。
說明：
(1) DLL程序不僅可以引出函數，也可以引出全局變量，因為客戶程序和DLL程序在同壹個地址空間，所以，把DLL中的全局變量引出到客戶程序中是有意義的。引用的方法並不復雜，或者把變量名放到DEF文件的EXPORTS部分，並加上DATA選項; 或者在變量說明前面加上_declspec(dllexport)說明符。
(2) DumpBin 通過/Exports選項可以列出DLL程序中的所有被引出的信息。
(3) 客戶程序本身也可以是壹個DLL程序，但它壹定先被裝入到進程空間中，以便可以調用系統函數操作作為服務程序的DLL模塊。
進程外組件
因為進程外組件程序和客戶程序位於不同的進程空間之中，他們使用不同的地址空間，所以組件和客戶之間的通信必須跨越進程邊界，這就涉及到以下壹些問題：
(1) 壹個進程如何調用另外壹個進程中的函數
(2) 參數如何從壹個進程被傳遞到另外壹個進程中
Windows平臺上，在不同進程之間進行通信的辦法很多，包括DDE, named pipe,或者***享內存等等，COM采用了LPC(Local Procedure Call)和RPC(Remote Procedure Call)
RegEdit可檢查CLSID子鍵下的COM對象(63頁)
Microsoft Visual C++提供OleView.exe，可列出當前機器上的所有類別信息，以及每壹種類別下的組件對象列表。
RegSvr32 D:\DicComp\DictComp.dll
RegSvr32 /u D:\DicComp\DictComp.dll
DLL組件必須有DllRegisterServer和DllUnregisterServer兩個用於註冊的入口函數，才能用RegSvr32註冊。
COM規定，支持自註冊的進程外組件必須支持兩個命令行參數/RegServer和/UnregServer，以便完成註冊或註銷操作。
Class Factory
實際上，客戶程序並不直接調用組件程序的引出函數，它調用COM庫的函數進行組件對象的創建工作，COM庫的創建函數根據註冊表的信息調用組件程序的入口函數來創建組件對象。組件程序需要提供壹個標準的入口函數DLLGetObjectClass，用於提供本組程序的組件信息。
Class Factory和DLLGetObjectClass函數
類廠是COM對象的生產基地，COM庫通過類廠創建COM對象; 對應每壹個COM類，有壹個類廠專門用於該COM類的對象創操作。類廠本身也是壹個COM對象，它支持壹個特殊的接口：IClassFactory，其定義如下：
Class IClassFactory : public IUnknown
{
virtual HRESULT _stdcall CreateInstance(IUnknown *pUnknownOuter, const IID& iid, void **ppv) = 0;
virtual HRESULT _stdcall LockServer(BOOL bLock) = 0;
};
接口IClassFactory有壹個重要的成員函數CreateInstance，用於創建對應的COM對象。因為每個類廠之針對特定的COM類對象，所以CreateInstance成員函數知道該創建什麽樣的COM對象。在CreateInstance成員函數的參數中，第壹個參數pUnknownOuter用於對象被聚合的情形，沒有聚合設成NULL。IClassFactory的另壹個成員函數LockServer用於控制組建的生存周期。
因為類廠本身也是個COM對象，它被用於其它COM對象的創建過程，那麽類廠對象又由誰來創建呢？答案是DLLGetClassObject引出函數。DLLGetClassObject函數並不是COM庫的函數，而是由組件程序實現的引出函數，我們先看壹下DLLGetClassObject函數的原型：
HRESULT DLLGetClassObject(const CLSID& clsid,
Const IID& iid,
(void **) ppv
);
COM庫在接到對象創建的指令後，它要調進程內組件的DLLGetClassObject函數，由該函數創類廠對象，並返回類廠對象的接口指針，COM庫或者客戶壹旦有了類廠的接口指針，它們就可以通過類廠接口IClassFactory的成員函數CreateInstance創建相應的COM對象。
COM庫與類廠的交互（67頁）
在COM庫中，有三個API函數可用於對象的創建，它們分別是CoGetClassObject, CoCreateInstance和CoCreateInstanceEx。通常情況下，客戶程序調用其中之壹完成對象的創建，並返回對象的初始接口指針。COM庫與類廠也通過這三個函數進行交互。
將COM組件看成是DLL這種想法是十分膚淺的！
DLL是COM組件的壹種發布形式，是壹個組件服務器。
組件應看成是DLL中所實現的接口集！
DLL是壹種形式，COM組件才是實質。
參考資料：