用VC进行COM编程所必须掌握的理论知识

　　(3) dispinterface接口、Dual接口以及Custom接口

　　这一小节放在这里似乎不太合适，因为这是在ATL编程时用到的术语。我在这里主要是想谈一下自动化接口的好处及缺点，用这三个术语来解释可能会更好一些，而且以后迟早会遇上它们，我将以一种通俗的方式来解释它们，可能并非那么精确，就好象用伪代码来描述算法一样。-:)

　　所谓的自动化接口就是用IDispatch实现的接口。我们已经讲解过IDispatch的作用了，它的好处就是脚本语言象VBScript、 JavaScript也能用COM组件了，从而基本上做到了与语言无关它的缺点主要有两个，第一个就是速度慢效率低。这是显而易见的，通过虚函数表一下子就可以调用函数了，而通过Invoke则等于中间转了道手续，尤其是需要把函数参数转换成一种规范的格式才去调用函数，耽误了很多时间。所以一般若非是迫不得已我们都想用VTable的方式调用函数以获得高效率。第二个缺点就是只能使用规定好的所谓的自动化数据类型。如果不用IDispatch我们可以想用什么数据类型就用什么类型，VC会自动给我们生成相应的调度代码。而用自动化接口就不行了，因为Invoke的实现代码是VC事先写好的，而它不能事先预料到我们要用到的所有类型，它只能根据一些常用的数据类型来写它的处理代码，而且它也要考虑不同语言之间的数据类型转换问题。所以VC自动化接口生成的调度代码只适用于它所规定好的那些数据类型，当然这些数据类型已经足够丰富了，但不能满足自定义数据结构的要求。你也可以自己写调度代码来处理你的自定义数据结构，但这并不是一件容易的事。考虑到IDispatch的种种缺点(它还有一个缺点，就是使用麻烦，:-) )现在一般都推荐写双接口组件，称为dual接口，实际上就是从IDispatch继承的接口。我们知道任何接口都必须从 IUnknown继承，IDispatch接口也不例外。那从IDispatch继承的接口实际上就等于有两个基类，一个是IUnknown，一个是IDispatch，所以它可以以两种方式来调用组件，可以通过 IUnknown用虚函数表的方式调用接口方法，也可以通过IDispatch::Invoke自动化调度来调用。这就有了很大的灵活性，这个组件既可以用于C++的环境也可以用于脚本语言中，同时满足了各方面的需要。

　　相对比的，dispinterface是一种纯粹的自动化接口，可以简单的就把它看作是IDispatch接口 (虽然它实际上不是的)，这种接口就只能通过自动化的方式来调用，COM组件的事件一般都用的是这种形式的接口。

　　Custom接口就是从IUnknown接口派生的类，显然它就只能用虚函数表的方式来调用接口了

　　(4) COM组件有三种，进程内、本地、远程。对于后两者情况必须调度接口指针及函数参数。

　　COM是一个DLL，它有三种运行模式。它可以是进程内的，即和调用者在同一个进程内，也可以和调用者在同一个机器上但在不同的进程内，还可以根本就和调用者在两台机器上。这里有一个根本点需要牢记，就是COM组件它只是一个DLL，它自己是运行不起来的，必须有一个进程象父亲般照顾它才行，即COM组件必须在一个进程内.那谁充当看护人的责任呢？先说说调度的问题。调度是个复杂的问题，以我的知识还讲不清楚这个问题，我只是一般性的谈谈几个最基本的概念。我们知道对于WIN32程序，每个进程都拥有4GB的虚拟地址空间，每个进程都有其各自的编址，同一个数据块在不同的进程里的编址很可能就是不一样的，所以存在着进程间的地址转换问题。这就是调度问题。对于本地和远程进程来说，DLL 和客户程序在不同的编址空间，所以要传递接口指针到客户程序必须要经过调度。Windows 已经提供了现成的调度函数，就不需要我们自己来做这个复杂的事情了。对远程组件来说函数的参数传递是另外一种调度。DCOM是以RPC为基础的，要在网络间传递数据必须遵守标准的网上数据传输协议，数据传递前要先打包，传递到目的地后要解包，这个过程就是调度，这个过程很复杂，不过Windows已经把一切都给我们做好了，一般情况下我们不需要自己来编写调度DLL。

　　我们刚说过一个COM组件必须在一个进程内。对于本地模式的组件一般是以EXE的形式出现，所以它本身就已经是一个进程。对于远程DLL，我们必须找一个进程，这个进程必须包含了调度代码以实现基本的调度。这个进程就是dllhost.exe。这是COM默认的DLL代理。实际上在分布式应用中，我们应该用MTS来作为DLL代理，因为MTS有着很强大的功能，是专门的用于管理分布式DLL组件的工具。

　　调度离我们很近又似乎很远，我们编程时很少关注到它，这也是COM的一个优点之一，既平台无关性，无论你是远程的、本地的还是进程内的，编程是一样的，一切细节都由COM自己处理好了，所以我们也不用深究这个问题，只要有个概念就可以了，当然如果你对调度有自己特殊的要求就需要深入了解调度的整个过程了，这里推荐一本《COM+技术内幕》，这绝对是一本讲调度的好书。

　　(5) COM组件的核心是IDL。

　　我们希望软件是一块块拼装出来的，但不可能是没有规定的胡乱拼接，总是要遵守一定的标准，各个模块之间如何才能亲密无间的合作，必须要事先共同制订好它们之间交互的规范，这个规范就是接口。我们知道接口实际上都是纯虚类，它里面定义好了很多的纯虚函数，等着某个组件去实现它，这个接口就是两个完全不相关的模块能够组合在一起的关键试想一下如果我们是一个应用软件厂商，我们的软件中需要用到某个模块，我们没有时间自己开发，所以我们想到市场上找一找看有没有这样的模块，我们怎么去找呢？也许我们需要的这个模块在业界已经有了标准，已经有人制订好了标准的接口，有很多组件工具厂商已经在自己的组件中实现了这个接口，那我们寻找的目标就是这些已经实现了接口的组件，我们不关心组件从哪来，它有什么其它的功能，我们只关心它是否很好的实现了我们制订好的接口。这种接口可能是业界的标准，也可能只是你和几个厂商之间内部制订的协议，但总之它是一个标准，是你的软件和别人的模块能够组合在一起的基础，是COM组件通信的标准。

　　COM具有语言无关性，它可以用任何语言编写，也可以在任何语言平台上被调用。但至今为止我们一直是以C++的环境中谈COM，那它的语言无关性是怎么体现出来的呢？或者换句话说，我们怎样才能以语言无关的方式来定义接口呢？前面我们是直接用纯虚类的方式定义的，但显然是不行的，除了C++谁还认它呢？正是出于这种考虑，微软决定采用IDL来定义接口。说白了，IDL实际上就是一种大家都认识的语言，用它来定义接口，不论放到哪个语言平台上都认识它。我们可以想象一下理想的标准的组件模式，我们总是从IDL开始，先用IDL制订好各个接口，然后把实现接口的任务分配不同的人，有的人可能善长用VC，有的人可能善长用VB，这没关系，作为项目负责人我不关心这些，我只关心你把最终的DLL 拿给我。这是一种多么好的开发模式，可以用任何语言来开发，也可以用任何语言来欣赏你的开发成果。

　　(6) COM组件的运行机制，即COM是怎么跑起来的。

　　这部分我们将构造一个创建COM组件的最小框架结构，然后看一看其内部处理流程是怎样的

　　　　IUnknown *pUnk=NULL;
　　　　IObject *pObject=NULL;
　　　　CoInitialize(NULL);
　　　　CoCreateInstance(CLSID_Object, CLSCTX_INPROC_SERVER, NULL, IID_IUnknown, (void**)&pUnk);
　　　　pUnk->QueryInterface(IID_IOjbect, (void**)&pObject);
　　　　pUnk->Release();
　　　　pObject->Func();
　　　　pObject->Release();
　　　　CoUninitialize();

　　这就是一个典型的创建COM组件的框架，不过我的兴趣在CoCreateInstance身上，让我们来看看它内部做了一些什么事情。以下是它内部实现的一个伪代码:

　　　　CoCreateInstance(....)
　　　　{
　　　　.......
　　　　IClassFactory *pClassFactory=NULL;
　　　　CoGetClassObject(CLSID_Object, CLSCTX_INPROC_SERVER, NULL, IID_IClassFactory, (void **)&pClassFactory);
　　　　pClassFactory->CreateInstance(NULL, IID_IUnknown, (void**)&pUnk);
　　　　pClassFactory->Release();
　　　　........
　　　}

　　这段话的意思就是先得到类厂对象，再通过类厂创建组件从而得到IUnknown指针。继续深入一步，看看CoGetClassObject的内部伪码：

　　　CoGetClassObject(.....)
　　　{
　　　　//通过查注册表CLSID_Object，得知组件DLL的位置、文件名
　　　　//装入DLL库
　　　　//使用函数GetProcAddress(...)得到DLL库中函数DllGetClassObject的函数指针。
　　　　//调用DllGetClassObject
　　　}
　　　　DllGetClassObject是干什么的，它是用来获得类厂对象的。只有先得到类厂才能去创建组件.
　　　　下面是DllGetClassObject的伪码：
　　　　DllGetClassObject(...)
　　　　{
　　　　......
　　　　CFactory* pFactory= new CFactory; //类厂对象
　　　　pFactory->QueryInterface(IID_IClassFactory, (void**)&pClassFactory);
　　　　//查询IClassFactory指针
　　　　pFactory->Release();
　　　　......
　　　　}
　　　　CoGetClassObject的流程已经到此为止，现在返回CoCreateInstance，看看CreateInstance的伪码：
　　　　CFactory::CreateInstance(.....)
　　　　{
　　　　...........
　　　　CObject *pObject = new CObject; //组件对象
　　　　pObject->QueryInterface(IID_IUnknown, (void**)&pUnk);
　　　　pObject->Release();
　　　　...........
　　　　}

　　(7) 一个典型的自注册的COM DLL所必有的四个函数

　　DllGetClassObject:用于获得类厂指针

　　DllRegisterServer:注册一些必要的信息到注册表中

　　DllUnregisterServer:卸载注册信息

　　DllCanUnloadNow:系统空闲时会调用这个函数，以确定是否可以卸载DLL

　　DLL还有一个函数是DllMain,这个函数在COM中并不要求一定要实现它，但是在VC生成的组件中自动都包含了它，它的作用主要是得到一个全局的实例对象。

　　(8) 注册表在COM中的重要作用

　　首先要知道GUID的概念，COM中所有的类、接口、类型库都用GUID来唯一标识，GUID是一个128位的字串，根据特制算法生成的GUID可以保证是全世界唯一的。 COM组件的创建，查询接口都是通过注册表进行的。有了注册表，应用程序就不需要知道组件的DLL文件名、位置，只需要根据CLSID查就可以了。当版本升级的时侯，只要改一下注册表信息就可以神不知鬼不觉的转到新版本的DLL。

　　本文是本人一时兴起的涂鸭之作，讲得并不是很全面，还有很多有用的体会没写出来，以后如果有时间有兴趣再写出来。希望这篇文章能给大家带来一点用处，那我一晚上的辛苦就没有白费了。-:)

查看本文来源