从OLE到COM，再到ActiveX，再到.NET

被这几个概念折磨了将近半年，网上没有一篇文章从头到尾把这些技术和框架的关系理个清楚，我整个人比较懒，但实在是怕自己忘，必须写下来才安心。

这个假期可能对比着看了能有几百个网页吧，也找了几本权威的书，写下的应该是比较有把握，如果有说的不对的地方，还麻烦高人指教

从体系结构角度讲，OLE和ActiveX都是建立在COM技术之上的，而.NET框架发展自COM技术，一定程度上汲取了COM的优点，并克服了其主要缺点。

从时间的角度讲，在这四者中，首先出现的其实是OLE技术，然后是COM技术，然后是ActiveX，最后是.NET。

OLE技术的萌芽

作为COM技术前身的OLE，其最初含义是指在程序之间链接和嵌入对象数据（Object Linking and Embedding）。它提供了建立混合文档的手段（资深Windows3.X用户可能记得当初在Word6.0中插入一个图形的新奇和喜悦，有关复合文档，后面文章详细讲述），使得那些没有太多专业知识的用户能够很容易地协调多个应用程序完成混合文档的建立。

1991年制定的OLE1.0规范主要解决多个应用程序之间的通信和消息传递问题，微软希望第三方开发商能够遵守这个规范，以使在当时的Windows平台上的应用程序能够相互协调工作，更大的提高工作效率。然而事与愿违，只有很少的软件开发商支持它。

为什么会这样呢？原因要从头说起，最初的OLE1.0的实现基于一种叫做动态数据交换（Dynamic DataExchange，DDE）的通信协议，理论上说，它可以让应用程序之间自动获取彼此的最新数据。但是DDE非常之慢，并且编写出能工作的DDE代码是一件相当困难的工作，另外DDE也并不太健壮和灵活[1]。

总之，OLE技术急需要一套更好的框架才能继续发展，这也就促成了后来COM技术的诞生

 

成也OLE败也OLE

微软于1993年发布了新的规范——OLE2.0，它在原有的基础上完善并增强了以下各方面的性能：

 

1．OLE自动化：一个程序有计划地控制另一个程序的能力。

2．OLE控件：小型的组件程序，可嵌入到另外的程序，提供自己的专有功能。

3．OLE文档：完善了早期的混合文档功能，不仅支持简单链接和嵌入，还支持在位激活、拖放等功能。

 

强大的功能使得很多的开发商开始支持新的OLE技术，微软在OLE2.0中使用了一个称为COM（Component ObjectModel，即组件对象模式）的新规范做为基础。COM相比DDE来说更小，更快，也更加强壮和灵活。

正是这样，同早期使用DDE的功能薄弱的OLE1.0相比，OLE2.0得到了更多软件厂商的支持。许多程序设计人员编写了大量的实现OLE自动化服务器功能的组件（不一定是EXE文件），这些组件一般不求功能齐全、强大，而是实现专门的功能，可以被其它程序编程控制，由此承袭OLE的名字称为OLE控件。

微软也籍此赢得了广大软件厂商的支持，使OLE技术深入人心。然而由于早期的OLE1.0的糟糕体验，人们对OLE技术形成了很多成见，导致后来的人们总把在Word中插入图形当作OLE技术的全部，各类资料在介绍新OLE技术时命名也不统一，造成很大的混乱。

这些都阻碍着OLE的推广，也使得COM技术的巨大潜力无法施展。

 

OLE 96——ActiveX框架

1996年，微软重新制订了一个关于OLE的规范——OLE96规范。这个规范扩展了 OLE控件的能力，并贯彻微软的Internet战略使它更易于在网络环境中使用。

这一次微软做足了打算，为了打消人们心中对OLE技术的狭隘成见，打消命名上的混乱，重新给OLE控件贴上另一个标签——ActiveX控件。不仅如此，以前的什么OLE文档也相应称为ActiveX文档了。总之，为了满足Internet战略，微软把OLE换成了ActiveX，企图使人们重新看待新的OLE——ActiveX，把它看做网络上的解决软件组件问题的标准。许多在Windows上同微软合作得很好的厂商在开发新版本软件时都开始支持ActiveX技术，例如Delphi、PowerBuild等开发工具。原来同Windows竞争的操作系统也开始支持ActiveX，例如Macintosh，甚至老对手OS/2上也可以使用ActiveX控件。

可见，直到1996年，OLE从以往的基于DDE的复合文档技术，化腐朽为神奇般地变成了基于COM的ActiveX技术。此时ActiveX，既是所有以COM为核心的技术总称。

 

COM时代的到来

如之前所说，是复合文档技术的需求造就了COM。但正如长距离输电的需求衍生出了交流电，而交流电的优点并不只是长距离输电一样，COM作为一种底层的规范，它的潜力远不止复合文档技术。他能够让不同的进程彼此通信，调用并创建彼此对象的实例，甚至修改它们，一个COM组件（ActiveX控件）可由不同语言的开发工具开发以及调用，包括C++和VisualBasic或PowerBuilder，甚至一些技术性语言如VBScript。这为大型软件的开发提供了极大的便利。

如下图，普通DLL，只有部分语言可以调用，很多脚本语言都无法调用，并且提供的是面向过程的接口，接口参数类型不统一，比如有一些结构体作参数、指针作参数甚至C++类对象作参数的函数，在其它没有指针的语言中调用起来很麻烦甚至无法调用。

而以COM组建的形式写出来的DLL可以给几乎任何语言调用，包括脚本语言，并且提供面向对象的接口，并且接口参数类型一般都是统一的。

 

 

弊端渐显

尽管COM技术如此强大，但它仍有着难以克服的缺陷。一方面，编写COM组件的技术门槛过高，必须对内存模型有深入的理解。另一方面，COM的接口组织形式决定了它的兼容性问题，一个接口发布之后便不能再修改，加一个函数也不行，甚至方法与属性的顺序在发布之后不能变。这为大型软件的开发带来了巨大的压力。

 

.NET的到来

2002年微软发布了新的.NET框架，这个框架致力于帮助开发者更好的进行敏捷软件开发、快速应用开发、平台无关性和网络透明化的软件开发平台，它由COM发展而来，汲取了COM的优点，但又完全脱离COM技术的制约，是一套包含了底层运行库和顶层开发技术的完全独立的框架。它与COM最本质的区别在于COM组件是非托管对象，这意味着它可以不需要任何环境而直接运行。而.NET组件是托管对象，必须有.NET框架环境才能运行。

[1] COM技术内幕.清华大学出版社.Dale Rogerson.杨秀章(译).p9.1998