微軟軟件開發技術二十年回顧

2019-11-17 04:43:14

字體：大中小

來源：轉載

供稿：網友

　　今年11月，微軟新一代的操作系統 Vista即將正式發布，它將會極大地改變原有的Windows編程機制。近20年來，隨著技術和應用的變化、發展，微軟的開發技術也歷經變遷。隨著微軟下一代開發平臺vista即將發布，微軟會把開發者引向何方? 　　自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軟件的核心技術，例如屏幕抓詞、垃圾郵件過濾、軟件界面高級定制等。 QQread.com 推出各大專業服務器評測 linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器三、 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框架出現以前基于組件的分布式應用程序戰略框架結構。 QQread.com 推出各大專業服務器評測 Linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器六、 .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)。 QQread.com 推出各大專業服務器評測 Linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器七、 .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框架又會締造出怎樣的奇跡，請試目以待。

上一篇：免費午餐已經結束——軟件向并發靠攏

下一篇：Java對各種文件的操作詳解