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

一


、

为什么要用


COM


　　软件工程发展到今天，从一开始的结构化编程，到面向对象编程，再到现在的

COM

编
程，目标只有一个，就是希望软件能象积方块一样是累起来的，是组装起来的，而不是一点点编出来的。结构化编程是函数块的形式，通过把一个软件划分成许多模
块，每个模块完成各自不同的功能，尽量做到高内聚低藕合，这已经是一个很好的开始，我们可以把不同的模块分给不同的人去做，然后合到一块，这已经有了组装
的概念了。

软件工程的核心就是要模块化

，最理想的情况就是

100%

内聚

0%

藕
合。整个软件的发展也都是朝着这个方向走的。结构化编程方式只是一个开始。下一步就出现了面向对象编程，它相对于面向功能的结构化方式是一个巨大的进步。
我们知道整个自然界都是由各种各样不同的事物组成的，事物之间存在着复杂的千丝万缕的关系，而正是靠着事物之间的联系、交互作用，我们的世界才是有生命力
的才是活动的。我们可以认为在自然界中事物做为一个概念，它是稳定的不变的，而事物之间的联系是多变的、运动的。事物应该是这个世界的本质所在。面向对象
的着眼点就是事物，就是这种稳定的概念。每个事物都有其固有的属性，都有其固有的行为，这些都是事物本身所固有的东西，而面向对象的方法就是描述出这种稳
定的东西。而面向功能的模块化方法它的着眼点是事物之间的联系，它眼中看不到事物的概念它只注重功能，我们平常在划分模块的时侯有没有想过这个函数与哪些
对象有关呢？很少有人这么想，一个函数它实现一种功能，这个功能必定与某些事物想联系，我们没有去掌握事物本身而只考虑事物之间是怎么相互作用而完成一个
功能的。说白了，这叫本末倒置，也叫急功近利，因为不是我们智慧不够，只是因为我们没有多想一步。面向功能的结构化方法因为它注意的只是事物之间的联系，
而联系是多变的，事物本身可能不会发生大的变化，而联系则是很有可能发生改变的，联系一变，那就是另一个世界了，那就是另一种功能了。如果我们用面向对象
的方法，我们就可以以不变应万变，只要事先把事物用类描述好，我们要改变的只是把这些类联系起来的方法，只是重新使用我们的类库，而面向过程的方法因为它
构造的是一个不稳定的世界，所以一点小小的变化也可能导致整个系统都要改变。然而面向对象方法仍然有问题，问题在于重用的方法。搭积木式的软件构造方法的
基础是有许许多多各种各样的可重用的部件、模块。我们首先想到的是类库，因为我们用面向对象的方法产生的直接结果就是许多的类。但类库的重用是基于源码的
方式，这是它的重大缺陷。首先它限制了编程语言，你的类库总是用一种语言写的吧，那你就不能拿到别的语言里用了。其次你每次都必须重新编译，只有编译了才
能与你自己的代码结合在一起生成可执行文件。在开发时这倒没什么，关键在于开发完成后，你的

EXE

都
已经生成好了，如果这时侯你的类库提供厂商告诉你他们又做好了一个新的类库，功能更强大速度更快，而你为之心动又想把这新版的类库用到你自己的程序中，那
你就必须重新编译、重新调试！这离我们理想的积木式软件构造方法还有一定差距，在我们的设想里希望把一个模块拿出来再换一个新的模块是非常方便的事，可是
现在不但要重新编译，还要冒着很大的风险，因为你可能要重新改变你自己的代码。另一种重用方式很自然地就想到了是

DLL

的方式。

Windows

里到处是

DLL

，它是

Windows

的基础，但

DLL

也有它自己的缺点。总结一下它至少有四点不足。

(1)


函数重名问题。


DLL

里是一个一个的函数，我们通过函数名来调用函数，那如果两个

DLL

里有重名的函数怎么办？

(2)


各编译器对


C


＋＋函数的名称修饰不兼容问题。


对于

C

＋＋函数，编译器要根据函数的参数信息为它生成修饰名，

DLL

库里存的就是这个修饰名，但是不同的编译器产生修饰的方法不一样，所以你在

VC

里编写的

DLL

在

BC

里就可以用不了。不过也可以用

extern "C";

来强调使用标准的

C

函数特性，关闭修饰功能，但这样也丧失了

C

＋＋的重载多态性功能。

(3)


路径问题。


放在自己的目录下面，别人的程序就找不到，放在系统目录下，就可能有重名的问题。而真正的组件应该可以放在任何地方甚至可以不在本机，用户根本不需考虑这个问题。

(4)DLL


与


EXE


的依赖问题。


我们一般都是用隐式连接的方式，就是编程的时侯指明用什么

DLL

，这种方式很简单，它在编译时就把

EXE

与

DLL

绑在一起了。如果

DLL

发行了一个新版本，我们很有必要重新链接一次，因为

DLL

里面函数的地址可能已经发生了改变。

DLL

的缺点就是

COM

的优点。首先我们要先把握住一点，

COM

和

DLL

一样都是基于二进制的代码重用，所以它不存在类库重用时的问题。另一个关键点是，

COM

本身也是

DLL

，既使是

ActiveX

控件

.ocx

它实际上也是

DLL

，所以说

DLL

在还是有重用上有很大的优势，只不过我们通过制订复杂的

COM

协议，通

COM

本身的机制改变了重用的方法，以一种新的方法来利用

DLL

，来克服

DLL

本身所固有的缺陷，从而实现更高一级的重用方法。

COM

没有重名问题，因为根本不是通过函数名来调用函数，而是通过虚函数表，自然也不会有函数名修饰的问题。路径问题也不复存在，因为是通过查注册表来找组件的，放在什么地方都可以，即使在别的机器上也可以。也不用考虑和

EXE

的依赖关系了，它们二者之间是松散的结合在一起，可以轻松的换上组件的一个新版本，而应用程序混然不觉

二、用

VC

进行

COM

编程，必须要掌握哪些

COM

理论知识


　　我见过很多人学
COM
，看完一本书后觉得对
COM
的原理比较了解了，
COM
也不过如此，可是就是不知道该怎么编程序，我自己也有这种情况，我也是经历了这样的阶段走过来的。要学
COM
的基本原理，我推荐的书是《
COM
技术内幕》。但仅看这样的书是远远不够的，我们最终的目的是要学会怎么用
COM
去编程序，而不是拼命的研究
COM
本身的机制。所以我个人觉得对
COM
的基本原理不需要花大量的时间去追根问底，没有必要，是吃力不讨好的事。其实我们只需要掌握几个关键概念就够了。这里我列出了一些我自己认为是用
VC
编程所必需掌握的几个关键概念。
(
这里所说的均是用
C++
语言条件下的
COM
编程方式
)

　

　

(1)


COM
组件实际上是一个
C++
类，而接口都是纯虚类。组件从接口派生而来
。我们可以简单的用纯粹的
C++
的语法形式来描述
COM
是个什么东西：

class IObject 　　 { 　　 public: 　　　　 virtual Function1(...) = 0; 　　　　 virtual Function2(...) = 0; 　　　　 .... 　　 }; 　　 class MyObject : public IObject 　　 { 　　 public: 　　　　 virtual Function1(...){...} 　　　　 virtual Function2(...){...} .... 　　 };

　　看清楚了吗？

IObject

就是我们常说的接口，

MyObject

就是所谓的

COM

组件。

切记切记接口都是纯虚类，它所包含的函数都是纯虚函数，而且它没有成员变量。而

COM

组件就是从这些纯虚类继承下来的派生类，它实现了这些虚函数

，仅此而已。从上面也可以看出，

COM

组件是以

C++

为基础的，特别重要的是虚函数和多态性的概念，

COM

中所有函数都是虚函数，都必须通过虚函数表

VTable

来调用，这一点是无比重要的，必需时刻牢记在心

。为了让大家确切了解一下虚函数表是什么样子，从《

COM

＋技术内幕》中

COPY

了下面这个示例图：

　　

(2)

COM
组件有三个最基本的接口类，分别是
IUnknown
、
IClassFactory
、
IDispatch
。

　　
COM
规范规定任何组件、任何接口都必须从
IUnknown
继承，
IUnknown
包含三个函数，分别是
QueryInterface
、
AddRef
、
Release
。这三个函数是无比重要的，而且
它们的排列顺序也是不可改变的
。
QueryInterface
用于查询组件实现的其它接口，说
白了也就是看看这个组件的父类中还有哪些接口类
，
AddRef
用于增加引用计数，
Release
用于减少引用计数。引用计数也是
COM
中的一个非常重要的概念。大体上简单的说来可以这么理解，
COM
组件是个
DLL
，当客户程序要用它时就要把它装到内存里。另一方面，一个组件也不是只给你一个人用的，可能会有很多个程序同时都要用到它。但实际上
DLL
只装载了一次，即内存中只有一个
COM
组件，那
COM
组件由谁来释放？由客户程序吗？不可能，因为如果你释放了组件，那别人怎么用，所以只能由
COM
组件自己来负责。所以出现了引用计数的概念，
COM
维持一个计数，记录当前有多少人在用它，每多一次调用计数就加一，少一个客户用它就减一，当最后一个客户释放它的时侯，
COM
知道已经没有人用它了，它的使用已经结束了，那它就把它自己给释放了。引用计数是
COM
编程里非常容易出错的一个地方，但所幸
VC
的各种各样的类库里已经基本上把
AddRef
的调用给隐含了，在我的印象里，我编程的时侯还从来没有调用过
AddRef
，我们只需在适当的时侯调用
Release
。至少有两个时侯要记住调用
Release
，第一个是调用了
QueryInterface
以后，第二个是调用了任何得到一个接口的指针的函数以后，记住多查
MSDN
以确定某个函数内部是否调用了
AddRef
，如果是的话那调用
Release
的责任就要归你了。
IUnknown
的这三个函数的实现非常规范但也非常烦琐，容易出错，所幸的事我们可能永远也不需要自己来实现它们。

　　
IClassFactory
的作用是创建
COM
组件。我们已经知道
COM
组件实际上就是一个类，那我们平常是怎么实例化一个类对象的？是用
‘new’
命令
!
很简单吧，
COM
组件也一样如此。但是谁来
new
它呢？不可能是客户程序，因为客户程序不可能知道组件的类名字，如果客户知道组件的类名字那组件的可重用性就要打个大大的折扣了，事实上客户程序只不过知道一个代表着组件的
128
位的数字串而已，这个等会再介绍。所以客户无法自己创建组件，而且考虑一下，如果组件是在远程的机器上，你还能
new
出一个对象吗？所以创建组件的责任交给了一个单独的对象，这个对象就是类厂。
每个组件都必须有一个与之相关的类厂
，这个类厂知道怎么样创建组件，当客户请求一个组件对象的实例时，实际上这个请求交给了类厂，由类厂创建组件实例，然后把实例指针交给客户程序。这个过程在跨进程及远程创建组件时特别有用，因为这时就不是一个简单的
new
操作就可以的了，它必须要经过调度，而这些复杂的操作都交给类厂对象去做了。
IClassFactory
最重要的一个函数就是
CreateInstance
，顾名思议就是创建组件实例，一般情况下我们不会直接调用它，
API
函数都为我们封装好它了，只有某些特殊情况下才会由我们自己来调用它，这也是
VC
编写
COM
组件的好处，使我们有了更多的控制机会，而
VB
给我们这样的机会则是太少太少了。

　　
IDispatch
叫做调度接口
。它的作用何在呢？这个世上除了
C++
还有很多别的语言，比如
VB
、
VJ
、
VBScript
、
JavaScript
等等。可以这么说，如果这世上没有这么多乱七八糟的语言，那就不会有
IDispatch
。
:-)
我们知道
COM
组件是
C++
类，是靠虚函数表来调用函数的，对于
VC
来说毫无问题，这本来就是针对
C++
而设计的，以前
VB
不行，现在
VB
也可以用指针了，也可以通过
VTable
来调用函数了，
VJ
也可以，但还是有些语言不行，那就是脚本语言，典型的如
VBScript
、
JavaScript
。不行的原因在于它们并不支持指针，连指针都不能用还怎么用多态性啊，还怎么调这些虚函数啊。唉，没办法，也不能置这些脚本语言于不顾吧，现在网页上用的都是这些脚本语言，而分布式应用也是
COM
组件的一个主要市场，它不得不被这些脚本语言所调用，既然虚函数表的方式行不通，我们只能另寻他法了。时势造英雄，
IDispatch
应运而生。
:-)
调度接口把每一个函数每一个属性都编上号，客户程序要调用这些函数属性的时侯就把这些编号传给
IDispatch
接口就行了，
IDispatch
再根据这些编号调用相应的函数，仅此而已。
当然实际的过程远比这复杂，仅给一个编号就能让别人知道怎么调用一个函数那不是天方夜潭吗，你总得让别人知道你要调用的函数要带什么参数，参数类型什么以及返回什么东西吧，而要以一种统一的方式来处理这些问题是件很头疼的事。
IDispatch
接口的主要函数是
Invoke
，客户程序都调用它，然后
Invoke
再调用相应的函数，如果看一看
MS
的类库里实现
Invoke
的代码就会惊叹它实现的复杂了，因为你必须考虑各种参数类型的情况，所幸我们不需要自己来做这件事，而且可能永远也没这样的机会。
:-)

　　
(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(); 　　　　 ........... 　　　　 }

　　下图是从

COM+

技术内幕中

COPY

来的一个例图，从图中可以清楚的看到

CoCreateInstance

的整个流程。

　　

(7)

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

　　
DllGetClassObject:
用于获得类厂指针

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

　　
DllUnregisterServer:
卸载注册信息

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

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

　　
(8)


注册表在
COM
中的重要作用

　　首先要知道
GUID
的概念，
COM
中所有的类、接口、类型库都用
GUID
来唯一标识，
GUID
是一个
128
位的字串
，根据特制算法生成的
GUID
可以保证是全世界唯一的。
COM

组件的创建，查询接口都是通过注册表进行的。有了注册表，应用程序就不需要知道组件的
DLL
文件名、位置，只需要根据
CLSID
查就可以了。当版本升级的时侯，只要改一下注册表信息就可以神不知鬼不觉的转到新版本的
DLL
。