服务器镜像用什么连接

现在有几个备选方案：
1。程序移植，数据库仍统一管理。
这种方式最易实现，但存在的问题数据库必须开放internet通道，如何保证安全，是个问题。而且，访问速度是否能达到要求同样是个问题。采用通道？速度上又不能满足。
2。程序和数据库都移植。
这种方式能实现的镜像效果最好，但实施难度较大，在国内网站中实现这种镜像的还不多。这方案还有2种不同实现方式：
21 程序不改，数据库同步
这种方式相对简单些，程序部分基本不用改动，依靠sqlserver2000的同步功能来实现数据同步。
但从我在erp项目实施中获得的经验看，这种方式看似简单，但其实问题可能最多。首先，sqlserver同样继承了microsoft的老毛病：效率不高。同步复制3G的数据这个速度我实在不乐观。其次需直接开放internet访问，如何避免安全问题，还没想好，还需要找安全专家咨询。最后，同步复制过程中如果发生网络故障，如何保证多数据源的数据完整性和一致性又是个极大的挑战。
22 平台程序改动，数据库异步复制
这种方式对程序的要求较高，网站平台架构的调整较大。等于是把网站由单站点程序转为多站点平台。这样在业务和数据一致性上都有较高要求。这种方式工作最大，难度看似也最大，但我认为这种方式最可行。首先，把程序结构按照事务划分，借助mts可实现多站点统一事务，保证数据的一致性；其次，数据采用异步复制，能避免网络中断造成的数据不完整，防止引起某些逻辑错误；最后，这种方式要求我们尽量少的访问数据库，由于负载的分担，可考虑大量的使用内存替代数据库，提高整体的访问效率。
不过，由于存在时间差，会造成镜像站点间的内容不一致的情况，我还没想好如何解决。 并且,需要开发一个事务调度程序对各镜像数据进行统一更新维护,每秒可能需要面临200次的请求，程序性能和效率会是问题，如何采用分布式我也没想好。

ActiveX
一、ActiveX的由来
ActiveX最初只不过是一个商标名称而已，它所涵盖的技术并不是各自孤立的，其
中多数都与Internet和Web有一定的关联。更重要的是，ActiveX的整体技术是由
Microsoft的 COM(Component Object Model，组件对象模型)构筑的。但不要误认
为ActiveX是定义了所有包含基于COM的技术。COM与Microsoft Office和Windows
以及Microsoft现在所做的一切都有关联，但显然这些产品并不是ActiveX家族中
的成员。
ActiveX是从Microsoft的复合文档技术——OLE成长起来的。OLE最初发布的版本
，只是瞄准复合文档，但在后续版本OLE2中，导入了COM。COM是应OLE设计者的需
求而诞生的。其基本的出发点是想让某个软件通过一个通用的机构为另一个软件
提供服务。因而，COM 的第一个使用者是OLE2。实际上，COM与复合文档间，没有
多大关系。后来，COM就作为与复合文档完全无关的技术，开始被广泛使用。这样
一来，Microsoft就开始"染指"通用平台技术。但COM不是产品，它需要一个商标
名称。不巧，市场专家们选用了"OLE"作为商标名称。于是，使用COM的技术都开
始贴上了OLE的标签。当然，这些技术中的绝大部分与复合文档没有关系。
Microsoft要想向人们解释:"OLE不单单是指复合文档!"，这要花费相当的精力和
时间。
于是，在1996年春，Microsoft改变了主意，选择了ActiveX作为新商标名。
ActiveX是指宽松定义的、基于COM的技术集合，而OLE仍然仅指复合文档。当然，
最重要的核心还是 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虽然起源于复合文档，但却可有
效地适用于许多软件问题。
二、ActiveX王国
Active平台是Microsoft的世界观。其基本思想是:使用ActiveX控件，来构筑包括
从与用户交互和适应COM的事务处理监视器到Web服务器、全部实现自动化的机构
。Active 平台包括两大部分:Active Server和Active Client。
Active Server实际上是中间层。使用组件或Active服务器页面，来提供用于业务
逻辑和主要应用处理的场所。ActiveServer的技术，其核心是NT Server、
Microsoft事务处理服务器、数据管理服务、目录服务、Web服务以及网络服务。
事务处理服务器是把线程产生和数据库多重化等传统的TP监控功能与Microsoft的
基于组件的编程模型结合起来。数据管理服务等Active平台的其他组件是用OLE
DB和ODBC ，访问DB2、Oracle、SQL Server等的数据源。目录服务是在DCOM
(Distributed COM，分布式COM)的周围，提供目录服务层，这样使远程对象在网
络上能相互搜索。Web服务以Inter net信息服务器为中心进行构筑，它为服务器
上的Web应用开发，提供脚本生成(Scripting )机构。网络服务以DCOM为中心进行
构筑，通过以同步MS-RPC为中介的网络，使之能够连接控件。
Active Client是一种交叉平台。Microsoft的技术纵然是独家所有，但也希望将
这种技术向多个OS开放。具体实施计划是使用脚本引擎(Scripting Engine)。这
种脚本引擎是由标准的HTML和带有Microsoft特色的Java虚拟机(JVM)、Microsoft
的VBScript与JSc ript所构成的。Active Client组装进了Microsoft的IE 30和
40，通过ActiveX，可以变成用户的C/S应用的一部分。
从清一色采用Windows的企业用户来看，Active平台可以提供坚固的、具有可缩放
性的服务器应用开发平台。ActiveServer在TP监视器这类高端产品的场合，也利
用常见的一些工具和技术。因此，小型工作组和Intranet应用不会超越Active
Server的能力。Acti ve平台的目标机虽是异种机环境，但由于过分依赖IE，所以
不能驱动客户端。尽管在一些非Windows平台上也推出了Explorer，但最好的支持
、最新版本的Explorer还是在Window s上。
三、ActiveX的进展
1向分布计算扩充
COM的最初版本假定COM对象及其客户端是在同一个机器上运行(可以在同一个进程
内 ，也可以在不同的进程内)，DCOM是ActiveX家族中的重要成员。后来，它在
Windows 95中也能使用。DCOM对于客户端制作COM对象、进行交互的方法没有做任
何改变。
客户端使用完全相同的代码，可以访问本地以及远程对象。但许多场合下，客户
想使用少数的DCOM附件。DCOM备有分布式安全保密机制，提供认证和数据加密。
在1998年要发布的Windows NT 50中，要将Kerberos等安全保密协议，追加到
DCOM中。DCOM已能够利用域名服务等简洁的目录服务，以用于搜寻在其他机器上
的COM对象。NT 50要追加对Acti ve Directory的支持。Active Directory是基
于域名服务和轻型目录访问协议的。
DCOM的劲敌，此前一直是OMG(Object Management Group)的CORBA(Common Object
R equest Broker Architecture)。它被组装进了Iona的Orbix和Visigenic的
VisiBroker等产品中。不久前，另一种支持分散对象的技术——Java的远程方法
调用出台了。无论是C ORBA，还是DCOM，都能在多种语言写的对象间进行通信。
而RMI却不同，它只限于在由Java 实现的对象间进行通信。显然，这是个制约。
但RMI使用起来非常简单。另外，RMI的开发者可以用Java来设计协议规范。因此
，在语言的功能上，可以做得浑然一体。
若写一个只处理两三个客户端的DCOM服务器，还是比较简单的。但是，要构筑一
个高效处理几百、几千个客户端的DCOM服务器，则相当之难。
为了便于编写可缩放的DCOM服务器，Microsoft发布了事务处理服务器(MTS)。MTS
在支持事务处理的同时，也提供自动生成线索和智能对象的重复使用等服务。MTS
使可缩放服务器的制作变得相当简单。即使是无需事务处理的应用，使用MTS也有
好处。实际上，M icrosoft鼓励人们用VB来写MTS应用。这与开发业务服务器的传
统手法不同，所有的MTS应用，都是作为一个以上的COM对象来编写，且必须以DLL
来实现。一般情况下，客户端看不到 MTS。客户端只管一如既往地制作、使用COM
对象即可。
2组件的标准化
基于组件的应用开发，其方法和组装电子装置一样，可以用已制作好的组件部件
来构筑应用。桌面用的、基于COM的组件叫做ActiveX控件。所谓ActiveX控件不过
是遵从一定的标准、与客户端交互的COM对象而已。
例如，ActiveX控件必须通过Automation (即使用dispinterfaces)来公开方法。
用这个被标准化的交互功能，可以在多个不同的上下文中，使用同一个控件。在
这个标准接口的"幕后"，ActiveX控件几乎是什么都能执行。现在，许多软件公司
都能提供实现各种功能的控件。
ActiveX控件是作为DDL编写的，为此，必须装载到某个容器中。ActiveX控件的原
型容器是VB，除此之外，还有多种容器可供选择。目前，一个非常重要的控件容
器是Microsoft 的Web浏览器
现在所谓ActiveX控件的那些内容，是实现许多方法所必须的。已经把它们从机器
的本地硬盘移到了VB等容器中。几百KB和几MB的控件，似乎没有什么大区别。但
要将控件装载到Web浏览器时，很可能要通过速度很慢的电话线。现在，控件的大
小已经是非常关键的问题。一旦要执行超过了某个限度以上的控件，就会延长下
载时间。因此，Microsoft规定 :在ActiveX控件中，只能执行绝对必要的功能。
Apple和IBM推行的OpenDoc，曾是ActiveX控件的主要竞争对手。现在OpenDoc的赞
助企业，已正式宣告中止资助。大部分与Microsoft对抗的企业，转而支持
JavaBeans(基于J ava的组件结构)。ActiveX控件，基本上都是和Windows捆绑在
一起、以二进制机器代码发放的，而JavaBeans却不同，它在哪儿都能执行。这当
然是有代价的。显而易见，只要不牺牲可移植性，就不可能完全、彻底地利用本
地环境。要编写从公共Internet上能下载的组件时，应优先选择JavaBeans。
桌面组件市场在持续、急速增长。其中绝大部分是以ActiveX控件构筑的(目前
Java Beans仍然是少数)。但服务器组件的标准化要落后一些。在桌面上，Web浏
览器、VB以及 PowerBuilder这些编程环境，作为容器是强有力的。但服务器容器
又该当如何呢作为服务器上的组件容器，事务处理服务器是一个较好的选择。
Microsoft的竞争对手，千方百计要阻止MTS和NT称霸市场。他们正在快马加鞭地
制订服务器上的组件标准，其中最有前途的是Enterprise JavaBeans。它是
JavaBeans的扩充 ，并定义了事务处理服务器接口。Enterprise JavaBeans的支
持者们，希望独立软件厂商不是将服务器组件作为COM组件来编写，而是要作为
Beans来编写。
四、ActiveX的构筑工具
随着ActiveX控件的推广，ActiveX控件的开发工具逐日增加。由于ActiveX不依赖
于语言，所以传统的开发工具基本上都能构筑、配备ActiveX控件。最常用的有
Delphi、Po werBuilder以及Visual Basic、Visual C++、Visual J++等。
1 基本概况
用3GL开发ActiveX控件的方法有:①MFC (Microsoft Foundation Class，
Microsoft 基础类)，②ATL(ActiveX Template Library，ActiveX模板库)，③
BaseCtrl Framework等。MFC最经典，采用MFC，可以使开发者不去关心接口，而
是集中精力关注对象的动作。缺点是控件的规模较大且执行时DLL必须与容器同时
存在。ATL可利用模板生成代码。就是说 ，库和DLL无需与控件一起推出。在ATL
中，需要从作为模板存在的几个基本类派生类。AT L也有缺点，即接口的处理较
难，应用中必要的接口，必须分别制作。另外，ATL不支持类向导(Class Wizard)
。遗憾的是，没有使对象描述语言(Object Description Language)和接口定义语
言文件、与用户代码自动同步的向导。BaseCtrl是个简便型库。与ATL非常相似，
但无模板。实际上，由于BaseCtrl过于简便，Microsoft并不支持它。在BaseCtrl
中，带有几个万能控件(Skeleton Control)。BaseCtrl提供容易理解的ActiveX开
发模型，但与 ATL相比并不简单，且灵活性也不及ATL。目前看来，对于ActiveX
控件开发者来说，BaseCt rl是个"苦涩"的选择。
2 开发工具
可制作ActiveX控件的、最初的工具是Microsoft的Visual C++。它可为ActiveX开
发者提供最多的控件。Visual J++也可以制作ActiveX控件。
Borland推出的两个工具(JBuilder和IntraBuilder)也非常令人瞩目。但是，用
Borl and的工具能制作ActiveX组件的，只有Delphi 30和C++ Builder。Borland
把Delphi的A ctiveX开发功能，叫作Active Inside。它是将任意的Delphi
Window做成ActiveX的形式。Active Inside备有配备在Web上的新控件。Delphi可
以将控件链接到COM和DCOM。
PowerBuilder 50是改造成能用于ActiveX开发的、客户机/服务器开发工具。
Powe rBuilder可以将Data Window(PowerBuilder应用开发的核心部分)作为
ActiveX控件来配备。以使现在的PowerBuilder开发者，能使用PowerScript编程
语言等某些熟悉的功能。
具有制作ActivX控件最好工具的，当属Microsoft。例如，若用Visual Basic 50
，开发者就可使用可视化编程环境和本机的Visual Basic for Application语言
，来开发控件。
五、ActiveX
的未来的确，Windows和Windows NT的世界，是ActiveX技术的最佳环境。但无论
Micr osoft如何卖力推进它的OS，也不能使所有的企业都变成清一色的Windows。
因此，Micros oft要设法使COM、DCOM以及ActiveX家族的一部分，也能在其他OS
上使用。现在，在Macin tosh中，已经支持ActiveX，其中也包含对ActiveX控件
的支持。Software AG正在把这些技术移植到多个Unix和IBM的OS/390上。DEC和HP
也打算将这些技术在自己的系统上使用，他们也是用移植Microsoft代码的办法来
实现的。
COM已成为Windows 95和Windows NT环境下基础软件的重要部分，但它的未来还有
许多不确定的因素。例如，Microsoft是否能将COM作为多平台技术，让其继续存
在发展下去 为了使NT服务器能适合已有的企业，就必须要使DCOM等分布式服务
也能在非Microsoft平台上应用。要解决这些问题， 需花费相当长的一段时间。
另外， 基于CORBA的产品和Jav a的RMI，已成功地运行在多OS环境下。多平台
DCOM出台得越晚，CORBA和RMI就领先越多。
ActiveX控件和JavaBeans的竞争前景如何无论使软件运行在Web浏览器上也好，
还是在另外的地方运行也好，总之，组件式软件(ComponentWare)将是下一个软件
开发的热点。目前，ActiveX控件虽然暂居领先，但由于OpenDoc的自生自灭，与
Microsoft竞争的企业会结为一体与之抗衡。用户决不希望看到"一统天下"，仅就
这点而言，JavaBeans也会在这一市场竞争中抢占一席之地。

Visual Basic 的应用程序版（VBA）是Microsoft 公司长期追求的目标，使可编程应用软件得到完美的实现，它作为一种通用的宏语言可被所有的Microsoft 可编程应用软件所共享。在没有VBA 以前，一些应用软件如Excel、Word、Access、Project 等都采用自己的宏语言供用户开发使用，但每种宏语言都是独立的，需要用户专门去学习，它们之间互不兼容，使得应用软件之间不能在程序上互联。拥有一种可跨越多个应用软件，使各应用软件产品具有高效、灵活且一致性的开发工具是至关重要的。VBA 作为一种新一代的标准宏语言，具有上述跨越多种应用软件并且具有控制应用软件对象的能力，使得程序设计人员仅需学习一种统一的标准宏语言，就可以转换到特定的应用软件上去，程序设计人员在编程和调试代码时所看到的是相同的用户界面，而且VBA 与原应用软件的宏语言相兼容，以保障用户在代码和工作上的投资。有了VBA 以后，多种应用程序共用一种宏语言，节省了程序人员的学习时间，提高了不同应用软件间的相互开发和调用能力。
在Office 2000 中，宏语言VBA 适用于所有应用程序，包括Word 、 Excel、PowerPoint、Access、Outlook 以及Project。在Office 97 的各应用程序中，新增了Visual Basic 编辑器。这样，用户无论是在Excel 中，还是在Word 中以至是在Access 中建立和管理VBA 都具有统一的方法和标准。
在介绍如何利用VBA 提高工作效率之前，首先介绍一些与VBA 有关的基础知识。
ActiveX
一、ActiveX的由来
ActiveX最初只不过是一个商标名称而已，它所涵盖的技术并不是各自孤立的，其中多数都与Internet和Web有一定的关联。更重要的是，ActiveX的整体技术是由Microsoft的 COM(Component Object Model，组件对象模型)构筑的。但不要误认为ActiveX是定义了所有包含基于COM的技术。COM与Microsoft Office和Windows以及Microsoft现在所做的一切都有关联，但显然这些产品并不是ActiveX家族中的成员。
ActiveX是从Microsoft的复合文档技术——OLE成长起来的。OLE最初发布的版本，只是瞄准复合文档，但在后续版本OLE2中，导入了COM。COM是应OLE设计者的需求而诞生的。其基本的出发点是想让某个软件通过一个通用的机构为另一个软件提供服务。因而，COM 的第一个使用者是OLE2。实际上，COM与复合文档间，没有多大关系。后来，COM就作为与复合文档完全无关的技术，开始被广泛使用。这样一来，Microsoft就开始"染指"通用平台技术。但COM不是产品，它需要一个商标名称。不巧，市场专家们选用了"OLE"作为商标名称。于是，使用COM的技术都开始贴上了OLE的标签。当然，这些技术中的绝大部分与复合文档没有关系。Microsoft要想向人们解释:"OLE不单单是指复合文档!"，这要花费相当的精力和时间。
于是，在1996年春，Microsoft改变了主意，选择了ActiveX作为新商标名。ActiveX是指宽松定义的、基于COM的技术集合，而OLE仍然仅指复合文档。当然，最重要的核心还是 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虽然起源于复合文档，但却可有效地适用于许多软件问题。
二、ActiveX王国
Active平台是Microsoft的世界观。其基本思想是:使用ActiveX控件，来构筑包括从与用户交互和适应COM的事务处理监视器到Web服务器、全部实现自动化的机构。Active 平台包括两大部分:Active Server和Active Client。
Active Server实际上是中间层。使用组件或Active服务器页面，来提供用于业务逻辑和主要应用处理的场所。ActiveServer的技术，其核心是NT Server、Microsoft事务处理服务器、数据管理服务、目录服务、Web服务以及网络服务。
事务处理服务器是把线程产生和数据库多重化等传统的TP监控功能与Microsoft的基于组件的编程模型结合起来。数据管理服务等Active平台的其他组件是用OLE DB和ODBC ，访问DB2、Oracle、SQL Server等的数据源。目录服务是在DCOM(Distributed COM，分布式COM)的周围，提供目录服务层，这样使远程对象在网络上能相互搜索。Web服务以Inter net信息服务器为中心进行构筑，它为服务器上的Web应用开发，提供脚本生成(Scripting )机构。网络服务以DCOM为中心进行构筑，通过以同步MS-RPC为中介的网络，使之能够连接控件。
Active Client是一种交叉平台。Microsoft的技术纵然是独家所有，但也希望将这种技术向多个OS开放。具体实施计划是使用脚本引擎(Scripting Engine)。这种脚本引擎是由标准的HTML和带有Microsoft特色的Java虚拟机(JVM)、Microsoft的VBScript与JSc ript所构成的。Active Client组装进了Microsoft的IE 30和40，通过ActiveX，可以变成用户的C/S应用的一部分。
从清一色采用Windows的企业用户来看，Active平台可以提供坚固的、具有可缩放性的服务器应用开发平台。ActiveServer在TP监视器这类高端产品的场合，也利用常见的一些工具和技术。因此，小型工作组和Intranet应用不会超越Active Server的能力。Acti ve平台的目标机虽是异种机环境，但由于过分依赖IE，所以不能驱动客户端。尽管在一些非Windows平台上也推出了Explorer，但最好的支持、最新版本的Explorer还是在Window s上。
三、ActiveX的进展
1向分布计算扩充
COM的最初版本假定COM对象及其客户端是在同一个机器上运行(可以在同一个进程内 ，也可以在不同的进程内)，DCOM是ActiveX家族中的重要成员。后来，它在Windows 95中也能使用。DCOM对于客户端制作COM对象、进行交互的方法没有做任何改变。
客户端使用完全相同的代码，可以访问本地以及远程对象。但许多场合下，客户想使用少数的DCOM附件。DCOM备有分布式安全保密机制，提供认证和数据加密。在1998年要发布的Windows NT 50中，要将Kerberos等安全保密协议，追加到DCOM中。DCOM已能够利用域名服务等简洁的目录服务，以用于搜寻在其他机器上的COM对象。NT 50要追加对Acti ve Directory的支持。Active Directory是基于域名服务和轻型目录访问协议的。
DCOM的劲敌，此前一直是OMG(Object Management Group)的CORBA(Common Object R equest Broker Architecture)。它被组装进了Iona的Orbix和Visigenic的VisiBroker等产品中。不久前，另一种支持分散对象的技术——Java的远程方法调用出台了。无论是C ORBA，还是DCOM，都能在多种语言写的对象间进行通信。而RMI却不同，它只限于在由Java 实现的对象间进行通信。显然，这是个制约。但RMI使用起来非常简单。另外，RMI的开发者可以用Java来设计协议规范。因此，在语言的功能上，可以做得浑然一体。
若写一个只处理两三个客户端的DCOM服务器，还是比较简单的。但是，要构筑一个高效处理几百、几千个客户端的DCOM服务器，则相当之难。
为了便于编写可缩放的DCOM服务器，Microsoft发布了事务处理服务器(MTS)。MTS在支持事务处理的同时，也提供自动生成线索和智能对象的重复使用等服务。MTS使可缩放服务器的制作变得相当简单。即使是无需事务处理的应用，使用MTS也有好处。实际上，M icrosoft鼓励人们用VB来写MTS应用。这与开发业务服务器的传统手法不同，所有的MTS应用，都是作为一个以上的COM对象来编写，且必须以DLL来实现。一般情况下，客户端看不到 MTS。客户端只管一如既往地制作、使用COM对象即可。
2组件的标准化
基于组件的应用开发，其方法和组装电子装置一样，可以用已制作好的组件部件来构筑应用。桌面用的、基于COM的组件叫做ActiveX控件。所谓ActiveX控件不过是遵从一定的标准、与客户端交互的COM对象而已。
例如，ActiveX控件必须通过Automation (即使用dispinterfaces)来公开方法。用这个被标准化的交互功能，可以在多个不同的上下文中，使用同一个控件。在这个标准接口的"幕后"，ActiveX控件几乎是什么都能执行。现在，许多软件公司都能提供实现各种功能的控件。
ActiveX控件是作为DDL编写的，为此，必须装载到某个容器中。ActiveX控件的原型容器是VB，除此之外，还有多种容器可供选择。目前，一个非常重要的控件容器是Microsoft 的Web浏览器
现在所谓ActiveX控件的那些内容，是实现许多方法所必须的。已经把它们从机器的本地硬盘移到了VB等容器中。几百KB和几MB的控件，似乎没有什么大区别。但要将控件装载到Web浏览器时，很可能要通过速度很慢的电话线。现在，控件的大小已经是非常关键的问题。一旦要执行超过了某个限度以上的控件，就会延长下载时间。因此，Microsoft规定 :在ActiveX控件中，只能执行绝对必要的功能。
Apple和IBM推行的OpenDoc，曾是ActiveX控件的主要竞争对手。现在OpenDoc的赞助企业，已正式宣告中止资助。大部分与Microsoft对抗的企业，转而支持JavaBeans(基于J ava的组件结构)。ActiveX控件，基本上都是和Windows捆绑在一起、以二进制机器代码发放的，而JavaBeans却不同，它在哪儿都能执行。这当然是有代价的。显而易见，只要不牺牲可移植性，就不可能完全、彻底地利用本地环境。要编写从公共Internet上能下载的组件时，应优先选择JavaBeans。
桌面组件市场在持续、急速增长。其中绝大部分是以ActiveX控件构筑的(目前Java Beans仍然是少数)。但服务器组件的标准化要落后一些。在桌面上，Web浏览器、VB以及 PowerBuilder这些编程环境，作为容器是强有力的。但服务器容器又该当如何呢作为服务器上的组件容器，事务处理服务器是一个较好的选择。
Microsoft的竞争对手，千方百计要阻止MTS和NT称霸市场。他们正在快马加鞭地制订服务器上的组件标准，其中最有前途的是Enterprise JavaBeans。它是JavaBeans的扩充 ，并定义了事务处理服务器接口。Enterprise JavaBeans的支持者们，希望独立软件厂商不是将服务器组件作为COM组件来编写，而是要作为Beans来编写。
四、ActiveX的构筑工具
随着ActiveX控件的推广，ActiveX控件的开发工具逐日增加。由于ActiveX不依赖于语言，所以传统的开发工具基本上都能构筑、配备ActiveX控件。最常用的有Delphi、Po werBuilder以及Visual Basic、Visual C++、Visual J++等。
1 基本概况
用3GL开发ActiveX控件的方法有:①MFC (Microsoft Foundation Class，Microsoft 基础类)，②ATL(ActiveX Template Library，ActiveX模板库)，③BaseCtrl Framework等。MFC最经典，采用MFC，可以使开发者不去关心接口，而是集中精力关注对象的动作。缺点是控件的规模较大且执行时DLL必须与容器同时存在。ATL可利用模板生成代码。就是说 ，库和DLL无需与控件一起推出。在ATL中，需要从作为模板存在的几个基本类派生类。AT L也有缺点，即接口的处理较难，应用中必要的接口，必须分别制作。另外，ATL不支持类向导(Class Wizard)。遗憾的是，没有使对象描述语言(Object Description Language)和接口定义语言文件、与用户代码自动同步的向导。BaseCtrl是个简便型库。与ATL非常相似，但无模板。实际上，由于BaseCtrl过于简便，Microsoft并不支持它。在BaseCtrl中，带有几个万能控件(Skeleton Control)。BaseCtrl提供容易理解的ActiveX开发模型，但与 ATL相比并不简单，且灵活性也不及ATL。目前看来，对于ActiveX控件开发者来说，BaseCt rl是个"苦涩"的选择。
2 开发工具
可制作ActiveX控件的、最初的工具是Microsoft的Visual C++。它可为ActiveX开发者提供最多的控件。Visual J++也可以制作ActiveX控件。
Borland推出的两个工具(JBuilder和IntraBuilder)也非常令人瞩目。但是，用Borl and的工具能制作ActiveX组件的，只有Delphi 30和C++ Builder。Borland把Delphi的A ctiveX开发功能，叫作Active Inside。它是将任意的Delphi Window做成ActiveX的形式。Active Inside备有配备在Web上的新控件。Delphi可以将控件链接到COM和DCOM。
PowerBuilder 50是改造成能用于ActiveX开发的、客户机/服务器开发工具。Powe rBuilder可以将Data Window(PowerBuilder应用开发的核心部分)作为ActiveX控件来配备。以使现在的PowerBuilder开发者，能使用PowerScript编程语言等某些熟悉的功能。
具有制作ActivX控件最好工具的，当属Microsoft。例如，若用Visual Basic 50，开发者就可使用可视化编程环境和本机的Visual Basic for Application语言，来开发控件。
五、ActiveX
的未来的确，Windows和Windows NT的世界，是ActiveX技术的最佳环境。但无论Micr osoft如何卖力推进它的OS，也不能使所有的企业都变成清一色的Windows。因此，Micros oft要设法使COM、DCOM以及ActiveX家族的一部分，也能在其他OS上使用。现在，在Macin tosh中，已经支持ActiveX，其中也包含对ActiveX控件的支持。Software AG正在把这些技术移植到多个Unix和IBM的OS/390上。DEC和HP也打算将这些技术在自己的系统上使用，他们也是用移植Microsoft代码的办法来实现的。
COM已成为Windows 95和Windows NT环境下基础软件的重要部分，但它的未来还有许多不确定的因素。例如，Microsoft是否能将COM作为多平台技术，让其继续存在发展下去 为了使NT服务器能适合已有的企业，就必须要使DCOM等分布式服务也能在非Microsoft平台上应用。要解决这些问题， 需花费相当长的一段时间。另外， 基于CORBA的产品和Jav a的RMI，已成功地运行在多OS环境下。多平台DCOM出台得越晚，CORBA和RMI就领先越多。
ActiveX控件和JavaBeans的竞争前景如何无论使软件运行在Web浏览器上也好，还是在另外的地方运行也好，总之，组件式软件(ComponentWare)将是下一个软件开发的热点。目前，ActiveX控件虽然暂居领先，但由于OpenDoc的自生自灭，与Microsoft竞争的企业会结为一体与之抗衡。用户决不希望看到"一统天下"，仅就这点而言，JavaBeans也会在这一市场竞争中抢占一席之地。
计算机科学里的宏是一种抽象，它根据一系列预定义的规则替换一定的文本模式。Excel 办公软件自动集成了“VBA”高级程序语言，用此语言编制出的程序就叫“宏”。使用“VBA”需要有一定的编程基础和耗费大量的时间，因此，绝大多数的使用者仅使用了Excel的一般制表功能，很少使用到“VBA”。
解释器或编译器在遇到宏时会自动进行这一模式替换。对于编译语言，宏展开在编译时发生，进行宏展开的工具常被称为宏展开器。宏这一术语也常常被用于许多类似的环境中，它们是源自宏展开的概念，这包括键盘宏和宏语言。绝大多数情况下，使用“宏”这个词的使用暗示着将小命令或动作转化为一系列指令。
宏的用途在于自动化频繁使用的序列或者是获得一种更强大的抽象能力－－但这常常是一回事。
计算机语言如C或汇编语言有简单的宏系统，由编译器或汇编器的预处理器实现。C的宏预处理器的工作只是简单的文本搜索和替换，使用附加的文本处理语言如M4，C 程序员可以获得更精巧的宏。
Lisp类语言如Common Lisp和Scheme有更精巧的宏系统: 宏的行为如同是函数对自身程序文本的变形，并且可以应用全部语言来表达这种变形。一个C宏可以定义一段语法的替换，然而一个Lisp的宏却可以控制一节代码的计算。
获得了控制代码的执行顺序（见惰性计算和非限制函数）的能力，使得新创建的语法结构与语言内建的语法结构不可区分。例如，一种Lisp 方言有 cond 而没有if ，就可以使用宏由前者定义后者。Lisp 语法的去部主要扩展，比如面向对象的CLOS 系统，可以由宏来定义

我是俄罗斯留学的,我是nokia81 设置如下（仅限诺基亚智能机）
一般得设置两个（顺序：连接名称 数据承载方式 接入点名称 用户名 提示输入密码 鉴定 主页)
1MTS Internet 分组数据 internetmtsru mts 否 （电话默认的） 普通 无
(点选项进入高级设置：网络类型：ipv4 ip：自动 dns：用户自定义（主dns：2138701 次dns：2138711） 代理服务器：无 代理端口号吗：o)
2mts internet 分组数据 internetmtsru mts 否 （电话默认的） 普通 无
(点选项进入高级设置：网络类型：ipv4 ip：自动 dns：自动 代理服务器：无 代理端口号吗：o)
一般上网选择第二个网络连接模式
其实不上手机qq一般上网动能上的去

---