The InfoTech 100

二、 API篇
  随着Windows操作系统开始占据主导地位，开发Windows平台下的应用程序成为人们的需要。当然，这也为传统的DOS程序员提供了一种新的编程方法—一种不受设备限制并由事件驱动的编程方法。另一方面，Windows GUI的开发迫使传统的DOS程序员的编程方法发生了变化。当时，大多数DOS软件以过程方式编写，即一个函数调用另一个函数，主程序始终处于控制之下，而事件驱动的编程模式使得程序放弃它们的全部控制权，等待外部事件发生并对外部事件作出响应，以便将它们的函数全部提供给最终用户。结果是，今天的Win32（当然包括早期的Win16）GUI程序的结构仍然与1987年时的结构相同。图1展示了Windows GUI应用程序的基本结构。
                          
                                            图1.Windows GUI应用程序的基本结构。

  其中，每一个程序都包含一个进入点、主窗口创建、一个消息循环和主窗口撤消。此外，都有一个函数与主窗口过程相关联，称为窗口过程，它包含用于处理系统事件和应用事件（如键盘输入、鼠标移动和点击、定时器报警、菜单选择和按钮点击）的代码。
   在Windows程序设计初期，Windows程序员所能使用的编程工具唯有API（应用程序编程接口）函数，这些函数是Windows提供给应用程序与操作系统的接口，它们犹如“积木块”一样，可以搭建出各种界面丰富功能灵活的应用程序。所以，可以认为API函数是构筑整个Windows框架的基石，在它的下面是Windows的操作系统核心，而它的上面则是各种功能的Windows应用程序。当时，因为缺乏良好的Windows编程平台，程序员想编写具有Windows风格的软件，必须借助API，API也因此而被赋予至高无上的地位。相应地，程序员还必须熟记一大堆常用的API函数，而且还得对Windows操作系统有深入的了解。
  随着软件技术的不断发展，在Windows平台上很快出现了很多优秀的可视化编程环境（诸如VB、VC ++、DELPHI等），程序员可以采用“即见即所得”的编程方式来开发具有精美用户界面和功能强大的应用程序。但实际上，要真正开发出更灵活、更实用、更具效率的应用程序，必然要涉及到直接的API函数调用；对于比较复杂和特殊的功能来说，使用类库和控件往往难以实现，这时就需要采用API函数来实现。
【提示】关于钩子技术。
   Windows操作系统是建立在事件驱动机制之上的，系统各部分之间的沟通也都是通过消息的相互传递而实现的。但在通常情况下，应用程序只能处理来自进程内部的消息或是从其他进程发过来的消息，如果需要对在进程外传递的消息进行拦截处理就必须采取一种被称为HOOK（钩子）的技术。钩子是Windows操作系统中非常重要的一种系统接口，用它可以轻松截获并处理在其他应用程序之间传递的消息，并由此可以完成一些普通应用程序难以实现的特殊功能。钩子的本质是一段用以处理系统消息的程序，通过系统调用，将其挂入到系统。值得注意的是，钩子技术成为许多种Windows软件的核心技术，例如屏幕抓词、垃圾邮件过滤、软件界面高级定制等。

三、 MFC篇
Windows API是面向过程的接口，因此对于当时的编程技术来说，它是完美无缺的。但是，随着人们逐渐使用C＋＋进行Windows程序的开发，迫切需要建立与Windows API的面向对象包装的接口。1992年，微软将Windows API开发成为它的应用程序框架（AFX），后来该产品又演变成为目前的微软基础类库（MFC）产品。下图2展示了MFC的顶级类层次结构。
    

图2.MFC的类层次结构。

  MFC为使用C＋＋开发Windows GUI应用程序提供了一个十分全面的基础框架，它对以前的API进行了面向对象的科学包装，大大简化和加快了程序的开发。
  Win95推出后出现在Visual C++ 4中的新版本的MFC 4.0使这个框架达到辉煌时期，在4.2版本时达到鼎盛。
  MFC框架中引入了一种适应当时开发需求的典型的文档-视图机制，从而大大简化了程序开发。当然，要掌握这些框架结构绝非一日之功，其中还涉及到部分COM及大量的宏技术。也正由于这些方面，导致了业界对MFC的褒贬不一。但正如其它微软技术一样，这只能进一步促进微软继续改进这种技术。几十年的技术积累已经奠定了MFC的生存基础，即使Windows的Vista发布，MFC也不可能退出Windows的舞台。事实上，Vista之后的Visual Studio.NET仍将MFC作为一个重要的组成部分，在今年的Visual Studio.NET 2005中，MFC在C++中的位置依然如故。MFC的未来，应该不必担心，只要你深入考察.NET类库，你会发现，MFC的许多思想机制正悄然进入.NET。

  新版的Visual C++.NET中MFC已经支持.NET开发了，而且MFC与ATL的协作更趋于和谐。如今你可以在Visual C++.NET中综合应用MFC、ATL与.NET库三者来开发应用程序，从而进一步增强C++开发的威力。

  【补注】ATL框架与WTL框架
  ATL即“ActiveX模板库”。它不能单独工作，是设计与Visual C++ V4.2，V5.0，V6.0一起工作的。
MFC和ATL都可以用来开发ActiveX控件。事实上，两者都支持各种开发向导和强有力的帮助类和模板，从而使控件的开发尽量简单。而且，这两种框架各有千秋。简言之，如果你相当熟悉MFC的各种机制而且是在创建庞大而成熟的图形应用程序本地控件或服务器控件，那么使用MFC书写控件时会有很大的优越性。

  然而，用MFC建立的控件在执行时要求相应的MFC DLL支持，相应地导致体积庞大。如果在控件的规模成问题时，则可以考虑 使用另一种方法－ATL活动模板库。

  在建立轻量级控件（几乎或根本没有用户界面要求的COM或DCOM服务器）时，ATL方法是MFC方法的替代方法。ATL在建立COM组件时使用了模板机制，这个框架对许多标准的COM接口提供了大量的模板。事实上，ATL根本不需要任何类型的运行时刻服务—由于以C++模板为基础，所以ATL对于外部库根本没有链接依赖性。因此，基于ATL的组件要比等价的基于MFC的控件占用的资源少。

  WTL框架，作为ATL的扩展，也是由ATL小组开发的，包含在微软于2000年1月发布的开发平台SDK包中，虽然微软没有正式支持。WTL通过提供一个用于编写Win32应用程序和控件的轻量级的框架、一些特殊的视图、GDI对象和实用的类来扩展ATL窗口类。WTL的目标是成为最好和最简单的实现基于Win32和ATL的应用程序、服务器和控件的方法。

四、 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对象。

五、 Windows DNA篇
  微软的Windows分布式因特网应用体系（简称Windows DNA）是微软创建新一代高适应性商业解决方案的框架，它使公司能够充分地挖掘数字神经系统的优点。Windows DNA是在.NET平台出现之前在微软平台上进行技术开发的大环境，要利用微软的组件技术OLE、COM、DCOM、MTS、COM+进行开发，就不能不了解这个Windows环境下的软件体系结构。Windows DNA是第一个将互联网、客户/服务器和用于计算的PC模型结合并集成在一起的为新一代分布式计算方案而设计的应用软件体系结构。下图4展示了微软创建的Windows DNA的系统架构。由图中可见，Windows DNA使用了一系列的服务来完成它的架构。使用Windows DNA模型，用户可建造一个能在任何网络上实现的、可伸缩的多层应用软件。
               
 
                                                                       图4.Windows DNA服务架构。
  因为Windows DNA应用软件深深地利用了集成的Windows平台服务，因此，公司可以把精力集中于实现业务方案，而并不是成为一个系统集成商。

  作为总结，以下简要列出微软在开发Windows DNA结构时的指导原则：
 无须折衷的网络计算
 交互操作能力
 真正的集成
 更低的花费
 快速跟近市场

   因为Windows DNA是基于COM和开放的Internet标准的，所以发展商可以使用任何语言或工具来生成可兼容的应用程序。COM提供了一个现代的、独立于语言的对象模型，它为应用程序提供了与结构的所有层进行交互操作的标准方式。通过COM，发展商通过可插入的软件单元能够扩展应用程序的任何部分，这些软件单元可由C++，Visual Basic,Java或者其它语言写成。总之，Windows DNA实际上是微软的.NET框架出现以前基于组件的分布式应用程序战略框架结构。

六、 .NET框架篇
  .NET是微软自从发布Windows 3.0以来最为激动人心的新技术，是微软战略上为下一个十年对服务器和桌面软件工程的第一步，是微软的一场世纪大豪赌。对于.NET，微软的定义是，“用于构架、配置、运行网络服务及其他应用程序的开发环境。该平台包括三个主要部分：公共语言运行时、框架类和ASP.NET。”

  .NET框架是微软公司继Windows DNA以来的新的开发平台。基于这个新的框架，以前在DNA中暴露出来的缺陷有望得到解决。另一方面，.NET并没有完全抛弃WINDOWS DNA，实际上它是WINDOWS DNA的继续和发展。如今的.NET不仅有一套明确的技术规范，还提供了一系列的支持产品，例如编译器、类库甚至最终的用户程序。如Windows.NET是操作系统平台、.NET框架是运行环境、.NET企业服务器为产品服务器、Visual Studio.NET为编程平台。

  .NET框架是以一种类似于Java系统的虚拟机方式运行和管理的编程平台，通过公共语言运行时刻为基础，支持多种语言（C#、VB.NET、C++、Python 等）的开发。下图5展示了.NET的整体框架结构。
                      
                                            图5..NET体系结构。
  下面的图6则从另一个角度展示了公共语言运行库和类库与应用程序之间以及与整个系统之间的关系。注意，该插图还展示了托管代码如何在更大的结构内运行。
                          
 
                         图6..NET公共语言运行库与类库、应用程序及整个系统之间关系示意图。
  .NET框架具有两个主要组件：公共语言运行库和.NET框架类库。公共语言运行库是.NET框架的基础。您可以将运行库看作一个在执行时管理代码的代理，它提供内存管理、线程管理和远程处理等核心服务，并且还强制实施严格的类型安全以及可提高安全性和可靠性的其他形式的代码准确性。事实上，代码管理的概念是运行库的基本原则。以运行库为目标的代码称为托管代码，而不以运行库为目标的代码称为非托管代码。.NET框架的另一个主要组件是类库，它是一个综合性的面向对象的可重用类型集合，您可以使用它开发多种应用程序，这些应用程序包括传统的命令行或图形用户界面(GUI)应用程序，也包括基于ASP.NET所提供的最新的应用程序（如Web窗体和XML Web服务）。

  .NET框架可由非托管组件承载，这些组件将公共语言运行库加载到它们的进程中并启动托管代码的执行，从而创建一个可以同时利用托管和非托管功能的软件环境。.NET框架不但提供若干个运行库宿主，而且还支持第三方运行库宿主的开发。
【补注】.NET框架简史
  .NET框架1.0（完整版本号1.0.3705），系最初的.NET构架，发行于2002年。它也是第一个微软Visual Studio.NET的发行版的一部分（Visual Studio.NET 2002）。
  .NET框架1.1（完整版本号1.1.4322），这是首个主要的.NET框架升级版本，发行于2003年，它也是第二个微软Visual Studio.NET版本的一部分（Visual Studio.NET 2003）。它也是首个Windows Server 2003内置的.NET框架版本。这个框架新增功能有：
• 内建了对移动ASP.NET控件的支持，现在已经集成到框架的内部。
• 安全方面的变更—使得Windows窗体代码以可靠的行为执行，从而可以在互联网环境内安全运行，并且加入了ASP.NET应用程序的代码安全访问功能。
• 内建了对ODBC和Oracle数据库的支持，现在已经集成到框架的内部。
• .NET Compact框架—这是一个用于智能设备（例如 PocketPC或者SmartPhone）的.NET框架的子集。
• 对IPv6的支持。
• 大量的API变更。
.NET框架2.0（完整版本号2.0.50727.42），发行于2005年10月27日。重大改进有：
• 大量的API变更。
• 一个新的API让需要管理一个.NET运行库实例的非.NET的应用程序可以做到这点。这个新的API对.NET运行库的各种功能（如多线程、内存分配、代码载入等）均提供了很好的控制。
  .NET框架3.0（曾用名WinFX），将随Windows Vista一同发布。这个框架依然使用.NET框架2.0版本的CLR(公共语言运行时)，并加入了适应未来软件发展方向的4个框架：Windows描述基础(WPF)、Windows通信基础(WCF)、Windows工作流基础(WWF)和Windows CardSpace(WCS)。

七、 .NET框架3.0
   这个最新框架将与即将发行的Windows Vista绑定发行。这个新式框架的侧重点在于，进一步拓宽.NET方案的应用范围。
.NET 3.0与1.x和2.0.NET框架存在一些不同之处。前两个框架专注于允许众多不同的语言与同一类库CLR进行通讯。CLR，从.NET 1.0中开始引入并在.NET 2.0中得到增强，它基于一个相对简单的概念进行工作：通用语言运行时刻模型能够执行任何运行.NET框架的系统中的代码。下图7展示了.NET 3.0框架的栈式框架结构。
                           
                                         图7..NET 3.0框架结构。
从总体来看，.NET 3.0框架并没有改进现有技术，而是引入了四种适应未来发展的基本新技术：
 Windows描述基础(WPF)
 Windows通信基础(WCF)
 Windows工作流基础(WWF)
 Windows CardSpace(WCS)
这其中的每一种技术都将成为开发者基于新一代操作系统及.NET平台用来实施新方案的基础。

  其中，WPF无可争辩地成为四个新式基础类集中最为重要的。这主要是由于两点：一致性WPF方案；新式的名为XAML的XML标准编程语言。

  首先，WPF为基于ASP.NET框架进行Web开发提供了一种一致的方案来构建编程模型，并且支持使用更为丰富的控件和设计技术来开发Windows程序。一个开发出来的单个WPF程序最终能够被发行到桌面，Web以及智能设备等多种环境下。
其次，WPF中创新性引入了一种名为XAML的XML标准编程语言。开发人员利用它能够控制对象的布局。从表面上看，这种语言似乎与Flash极为相似，其实二者之间存在相当的不同。Flash是一个成熟的、可控制的、独立于操作系统的封闭式框架。而相比之下，WPF允许你与操作系统及其它.NET框架技术进行集成。总之，二者服务于不同的市场需求但又存在一些“边缘交叉”。
在这个“网络即是一切”的社会里，Windows通信基础(WCF)显得极为重要。这个编程模型把web服务、.NET远程技术、分布式事务和消息队列统一到单个面向服务的编程模型中，从而实现真正意义上的分布式计算。

  Windows工作流基础(WWF)是一种定义、执行和管理工作流的微软技术。工作流由一系列的活动组成；开发者能够编写他们自己的域特定的活动，然后把它们应用于工作流中。.NET框架3.0/Windows工作流基础还提供了一组涉及若干控制流构建方面的通用目的的活动。值得注意的是，这个框架了还包括了许多Visual Studio 2005扩展（可视化工作流设计器、支持用户调试工作流的可视化调试器、工作流编译系统）。总之，借助于WWF，新一代应用程序开发过程的流程控制方面将得到极大的改善。
最后，Windows CardSpace（WCS）为程序开发中一直令人头疼的认证问题上提供了一种新的解决方案。不同于以前的方案，现在，微软使用CardSpace实现了一种几乎是全新的安全设计尝试，其基本原理依据“任何用户都能够创建并且共享他的或她的唯一的身份”。

  总之，WCS有望改变你到一个应用程序（基于Web、手机或桌面程序）的认证方式，从而极有助于保护用户的私有数据。
【补注】
  第一，构建.NET 3.0解决方案的主要工具仍是Visual Studio。第二，.NET框架并非操作系统本身。因此，NET 1.x和2.0和3.0都被设计可以运行于Windows XP、Windows 2003/R2和Windows Vista等系统之上。

八、 总结
  回顾微软Windows二十一年核心技术发展史，不由不令人感概万千。微软成就其帝国霸业的原因多种，但仅从其核心开发技术看来，战略前瞻性是这个软件巨人长盛不衰的最重要原因之一。从无到有，从不完善到完善，无一不显露出这种端倪。如今，微软帝国传奇依然。在今后这个由众多IT巨擘支持下的JAVA时代，在这个Linux大旗麾下的开源时代，在这个“无网而不胜”的时代，微软的Window Vista及其核心.NET框架又会缔造出怎样的奇迹，请试目以待。