最近在看《Delhpi5开发人员指南》，读到ActiveX，书上说到ActiveX时是这么说的：
什么是ActiveX控件
A c t i v e X控件是充分利用O L E和A c t i v e X技术的自定义控件。V B X是为1 6位的Visual Basic设计的，因而也受限于Visual Basic的不足。A c t i v e X控件是基于与应用程序无关的思想而设计的。你可以简单地认为A c t i v e X控件合并了V B X技术和A c t i v e X标准。在本章中，可以认为O L E与A c t i v e X是同一回事。
从本质上讲，A c t i v e X控件是一个A c t i v e X服务器，它能提供所有的O L E功能和服务，可视化编辑、拖放和O L E自动化。与所有的A c t i v e X服务器一样，A c t i v e X控件需要系统注册表中进行注册。A c t i v e X控件可以用许多产品来开发，包括D e l p h i、Borland C++Builder、Visual C++以及Visual Basic。
M i c r o s o f t积极鼓励把A c t i v e X控件作为与应用程序无关的自定义控件。M i c r o s o f t已经声明，Wi n 3 2或更高的操作系统将不再直接支持V B X技术。正因为如此，开发人员在开发3 2位应用程序时，应优先考虑A c t i v e X控件，而不是V B X控件。
这中间提到了三个概念，OLE、VBX和ActiveX服务器，我到网上找了一些资料：
1、OLE:
定义：Object Linking and Embedding,对象连接与嵌入，简称OLE技术。OLE不仅是桌面应用程序集成，而且还定义和实现了一种允许应用程序作为软件“对象”(数据集合和操作数据的函数)彼此进行“连接”的机制，这种连接机制和协议称为部件对象模型(Component Object Model),简称COM。OLE可以用来创建复合文档，复合文档包含了创建于不同源应用程序，有着不同类型的数据，因此它可以把文字、声音、图像、表格等组合在一起。
特点：对象链接和嵌入。在客户应用程序间传输和共享信息的一组综合标准。允许创建带有指向应用程序的链接的混合文档以使用户修改时不必在应用程序间切换的协议。OLE基于组件对象模型(COM) 并允许开发可在多个应用程序间互操作的可复用即插即用对象。该协议已广泛用于商业上，在商业中电子表格、字处理程序、财务软件包和其他应用程序可以通过客户/服务器体系共享和链接单独的信息
2、VBX
VBX是Visual Baisc开发环境的一些内带工具，最早由C++开发，后来却都是用VB自己开发的。VBX是一类DLL应用程序，具有特殊的支持以便可以在VB系统中使用。
{在google上搜索时，输入vbx能找到相关的正确资料就很少了，可以肯定的是这是当时VB中的一项控件技术，估计当时的高度跟现在的ACTIVEX差不多}
3、ActiveX服务器
{在网上找这个名词已经是头脑一片混乱了，因为这牵涉到了COM技术，还好找了一篇系统介绍这些技术的文章，贴过来看看}
COM、OLE、ActiveX及COM+篇
微软的许多技术，如OLE、ActiveX、以及DirectX等都是基于COM技术而建立起来的。微软本身也大量地使用COM组件来定制他们的应用程序及操作系统。那么，什么是COM呢?
所谓COM即“组件对象模型”，是一种说明如何建立可动态互变组件的规范，此规范提供了为保证能够互操作，客户和组件应遵循的一些二进制和网络标准。通过这种标准将可以在任意两个组件之间进行通信而不用考虑其所处的操作环境是否相同、使用的开发语言是否一致以及是否运行于同一台计算机。开发COM的目的是为了使应用程序更易于定制、更为灵活。
其实，COM不是以一个单独的开发过程的一部分出现的。相反，它最初是以对象及嵌入系统的形式产生于Windows 3.0。我们知道，OLE 1允许一个应用程序(如WORD或EXCEL)可以不必打开第二个应用程序就能显示其它应用程序的数据。但OLE 1还存在两个局限:
·首先是嵌入的数据不能被应用程序所编辑;
·其次，没有标准化的系统用于存放嵌入的信息。
于是，出现了OLE 2，OLE 2是与WINDOWS 3.1一起推出的，它是第一个真正的COM技术，而OLE 1还不具备COM的各项特性—它使用的是另一种技术体系。OLE 2中产生了一种新的唯一的数据格式，称为复合文件。这种文件中能够包括所有OLE支持的应用程序的相关信息，并在任一工作的应用程序中支持编辑、更新、打印等功能。
但OLE 2仍然存在一些局限性，最为明显的是任何时候要对一个嵌入的数据进行编辑都得重新打开一个窗口。对这一点的改进，生成了OLE的一个新版本，称为OLE自动化。该技术除了允许在调用数据的应用程序内部进行编辑(称为内部编辑)，还在OLE 2的基础上加入了其它两项与COM技术相关的改进;一是提供了非C++开发程序(如VB程序)接入COM功能的能力;二是支持存在于复合文件以外的基于COM技术的部件的创建。Windows 3.11全面支持自动化技术。
虽然，这最后一次的技术改进给COM带来了最持久的冲击，但是COM的OLE实现并仍然没有实现Bill Gate先生的部件化软件的梦想。随之而来的另一技术革新却通过从未想过的机制—VBX控件使之变成了现实。VBX是Visual Baisc开发环境的一些内带工具，最早由C++开发，后来却都是用VB自己开发的。VBX是一类DLL应用程序，具有特殊的支持以便可以在VB系统中使用。在一年左右的时间内，VBX控件的市场迅速发展成为一个几百万美元的产业，并带动了VB产品的销售。VBX具有两项以前的自动化服务器所不具备的重要性质:用户接口和它与客户(容器)的通信能力。
VBX的这种出乎意料的成功让微软决定让COM工作组在自动化基础上增加等效于VBX的性能。这一开发过程的结果就是OCX控件(是一种特殊的自动化DLL服务器)，它采用COM技术支持VBX控件的所有功能，而且它从此升级为32位的控件。可惜，在OCX尚未来得及普及以前，因特网和Java的出现使它们被重新改造成了ActiveX控件。
当时，没有谁会预料到Java和Internet会在WWW领域以氢弹的威力在计算机领域爆炸。微软长期以来一直认为他们在PC机软件领域的垄断是无可挑战的，但是Java和网页浏览器伴随着Internet，以一种全新的方式进入到个人微机的软件领域，且该领域由Sun和Netscape控制而不是微软。作为迎击，COM变成了ActiveX，复合文件变成了ActiveX文件，OCX控件变成了ActiveX控件等等。基于COM的ActiveX组件均根据Internet的特点增加相应的新特征，如保密安全性能、代码短、数据支持异步下载。同时，ActiveX组件还具有如下特点:
·ActiveX在自动化服务器上增加了用户接口;
·通用属性和属性页机制使ActiveX控件的行为标准化;
·连接点机制支持从ActiveX控件向容器发送事件;
·ActiveX的持续性解决了越时的状态存储问题。
总之，OLE1、OLE2、OLE自动化、VBX控件、OCX控件、ActiveX以及COM+都是COM概念在Windows操作系统的各种实现方式。如今，COM已成为微软产品系列的核心组成技术:
·Internet Explorer 4网络浏览器支持所有的ActiveX控件，实际上它正是采用了一个ActiveX组件用于它的显示接口;
·Windows 98这种新版的Windows操作系统将IE与操作系统捆绑在一起，它基于COM技术并支持活动桌面，使桌面部件具有网络应用的功能;
·Internet信息服务器(IIS)是微软加入网络服务器大战的重量级武器，IIS包括很多的功能强大的基于COM技术的系列内容，如Active Server Page，ISAPI扩展和ISAPI过滤器;
·微软事务服务器(MTS)是一种面向数据库的系统，MTS采用COM技术以支持多种数据库系统和售货机的混合事务处理，并仿造非数据库的执行方式，将事务的处理变成单步的行为，其结果可以为“成功”、“失败”和“返回”而不会因为处理失败而丢失数据;
·OLE DB推回到COM的OLE 2技术上，它采用与ODBC数据库相同的技术，支持非数据库应用程序与面向数据库的技术(如MTS)共同工作。
从另一方面看，最初，Windows是利用DLL在二进制级实现代码共享的。这也是Windows程序运行的关键——重用kernel32.dll,user32.dll等。但DLL是针对C接口而写的，它们只能被C或理解C调用规范的语言使用。由编程语言来负责实现共享代码，而不是由DLL本身。这样的话，DLL的使用受到限制。尽管在后来，MFC又引入了另外一种MFC扩展DLL二进制共享机制，但它的使用仍受限制——只能在MFC程序中使用。
COM通过定义二进制标准解决了这些问题，即COM明确指出二进制模块(DLL和EXE)必须被编译成与指定的结构匹配。这个标准也确切地规定了在内存中如何组织COM对象。COM定义的二进制标准还必须独立于任何编程语言(如C++中的命名修饰)。事实上，COM正是充分利用了Win32 DLL的灵活性才得以真正在Windows平台上实现的。COM的发布形式是:以win32动态链接库(DLL)或者可执行文件(EXE)的形式发布的可执行代码组成。
注意，COM本身也要实现一个称为COM库的API，由该库提供诸如客户对组件的查询，以及组件的注册/反注册等一系列服务。一般来说，COM库由操作系统加以实现，程序员不必关心其实现细节。
【注】DirectX技术
要在Windows平台上进行游戏开发必须了解两个重量级游戏API:DirectX和OpenGL。其中，DirectX是微软开发的专门用于优化游戏制作的API。DirectX由很多组件组成:DirectDraw、DirectSound、DirectMusic、DirectPlay、Direct3D、DirectInput、DirectSetup。它是允许你直接控制计算机硬件设备的软件，它比Windows GDI要快好几倍，可用于不同的语言和多种平台，支持从绘制象素到高级3D图像，从播放简单声音到数字音乐，从键盘控制到反震手柄……几乎为你的游戏开发提供了所需的一切。注意，DirectX的基础正是COM技术。
什么是COM+?
必须明确，COM+并不是COM的简单升级，但它的底层结构仍以COM为基础，COM+综合了COM、DCOM和MTS这些技术要素，把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统;因此，COM+与操作系统的结合更加紧密。下图3展示了COM+与MTS、COM/DCOM的关系。
图3.COM+与MTS、COM/DCOM的关系
另一方面，COM+不再局限于COM的组件技术，它更加注重于分布式网络应用的设计和实现。COM+继承了COM几乎全部的优势，同时又避免了COM实现中的一些不足，把COM、DCOM和MTS的编程模型有机地结合起来，继承了它们的绝大多数特性，在原有的特性上增加了新的功能:
·真正的异步通讯。
·事件服务。
·可伸缩性。
·可管理和可配置性。
·易于开发。
COM+标志着微软的组件技术达到了一个新的高度，它不再局限于一台机器上的桌面系统，而是把目标指向了更为广阔的企业内部网，甚至国际互连网。COM+与多层结构模型(Windows DNA结构，详见下一节)以及Windows操作系统为企业应用或Web应用提供了一套完整的解决方案。
【问题】.NET时代，COM是否会消失?
不会。其实，.NET只不过是COM的别名而已。对于一个经验丰富的C++程序员而言，.NET就是COM的进化，而微软内部.NET可以说是“COM 3.0”。其实，CLR就是一个不折不扣的COM对象。但是，请注意，.NET使用一种不同的方法来编写组件，这样.NET组件与原先的COM组件存在明显的不同。.NET组件不需要使用注册表和类型库，因为所有关于组件的信息都以元数据的形式包含在程序集(Assembly)中。但是，借助于一个称为COM Interop的工具，COM对象和.NET对象可以很好地协作:通过提供软件包类，.NET对象可以访问COM对象;通过提供所有的注册表项和COM对象构建机制，COM对象可以访问.NET对象。