COM、DLL、ActiveX、OLE，CLR之间的区别

COM的最核心的思想，说白了就是要做个跨语言的 “class” “object” “function” 。

因为所有OOP语言，这三个都是核心，如果能做到这三个语言要素就可以跨语言，所有语言不都是可以互通了，程序员可以很用自己喜欢的语言编程了，这是目的。

COM是OO技术的巅峰之作，COM之后的OO都是COM的子集而已
COM的意图在于标准化OO组件的界面，使得

跨平台
跨语言
跨机器
跨进程
的分布式对象服务可以标准化，而且服务方可以被动态替换。COM的本质是一个分布式OO-RPC规范

COM的实现，为了跨语言，该怎么做呢？

1）肯定需要有种中立的，对语言里的类型系统的抽象，这就是type library，大家对别的语言的类型，不是直接去理解的，而是通过公共的类型来互相翻译。

2）类型必须要要有名字，我才能知道你说的是什么。而类型的名字没法跨语言，首先有些语言，比如c++，编译之后，根本不存类型的名字，其次这么多语言要求名字不重复，简直没法编程了，所以这就有了 class id，他是UUID，也就是说一个计算出来的名字，就像网卡mac一样，绝B不可能重复，你可以看看注册表里有很多“CLASSID”，就是这么来的。

3）我们真的那么需要类型跨语言吗？回想一下我们对class的使用，绝大多数时候，我们是不会访问成员的，而是通过function来访问类成员，所以我们的首要工作是研究怎么跨语言调用别的语言的function。特别是我们不会简单的调用一个function，我们会把功能相关的function组织起来，成为”一堆"，这一堆function我们叫他interface，到这里，我们想到了，我们不会直接把class裸露的暴露给别的语言，我们只是暴露给别的语言以interface，当然函数调用的时候，参数也有类型，所以类型的跨语言也是必须的。

什么叫COM组件，说白了，就是一堆功能相关的interface，他是某种语言像另种语言暴露功能的最大单位。

4）COM组件并不需要名字，或者说不需要UUID，因为我们总是使用他里面的接口，而不是直接使用COM组件，所以接口也要UUID。说了这么多，COM架构这么复杂，肯定需要一个中间层，或者说摆渡人，这就是COM Library（一堆dll） + 注册表。A应用通知COM Library，并输入接口的UUID,由COM Library装入B应用的该组件对应的dll，并把接口指针返回给A应用，指针里指示的是一堆函数指针，由这些指针，可以调用到B应用里的函数功能。

熟悉面向对象编程和网络编程的人一定对ActiveX、OLE和 COM/DCOM这些概念不会陌生，但是它们之间究竟是什么样的关系，对许多人还是比较模糊的。在具体介绍它们的关系之间，我们还是先明确组件（Component）和对象（Object）之间的区别。组件是一个可重用的模块，它是由一组处理过程、数据封装和用户接口组成的业务对象（Rules Object）。组件看起来像对象，但不符合对象的学术定义。它们的主要区别是：

1）组件可以在另一个称为容器（有时也称为承载者或宿主）的应用程序中使用，也可以作为独立过程使用；
2）组件可以由一个类构成，也可以由多个类组成，或者是一个完整的应用程序；
3）组件为模块重用，而对象为代码重用。

现在，比较流行的组件模型有COM（Component ObjectModule，对象组件模型）/DCOM（ Distributed COM，分布式对象组件模型）和CORBA（Common Object Request BrokerArchitecture，公共对象请求代理体系结构）。

从组件 与对象的区别说起，是想让大家明确COM和CORBA是处在整个体系结构的最底层，如果暂时对此还不能理解，不妨继续往下看，最后在回过头看一看就自然明白了。现在开始阐述ActiveX、OLE 和COM的关系。首先，让大家有一个总体的概念，从时间的角度讲，OLE是最早出现的，然后是COM和ActiveX；从体系结构角度讲，OLE和 ActiveX是建立在 COM之上的，所以COM是基础；单从名称角度讲，OLE、ActiveX是两个商标名称，而COM则是一个纯技术名词，这也是大家更多的听说 ActiveX和OLE的原因。既然OLE是最早出现的，那么就从OLE说起，自从Windows操作系统流行以来，“剪贴板”（ Clipboard）首先解决了不同程序间的通信问题（由剪贴板作为数据交换中心，进行复制、粘贴的操作），但是剪贴板传递的都是“死”数据，应用程序开发者得自行编写、解析数据格式的代码，于是动态数据交换（Dynamic Data Exchange，DDE）的通信协定应运而生，它可以让应用程序之间自动获取彼此的最新数据，但是，解决彼此之间的“数据格式”转换仍然是程序员沉重的负担。对象的链接与嵌入（Object Linking and Embedded，OLE）的诞生把原来应用程序的数据交换提高到“对象交换”，这样程序间不但获得数据也同样获得彼此的应用程序对象，并且可以直接使用彼此的数据内容，其实OLE是Microsoft的复合文档技术，它的最初版本只是瞄准复合文档，但在后续版本OLE2中，导入了COM。由此可见，COM是应OLE的需求而诞生的，所以虽然COM是OLE的基础，但OLE的产生却在COM之前。COM的基本出发点是，让某个软件通过一个通用的机构为另一个软件提供服务。COM是应OLE 的需求而诞生，但它的第一个使用者却是OLE2，所以COM与复合文档间并没有多大的关系，实际上，后来COM就作为与复合文档完全无关的技术，开始被广泛应用。这样一来， Microsoft就开始“染指”通用平台技术。但是COM并不是产品，它需要一个商标名称。而那时Microsoft的市场专家们已经选用了OLE作为 商标名称，所以使用COM技术的都开始贴上了OLE的标签。虽然这些技术中的绝大多数与复合文档没有关系。Microsoft的这一做法让人产生这样一个误解OLE是仅指复合文档呢？还是不单单指复 合文档？其实OLE是COM的商标名称，自然不仅仅指复合文档。但Microsoft自己恐怕无法解释清楚，这要花费相当的精力和时间。 于是，随着Internet的发展，在1996年春，Microsoft改变了主意，选择ActiveX作为新的商标名称。ActiveX是指宽松定义 的、基于COM的技术集合，而OLE仍然仅指复合文档。当然， ActiveX最核心的技术还是COM。ActiveX和OLE的最大不同在于，OLE针对的是桌面上应用软件和文件之间的集成，而ActiveX则以提 供进一步的网络应用与用户交互为主。到这里，大家应该对ActiveX、OLE和COM三者的关系有了一个比较明确的认识，COM才是最根本的核心技术， 所以下面的重点COM。让对象模型完全独立于编程语言，这是一个非常新奇的思想。这一点从C++和Java的对象概念上，我们就能有所了解。但所谓COM 对象究竟是什么呢？为了便于理解，可以把COM看作是某种（软件）打包技术，即把它看作是软件的不同部分，按照一定的面向对象的形式，组合成可以交互的过程和以组支持库。COM对象可以用C++、Java和VB等任意一种语言编写，并可以用DLL或作为不同过程工作的执行文件的形式来实现。使用COM对象 的浏览器，无需关心对象是用什么语言写的，也无须关心它是以DLL还是以另外的过程来执行的。从浏览器端看，无任何区别。这样一个通用的处理技巧非常有用。例如，由用户协调运行的两个应用，可以将它们的共同作业部分作为COM对象间的交互来实现（当然，现在的OLE复合文档也能做到）。为在浏览器中执行 从Web服务器下载的代码，浏览器可把它看作是COM对象，也就是说，COM技术也是一种打包可下载代码的标准方法（ActiveX控件就是执行这种功能的）。甚至连应用与本机OS进行交互的方法也可以用COM来指定，例如在Windows和Windows NT中用的是新API，多数是作为COM对象来定义的。可见，COM虽然起源于复合文档，但却可有效地适用于许多软件问题，它毕竟是处在底层的基础技术。 用一句话来说，COM是独立于语言的组件体系结构，可以让组件间相互通信。随着计算机网络的发展，COM进一步发展为分布式组件对象模型，这就是 DCOM，它类似于CORBA的ORB，本文对此将不再做进一步的阐述。通过上面的讲述相信大家一定对ActiveX、OLE和COM/DCOM的关系有 了一个清楚的了解。

使用Windows的人对于ActiveX控制一定不会陌生，它提供了一种类似于DLL动态链接库的调用，不过它与DLL的唯一区别就是ActiveX不注册不能被系统识别并使用。那么，当我们得到一个ActiveX没有被正确安装且不能使用的消息后，又要安装ActiveX怎么办呢？１. Regsvr32程序法在Windows的System文件夹下有一个regsvr32.exe的程序，它就是Windows自己带的ActiveX注册 和反注册工具。利用它也能够非常方便地注册ActiveX控件，它的用法为：regsvr32/ｕ/ｓ/ｎ/ｉDLLNAME，其中DLLNAME为ActiveX控件文件名，建议在安装前拷贝到System文件夹下参数有如下意义：/ｕ － 反注册控件 /ｓ － 不管注册成功与否，均不显示提示框/ｃ － 控制台输出/ｉ－ 跳过控件的选项进行安装 （与注册不同） /ｎ － 不注册控件，此选项必须与/ｉ 选项一起使用例如笔者要注册amovie.ocx控件，则打入 regsvr32 amovie.ocx即可，要反注册它时只需使用regsvr32 /ｕ amovie.ocx就行了。２.注册表法所谓注册ActiveX，无非是将一些信息记录在Windows的注册表中，如SchockWave Flash Object控件，我们可以运行Regedit.exe注册表编辑程序，利用关键字进行搜索，然后把搜索得到后的注册表导出为一ＲＥＧ注册表文件，再将其相应的ActiveX文件拷贝到Windows的System文件夹（一般ActiveX的文件名为OCX，安装在Windows的System文件夹 内）下，最后在要安装ActiveX的机器上双击导入刚才导出的注册表文件即可完成安装。

ActiveX、OLE和COM都是微软的一些技术标准。Ole比较老后来发展成ActiveX，再后来发展成为COM OCX，DLL是扩展名。ActiveX有两种扩展名OCX和DLL。实际上你可以把它们的扩展名字调换。 COM作为ActiveX的更新技术，扩展名也有可能是DLL文件还有可能是动态链接库。主要是装载一些函数，可以动态加载。COM的前景以后一种比较理想的应用程序模式就是ＷEB化（条件是网络速度足够快），未来的软件应该不存在客户应用软件的说法了，客户就只有浏览器，浏览器就是操作系统，客户一边下载一边使用，当然下载的都是一个个功能独立的模块。而这些功能独立的模块就是com组件，一般的DLL是不能这么用的。
    
    
    COM组件和DLL的区别

com英文为Component Object Model（组件对象模型），是微软生产软件组件的标准。
它是构造二进制兼容软件组件的规范，不管组件应用何种语言编写只要遵循com规范就可以相互直接通信。提出com规范主要是为了满足：
1.程序的快速开发，可以将一个大型的工程分成若干个com组件同时开发。
2.可以动态的插入或卸载com组件。
3.可以隐藏或封装com组件内部的实现细节。
com组件可以由不同的语言进行编写，但com组件之间的通信是通过组件的接口来实现的，com组件接口的实现是统一的，它采用的是虚拟函数表（VTBL）形式。虚拟函数表中包含了组件函数的一组指针，我们可以通过这组指针来获取我们想要通信的组件函数的内存地址。dll（动态链接库）是包含函数和数据的模块的集合。它可以导出数据也可以导出函数以供其它的dll调用。dll的加载可以通过静态链接和动态链接两种方式。
1.静态链接时将所要链接的dll模块以二进制的形式编译进其他模块。
2.动态链接指调用模块在运行时加载DLL，使用LoadLibrary函数或LoadLibraryEx函数将dll加载到进程的地址空间，并调用GetProcAddress函数以获取导出的 DLL函数的地址。
动态加载dll的优点：
1.DLL可节省内存并减少交换。通过在内存中共享 DLL的单个副本，多个进程可以同时使用一个DLL。相比之下，对于使用静态链接库构建的每一个应用程序，Windows 都要在内存中为其加载库代码的一个副本。
2.DLL 可节省磁盘空间。 多个应用程序可以共享磁盘上的一个 DLL副本。相比之下，使用静态 链接库构建的每一个应用程序都需要让链接到程序文件映像的库代码作为一个单独的专用副本。
dll与com的关系：com是一种规范，按照是com规范实现的dll可以被视为com组件，
例如我们用mfc建立的Active X控件工程其中的接口封装是靠idl描述的所以可以视为com组件。而且从上面关于com和dll的说明可以看出com组件的接口是一组具有特定规范的函数，所以com组件可以别视为dll但dll不一定是com组件。
com和DLL最大的区别就是: dll是以函数集合的方式来调用的是编程语言相关的象VC必须加上extern “C”…而COM是以interface的方式提供给用户使用的是一种二进制的调用规范,是与编程语言无关的,它使用idl接口定义语言来描述自己使用类继承来实现自己的功能和方法.DLL只有DLL一种形势,里面可任意定义函数无限制,只能运行在本机上而COM有DLL和EXE两种存在形势: COM所在的DLL中必须导出四个函数:dllgetobjectclass,dllregisterserver, dllunregisterserver,dllunloadnow这四个函数各有作用,有些是提供给COM管理器用的,通过CLSID和IID来使用,有些是提供给注册机用的.COM结合MTS,就是COM+, 是DCOM的高级版本,提供了更为强大和安全的分布式COM服务,DCOM运行在不同的机器上 用proxy和stub来实现远程接口的本地映射 二者从执行速度来说 二者相差无几 但是启动速度DLL要比COM快！
我想你应该知道类库和框架（最典型的就是MFC）的概念，它们是提供源代码级复用的，也就是说类库是以源代码的形式分发的，类库的使用者（比如使用MFC开发应用程序的我们）要把实现代码加入到他们的工程中去，然后编译链接，这时候类库中的源代码就成为了你的应用程序中的一部分，将来如果要是类库的设计者重新修改了他们的类库，那么你的应用程序就需要重新编译链接你的应用程序，这对于已经到了最终用户手中的你的应用程序的升级很麻烦，而且一个最终用户的机子上有可能有很多个程序使用了同一个类库当中的相同类的话就会出现一些多余的代码！   
          这就需要提供一种机制来解决上面的问题，把你的可重用的代码做成一个Dll的形式包装起来是一个可行的方法，在这个Dll中导出一些你需要提供给第三方使用的类、全局函数、数据等，这样你就可以在最终用户的机器上保持一份你的Dll,其它应用程序通过调用你Dll中的引出函数就可以实现代码共享，这样如果你以后升级了你的Dll（保持接口不变），最终用户只要得到这个新的Dll覆盖掉原先的那个旧Dll不用更改任何东西就可以使他机子上的程序保持最新了，而且由于代码只有一份，在运行时使用的空间也比使用类库开发的程序来得少。   
          但是上面这种使用Dll的方案还是有缺陷的，由于每个编译器都会加入它自己的一些独特的语言特征。比如Dll我是使用Visual   C++开发的，里面有异常处理的代码，现在我在Borland   C++中使用这个Dll，那么它将无法捕捉到这些异常；再举个例子，如果这个Dll导出了一个类，而这个类在新的Dll中增加了一些成员变量（也就是说这个类的对象占用的内存增加了），那么在最终用户机子上的原先使用旧的Dll而改用了新的Dll的应用程序如果没有重新编译链接的话会产生非法操作，因为C++的编译模型要求应用程序在编译的时候就需要知道对象占用的空间，原先使用了旧的Dll的应用程序由于没有经过重新编译链接，它所认得的还是原先Dll中的类的对象的大小，最终用户机子换成了新的Dll后，那个旧的应用程序当访问这些新的成员变量的时候就会产生越界非法操作。其实Dll还有其它许多缺陷的！   
          根据这些，我们需要更好的重用机制（在二进制级别的），在Windows下，大量用到的非COM所属了。其基本的思想就是它实现了真正的接口与代码实现的分离，而且它是与语言无关的。COM分为进程内组件（编译链接成Dll或者Ocx文件,本质上一样，一个无界面另一个有界面）和进程外组件（编译链接成Exe文件），这些组件会提供一些接口供第三方调用。其它有关COM的知识如果要讲起来的话那可是长篇累牍，可以看看相关的书籍。
 
这阵子在想一个需要利用com组件的小程序怎么做，突然想起上次去面试的时候考官问过autocad开发时为什么要利用com，而不采用一般的dll呢？     到google上查了一下，许多人也问了一样的问题：）     用com来写程序要比普通的dll麻烦一些，但是带来的好处也大很多，尤其是在开发像autocad这样大型软件的时候，需要跨区域来协同工作。 “学习COM，首先要知道COM的目的是什么，它解决了一个什么样的问题，在此基础上，MS提供了各式各样的可扩展的COM服务，COM编程接口。这些服务和接口恐怕一个程序员一辈子都不可能通晓，因为发展是如此之快。大家也没有必要通晓这些接口，就象对待大量的WIN   API的态度，用到时再查帮助。   
 COM的各种努力都是在规定了一种二进制交互的协议。说起来简单，做起来相当复杂，要使使用不同语言编写的客户能够使用任意语言编写的服务程序谈何容易！这里说语言还是把问题简单化了，因为每种语言还有各式各样的编译器，不同编译器出来的二进制代码如何交互？   
  就拿DLL来说，DLL是对静态连接的一种改进，带来了更细的开发分工，也带来了很多问题，其中就有二进制如何交互的问题。这个问题当DLL输出类时更加突出。COM为解决此问题提出了极负创意的解决方案，不仅如此，更进一步引申，提出了如何跨 网络的交互。然后，针对internet服务器的开发提出COM+。COM体系中融合了多种经典的设计模式，可以说是一种更加精干的C++。   
    
 COM博大精深，若干大师仍须半年的mental   fog,   方能有豁然开朗之时。我们这些晚辈，还需多加修炼才对，但决不止是COM“   
1、COM组件以接口对功能分类，便于组织；DLL特别是大的DLL，函数一大堆，难以组织；
2、COM组件便于升级维护，功能扩充，只需添加接口就行；DLL升级困难，函数不能随意改变；
3、COM创建调用有很好的安全性，DLL没有；
4、COM组件可轻松实现进程间调用，DLL很困难；
5、COM组件可轻松实现分布式调用，DLL不可能；
6、COM组件具有封装、继承、多态的面向对象特征，DLL只有封装；
7、在COM组件的基础上实现了大量功能：ActiveX，OLE等；

COM主要是一套给C/C++用的接口，当然为了微软的野心，它也被推广到了VB、Delphi以及其他一大堆奇奇怪怪的平台上。它主要为了使用dll发布基于interface的接口。我们知道dll的接口是为了C设计的，它导出的基本都是C的函数，从原理上来说，将dll加载到内存之后，会告诉你一组函数的地址，你自己call进去就可以调用相应的函数。
      但是对于C++来说这个事情就头疼了，现在假设你有一个类，我们知道使用一个类的第一步是创建这个类：new MyClass()。这里直接就出问题了，new方法通过编译器计算MyClass的大小来分配相应的内存空间，但是如果库升级了，相应的类可能会增加新的成员，大小就变了，那么使用旧的定义分配出来的空间就不能在新的库当中使用。
      要解决这问题，我们必须在dll当中导出一个CreateObject的方法，用来代替构造函数，然后返回一个接口。然而，接口的定义在不同版本当中也是有可能会变化的，为了兼容以前的版本同时也提供新功能，还需要让这个对象可以返回不同版本的接口。接口其实是一个只有纯虚函数的C++类，不过对它进行了一些改造来兼容C和其他一些编程语言。
        在这样改造之后，出问题的还有析构过程~MyClass()或者说delete myClass，因为同一个对象可能返回了很多个接口，有些接口还在被使用，如果其中一个被人delete了，其他接口都会出错，所以又引入了引用计数，来让许多人可以共享同一个对象。
其实到此为止也并不算是很奇怪的技术，我们用C++有的时候也会使用Factory方法来代替构造函数实现某些特殊的多态，也会用引用计数等等。COM技术的奇怪地方在于微软实在是脑洞太大了，它们构造了一个操作系统级别的Factory，规定所有人的Interface都统一用UUID来标识，以后想要哪个Interface只要报出UUID来就行了。这样甚至连链接到特定的dll都省了。   这就好      比一个COM程序员，只要他在Windows平台上，调用别的库就只要首先翻一下魔导书，查到了一个用奇怪文字写的“Excel = {xxx-xxx-xxxx…}”的记号，然后它只要对着空中喊一声：“召唤，Excel！CoCreateInstance, {xxx-xxx-xxxx…}”
      然后呼的从魔法阵里面窜出来了一个怪物，它长什么样我们完全看不清，因为这时候它的类型是IUnknow，这是脑洞奇大无比的微软为所有接口设计的一个基类。我们需要进一步要求它变成我们能控制的接口形态，于是我们再喊下一条指令：“变身，Excel 2003形态！QueryInterface, {xxx-xxx-xxxx…}”。QueryInterface使用的是另一个UUID，用来表示不同版本的接口。于是怪物就变成了我们需要的Excel 2003接口，虽然我们不知道它实际上是2003还是2007还是更高版本。
      等我们使唤完这只召唤兽，我们就会对它说“回去吧，召唤兽！Release！”但是它不一定听话，因为之前给它的命令也许还没有执行完，它会忠诚地等到执行完再回去，当然我们并不关心这些细节。

微软大概会觉得自己设计出了软件史上最完美的二进制接口，从今以后所有的第三方库都可以涵盖在这套接口之下。然而历史的车轮是无情的，它碾过那些自以为是的人的速度总是会比想象的更快。com用起来过于复杂，这就导致了后来的vm的方式来达到语言互通，vm提供了基础的语言或者说运行时的抽象，上层语言架构在vm之上，之后的语言互通就好办了，这条路被java证实了，而且很成功。Java的直接基于类的接口被广泛应用，开发使用起来远远来的简单，即便偶尔出点问题大家也都想办法解决了，事实证明程序员并不愿意花10倍的编写代码的时间来解决二进制库的版本兼容问题，他们更愿意假装没看见。所以微软就放弃了com，走了CLR。很快微软也抄了一个.NET托管dll的方案出来，于是纯的二进制接口COM就慢慢被抛弃了。

CLR:
CLR是通用语言运行平台的简称。通用语言运行平台(Common Language Runtime，简称CLR)是微软为他们的.Net虚拟机所选用的名称。这是通用语言架构的微软实现版本，它定义了一个代码运行的环境。CLR运行一种称为“通用中间语言”的字节码，这个是微软的通用中间语言实现版本。CLR运行在微软的视窗操作系统上。查看通用语言架构可以找到该规格的实现版本列表。其中有一些版本是运行在非Windows的操作系统中。扩展资料：CLR(公共语言运行库,Common Language Runtime)和Java虚拟机一样也是一个运行时环境，是一个可由多种编程语言使用的运行环境。CLR的核心功能包括：内存管理、程序集加载、安全性、异常处理和线程同步，可由面向CLR的所有语言使用。并保证应用和底层操作系统之间必要的分离。CLR是.NET Framework的主要执行引擎。为了提高平台的可靠性，以及为了达到面向事务的电子商务应用所要求的稳定性级别，CLR还要负责其他一些任务，比如监视程序的运行。按照.NET的说法，在CLR监视之下运行的程序属于“托管的”（managed）代码，而不在CLR之下、直接在裸机上运行的应用或者组件属于“非托管的”（unmanaged）的代码。跨语言集成的能力：CLR包含了一个丰富的语言特性集，保证了它与各种程序设计语言的兼容性。这一特性集即公用语言规范。

COM，OLE，ActiveX，OCX，VBScript，历史不会忘记你们的…COM在当时是一个伟大的发明，到今天，其实COM都是C++的二进制本机代码的动态链接的最佳的选择（Windows上的）。COM在Windows操作系统底层继续发挥余热的时间肯定还会很长，因为永远都会有偏底层的C++开发的需要，比如游戏之类。不过技术革新太快，技术趋势已经很明确了。
————————————————
版权声明：本文为CSDN博主「易明天下」的原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xsb1815/article/details/103298611