自Windows 1.0问世到今年11月份，微软Windows操作系统已经走过了它辉煌的二十一年。沧海桑田一瞬间，让我们再次追随Windows的踪迹，了解微软核心技术发展史，评析她当时所处的位置并展望其今后的发展趋势。
一、 操作系统篇Win16 时代（1985～1995）
1985年11月，微软公司正式发布了第一代窗口式多任务系统──Windows 1.0，代表了MS-DOS时代将逐渐终结，Windows王朝正式拉开了序幕。该操作系统的推出标志着PC机开始进入了图形用户界面（GUI）时代。 1987年12月9日，Windows 2.0发布，但这个版本依然没有获得用户的广泛认同。
1990年5月22日，微软推出Windows 3.0，由于在界面/人性化/内存管理多方面的巨大改进，终于获得用户的认同。1992年4月，windows 3.1发布，在最初发布的两个月内，销售量就超过了一百万份；至此，微软公司的资本积累/研究开发进入良性循环。随后，首次发布了Windows 3.2中文版本。不论是图形操作系统的稳定性还是友好性，Windows 3.X都有了巨大的改进。Windows 3.X在界面人性化和内存管理上有了较大的改进：具备了模拟32位操作系统的功能，图片显示效果大有长进，对当时最先进的386处理器有良好的支持。另 外，这个系统提供的对虚拟设备驱动（VxD）的支持，极大改善了系统的可扩展性。
1992年10月，Windows for Workgroups 3.1发布，标识微软公司吹响了进军企业服务器市场的号角。1993年，Windows NT 3.1发布，它是第一款真正面向服务器市场的产品。值得注意的是，在这个版本中，微软把主要的API改为32位的版本。
Win32 时代（1995～2005）
1995年8月24日，微软推出具有里程碑意义的Windows 95。这是微软开发的第一个独立的32位操作系统，并实现真正意义上图形用户界面。从此，个人电脑进入了普及化阶段。
另外，Windows 95是单用户多任务操作系统，它能够在同一个时间片中处理多个任务，充分利用了CPU的资源空间，并提高了应用程序的响应能力。同时，Windows 95还集成了网络功能和即插即用功能。
1996年8月，Windows NT 4.0发布，增加了许多了管理方面的特性，稳定性进一步提高。同年11月，针对各种嵌入式系统和产品设计的Windows CE 1.0发布。这标识着微软的战线从桌面系统杀到了服务器市场，又转攻到嵌入式行业；至此，微软帝国的雏形已基本形成。1997年11月，Windows CE 2.0发布。
1998年6月25日，Windows 98发布；与Internet的紧密集成是Windows 98最重要的特性。1999年6月10日，Windows 98 SE发布，以内置方式提供了Internet Explorer 5、Windows Netmeeting 3、Internet Connection Sharing、对DVD-ROM和对USB的支持。
Windows 2000（Windows NT 5.0）Professional于2000年年初发布，它是第一个基于NT技术的纯32位的Windows操作系统，实现了真正意义上的多用户。从此， Windows操作系统进入商业用户市场。Windows 2000包含新的NTFS文件系统、EFS文件加密、增强硬件支持等新特性。
2001年10月25日，Windows家族中极具开创性的版本Windows XP面世。Windows XP具有全新的图形用户界面，整合了更多更实用的功能：防火墙，即时通讯，媒体播放器，增强的即插即用特性。Windows XP具有全面为中国用户开发的中文技术及特性，能够全面满足中国用户在数字时代的需求。
2003年4月，Windows Server 2003发布。这个版本对活动目录、组策略操作和管理、磁盘管理等面向服务器的功能作了较大改进，对.net技术的完善支持进一步扩展了服务器的应用范围。
2004年9月微软发布Windows XP SP2。
Windows Vista(2006.11 ～）
今年
11月，微软新一代的操作系统Vista即将正式发布，它将会极大地改变原有的Windows编程机制。
Vista生成器最终将跟以前的
Win32 API进行分离，取而代之的是可管理的WinFX，而WinFX将成为微软继DOS、Win16、Win32之后推出的第四代API。据外刊报道，以前利用Win32 API开发的软件，在微软承诺的维护期之后将不能运行。
Win32 API历经
Windows 95到XP，受到众多应用软件开发商的追捧。过去，无论是最常用的字处理、电子邮件、即时通讯软件，还是专业的杀毒、ERP软件等，大都利用微软提供的 API进行开发。微软提供了近7.8万个Windows API以及大量的辅助开发工具，这种友好的服务极大地鼓励了无数程序员在微软平台上创造各种应用软件。但另一方面，微软又通过API“控制”了软件的开 发，帮助自己成就了霸主地位。如今，在Win32 API逐渐淡出人们的视野后，新一代的API还能如微软设想的那样延续Win32时代的辉煌吗？
微软已经看到了这些威胁。所以， Vista的发行中配带了全新的WinFX。同时，微软的WinFX已经 把繁杂的Win32 API减少到8千个左右，在.NET框架下采用可管理代码编程模式，进一步减轻程序员的负担。另外，WinFX还加入全新的图形用户界面子系统 Avalon、文件子系统WinFS和网络服务通讯子系统Indigo，使得开发环境更加友好。时势所趋，正如Win32取代DOS和Win16一样， Win32 API也终将被WinFX所替代，而成为新操作系统中的“遗留物”。
据估计，在一段时间内，程序员还可以继续使用
Win32 API开发应用程序，但利用WinFX开发的程序并不向下兼容，只能在Vista平台上运行。另一方面，Vista操作系统带来的变化和WinFX开发者 框架迟早将会刺激开发者转向.NET框架。因此，作为Windows开发人员，应当尽早掌握.NET框架可管理编码的技能以便应对在2008年全面使用 WinFX时可能出现的种种问题。
二、 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软件的核心技术，例如屏幕抓词、垃圾邮件 过滤、软件界面高级定制等。
图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书写控件时会有很大的优越性。
四、 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框架又会缔造出怎样的奇迹，请试目以待。
二、 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的顶级类层次结构。
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框架又会缔造出怎样的奇迹，请试目以待。
本文转自朱先忠老师51CTO博客，原文链接： http://blog.51cto.com/zhuxianzhong/59900
，如需转载请自行联系原作者
