一 、 为什么要用 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 |
看清楚了吗？ 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; |
这就是一个典型的创建 COM 组件的框架，不过我的兴趣在 CoCreateInstance 身上，让我们来看看它内部做了一 些什么事情。以下是它内部实现的一个伪代码 :
| CoCreateInstance(....) |
这段话的意思就是先得到类厂对象，再通过类厂创建组件从而得到 IUnknown 指针。继续深入一步，看看 CoGetClassObject 的内部伪码：
| CoGetClassObject(.....) |
下图是从 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 。
581
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
