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分享到：

转载于:https://www.cnblogs.com/xiaopengblog/p/3139968.html