Windows 8與開發(fā)者夢境的輪回
我們曾經(jīng)報道過，微軟稱Windows 8 觸摸友好的沉浸模式不會使用基于.NET的開發(fā)平臺而轉(zhuǎn)向HTML5和javascript。然而在過去十年里，微軟曾大力推崇前者。微軟公司并未給予進(jìn)一步的評論。但是對于開發(fā)者，這個問題顯得尤為關(guān)切——我怎么利用現(xiàn)有的技能和經(jīng)驗去開發(fā)新的應(yīng)用呢？微軟似乎并不打算在9月份的BUILD大會之前透露任何信息。
推薦專題：Windows 8新聞直通車
不過事情可能并不是開發(fā)者想的那么糟糕。Windows8的早前的里程碑版本已經(jīng)被泄露到互聯(lián)網(wǎng)上，已經(jīng)有了很多關(guān)于這個系統(tǒng)如何工作的研究。盡管官方的口風(fēng)很緊，還是有一些細(xì)枝末節(jié)的信息從雷蒙德大院里跑了出來。就目前看來，Windows 8其實還是相當(dāng)不錯的。有跡象表明，Windows 8 將解很多決長久困擾Windows軟件開發(fā)的問題。如果微軟能夠最終搞定一切，那么Windows 8 將是一個重大的發(fā)布版本，達(dá)成本應(yīng)由Windows Longhorn(譯注，即Windows Vista)完成的目標(biāo)。
回顧歷史
在我們開始討論微軟想拿Windows 8做什么之前，知道一些背景是必要的。要理解為什么Windows 8將會是一個重大的革新，必須先理清現(xiàn)狀。
在2002年引入.NET之前，Windows 應(yīng)用程序主要通過兩種方式編寫。大型應(yīng)用——像Office，Photoshop或者Netscape瀏覽器——傾向于使用Win32 API和C++。Win32是一個龐大的編程接口，涵蓋方方面面。熟知的如圖形和用戶界面創(chuàng)建、網(wǎng)絡(luò)通信和文件系統(tǒng)訪問。還有比較生僻的備份、網(wǎng)絡(luò)配置和安全相關(guān)的一些東西。
Win32的確大而全，但是有些事情它并不擅長甚至無法完成。例如，雖然Win32提供了數(shù)據(jù)庫訪問的接口——事實上只有幾個——但使用純粹Win32來寫數(shù)據(jù)庫應(yīng)用是相當(dāng)繁瑣的。更嚴(yán)重的問題是，Win32提供了創(chuàng)建圖形用戶界面的所需的所有基本工具，但它并沒有簡化工作。例如，在用戶界面布局方面它就毫無作為。每個按鈕、文本框和工具條都必須由開發(fā)者來指定位置，而且如果你想要它們的位置隨窗口大小變化而移動，你得包辦所有的事情。有很多庫被開發(fā)出來作為開發(fā)者和操作系統(tǒng)之間的中間層，包括微軟自己的MFC，以此來簡化工作。但是很多時候，為了達(dá)到想要的效果還是不得不回歸Win32。
（.NET之前）開發(fā)Windows應(yīng)用的另一主要方式則是Visual Basic。Visual Basic能夠讓某些任務(wù)變得相當(dāng)簡單——特別是數(shù)據(jù)庫交互和用戶界面創(chuàng)建——并因此在商業(yè)領(lǐng)域占據(jù)一席之地。相當(dāng)多的商業(yè)程序都只是簡單的從數(shù)據(jù)庫取出數(shù)據(jù)，展示給用戶然后給用戶一個表格來增加數(shù)據(jù)。在處理這檔子事情上，Visual Basic很優(yōu)秀。但是要做其他的事情Visual Basic就不是那么回事了。Visual Basic 對直接調(diào)用Win32 API 缺乏有效的支持，特別是那些需要用到特殊結(jié)構(gòu)（譯注：原文這里有鏈接指出是函數(shù)指針）的API。而且Visual Basic也缺乏對面向?qū)ο笳Z義的支持，它只是“基于對象”的。
.NET的出現(xiàn)改變了整個格局。.NET如同VB一般簡單易用，但是不像VB那么弱。和VB一樣，.NET擁有很好的工具來構(gòu)建用戶界面和與數(shù)據(jù)庫交互，因此很適合用來編寫商業(yè)應(yīng)用。而和VB不同的是，.NET有一種簡單，但是稍顯笨拙，的方法來訪問Win32 API。因此，.NET平臺很快就吸引了商業(yè)應(yīng)用開發(fā)者，并且一些新的商業(yè)項目也在使用它。
Longhorn 之夢
Windows XP 在.NET前一年發(fā)布，因此毫不奇怪沒有用到.NET技術(shù)。但是微軟在2003年10月的PDC大會上宣布，事情將隨著Windows Longhorn的發(fā)布而改變。Longhorn 將把.NET整合到Windows平臺核心中去。一時周知.NET FX(FX代表Framework)將讓位于WinFX，即基于同樣技術(shù)的"Windows Framework"。除此之外，Windows Longhorn將帶來一種全新的方式來編寫用戶界面，代碼名為Avalon（譯注：即WPF），完全現(xiàn)代、基于矢量和硬件加速的框架。Windows系統(tǒng)中用戶可見的程序——資源管理器、計算器等——將使用WinFX技術(shù)。.NET將被視作編寫Windows應(yīng)用的最佳方式。而Win32則繼續(xù)存在以保持向下兼容，但不會再變動。
Longhorn本應(yīng)是舊式Windows應(yīng)用開發(fā)的終結(jié)和現(xiàn)代Windows應(yīng)用開發(fā)新紀(jì)元的開端，而不是因為10年或者15年前的設(shè)計決定而遭閹割。
如我們所知道的那樣，Longhorn系統(tǒng)沒有給我們帶來這些。Longhorn工程變得極其龐大、不可管理而最終崩潰。而與此同時，Longhorn的基石Windows XP卻在被黑客們肆意凌辱。微軟不得不投入大量資源讓W(xué)indows XP和Windows Server 2003的安全性可以讓人接受——最終的結(jié)果就是Windows XP SP2和Windows Server 2003 SP1——然后再開始下一代操作系統(tǒng)的開發(fā)，最終就是Windows Vista發(fā)布。然后一切重新開始。
這其中最大的杯具之一就是.NET。Windows Vista盡管在某些方面有重大意義，但是它完全拋棄了WinFX的概念。Avalon最終發(fā)布——即WPF——但是只是作為操作系統(tǒng)的一個插件，而不是核心的一部分。Windows Vista 和 Windows 7中唯一顯著基于.NET平臺的程序是Media Center（然而它甚至沒有用到WPF）。其他的一切東西都是老一套的Win32。Win32 API也被更新和擴(kuò)充。相當(dāng)數(shù)量的低層功能被添加到Win32來支持GUI的變化，諸如任務(wù)欄縮略圖和AERO玻璃主題。而這些新的東西在WPF里都不能很好的工作。
導(dǎo)致微軟作出這種決定的因素有若干。部分是因為這個決定只是一個權(quán)宜之計，沒有時間用.NET來重寫所有的東西。更重要的原因則可能是微軟內(nèi)部陣營的分裂。Windows來自于Win陣營，.NET來自于Dev陣營，然后還有服務(wù)器業(yè)務(wù)等等其他陣營?？赡苣阏J(rèn)為這些小組的目標(biāo)是一致的，但是實際不然。當(dāng)然，這些小組之間沒有什么冤仇，只是各自有不同的重點。
曲折的開發(fā)
各個小組重點的不同在當(dāng)時影響重大。舉個例子，WPF只能被.NET程序使用，而且只能配套C#或VB.NET使用。而整個API，由上至下都是原生的C++代碼，將現(xiàn)有程序移植到WPF工作量巨大。計劃之初，所有的開發(fā)都打算用.NET進(jìn)行，但是漸漸計劃成變化，原生代碼還是成了首選的開發(fā)環(huán)境。這的確是個很大的問題。微軟沒辦法使用全新的、基于矢量、分辨率無關(guān)和硬件加速的WPF來構(gòu)建任何操作系統(tǒng)核心程序。
其它的差異則是各小組目標(biāo)不同導(dǎo)致。Dev陣營的首要任務(wù)是創(chuàng)建一個可信賴的開發(fā)平臺，這意味著他們要添加核心功能、開發(fā)工具和庫（例如Silverlight）。Win陣營的首要任務(wù)則是前面提到過的C++兼容性，系統(tǒng)的健壯性及解決一些技術(shù)問題。所有的目標(biāo)都是合理的，但是Dev陣營沒有配合Win陣營，沒有給Win陣營需要的東西。最終的結(jié)果就是Win陣營的管理部門看.NET很不爽，欣然忽略它。
.NET在Windows Vista 之后的幾個版本對境況有所改進(jìn)，但是C++的問題還是沒有解決。傷害再所難免，Win陣營于是對Dev陣營不滿，無視他們的工作。Windows 7和它前輩Windows Vista一樣，只有Media Center這個程序使用.NET。Windows 7新的API全部是原生的C++ API，沒有好的辦法從.NET程序訪問。而原生C++代碼也無法訪問分辨率無關(guān)、基于矢量、硬件加速的框架來構(gòu)建用戶界面。
Windows 8 將終結(jié)一切。
【編輯推薦】
