微軟著名工程師、Windows Server設計師
“我們在1988年11月作為壹個小組壹起到來。”Lucovsky告訴我們,並強調NT團隊的第壹個任務是獲取壹臺開發機器,後來是25MHz的386 PC機,具有110 MB硬盤和13 MB內存。“它們價高質次。”他笑著說。在頭兩周裏,除了用Word編寫原始設計文檔外,沒有什麽重大的開發活動。
最後,到了開始寫代碼的時候了。“大約在1988年12月中旬,我們核查了最初的代碼,”Lucovsky說道,“到1989年1月份時,它只具有壹個在Intel i860模擬器上引導的非常基本的系統。”實際上,這是NT名稱的真正來由,據Lucovsky透露,“New Technology”這個說法是在該產品取得市場成功後加上去的。“起初,我們將NT的運行目標定位於Intel i860 (代碼號為N-Ten),壹個令人生厭的RISC處理器。由於我們沒有壹臺i860機器,我們不得不使用i860模擬器。這就是我們稱之為NT的原因,因為它工作在‘N-Ten’上。”
1989年4月,新指定的NT團隊有了在模擬器上運行的基本系統內核。“我們5個來自DEC的家夥和來自微軟的Steve Wood壹起開始工作,”Lucovsky說,“我們這個小組保持了很長時間,經過壹個夏季,我們開始考慮:創建壹個操作系統究竟有多難?我們制定了壹個用18個月完成NT的計劃。但是我們忘記了壹些重要的因素,比如用戶模式、網絡等等。”
1989年之後,NT小組開始擴充。他們增加了正式的網絡團隊,和壹個擴充的獨立安全性團隊,他們先前負責文件系統和本地化開發。“在第壹年中我們增加到50個人,”Lucovsky說,“在這壹年中,我們最終得到了第壹臺i860原型機,因此我們可以替換模擬器。我們開始查看上下文切換次數,試圖找到壹個方法讓它工作得更好。我們幾乎立即就發現i860將永遠無法工作。因此,我們開始著眼於MIPS體系,另壹種RISC設計。”
1989年12月,NT團隊決定放棄i860並用MIPS R3000芯片替換。“我們在真實硬件上無休止地引導NT,這樣持續了兩三個月,”Lucovsky告訴我們,“當我們移植到MIPS上之後,我們得到了回報,我們將NT設計為可方便移植的,它幾乎立即就開始工作了。這種改變沒有帶來太多的痛苦。”
從這時起,NT團隊迅速擴大,來自微軟不同陣營的人現在都加入進來。當壹種使用圖形的新風格被創立後,圖形團隊迅速增長。他們也開始將NT轉向當時的主流PC處理器Intel i386,Lucovsky解釋了他們最初沒有定位到i386的原因。“我們暫時避開386是為了避免局限於該體系,我們不想采用壹個不可移植的構想。”他說如果在壹開始就定位於Intel系列芯片,則他們在早期就可以有壹個較高性能的系統,但是那樣就會長久地傷害NT,並且將很難跟上新體系結構的發展,比如最近基於64位Itanium芯片的Windows Server 2003。
NT變成Windows NT
“我們的核心體系非常堅固,所以我們才能使NT從適應1990年的386-25,壹直發展到今天適應嵌入式設備、64路64位多處理器的機器和以1000美元為單位的刀片式服務器。”
——David Thompson
微軟副總裁、Windows Server產品組
“在1990年的春天,我們的MIPS版本繼續曲折前進,同時我們開始狂熱地開發386的版本,”Lucovs說道,“這是另壹個巨大突破。”那壹年5月,微軟發布了Windows 3.0,立即受到了全世界的關註。Windows由於其基於PC的圖形功能而取得了非凡的成功。“我們開始研究Windows 3.0並且自問‘如果用32位的Windows版本替換OS/2將會怎樣呢?’”Lucovsky又甩出壹個更深層次的問題:“Steve Wood、Scott Ludwig、壹個圖形工程師組的人以及我本人,我們4個家夥研究了16位的Windows API,並研究如何將其延伸到32位。我們花了壹個月完成了壹半的API集合,然後把它交給100位設計評估者,看看他們的想法。”
新的API最終命名為Win32,關鍵的壹點是,盡管它是壹個新的API,但是它看上去和運行起來都與16位Windows API相似,這使得開發人員可以很容易地將程序移植到新系統上。“我們使得16位程序可以非常容易地移植到NT上,”Lucovsky說,“並且這些程序將得益於NT的獨特功能,比如更大的尋址空間。我們也增加了許多16位版本中所沒有的API。我們增加了主流的新功能,使它成為壹個完整的操作系統API,但我們使用了Windows程序員所熟悉的風格。”
這在微軟內部立即引起了反響。“當他們看到它是如此易用時,立刻就喜歡上了它,”Lucovsky說,“它基於Windows而不是OS/2,它使用了壹種完全不同的編程模式。”然而,替換OS/2產品,將NT變成壹個32位的Windows版本,帶來了新的課題,其中並不完全是技術問題。微軟不得不獲取ISV和OEM審批,當然也要將這個改變通知IBM。“我們對IBM做了壹個ISV預覽,足足有20多頁,然後我們說:‘看,這就是我們要做的。’開始他們以為Win32不過是OS/2的壹個迷人綽號,可是接下來妳可以看看他們的臉色:‘等壹等,這不是OS/2!’”
對OS/2的拋棄永遠地傷害了兩家公司的感情。“但是我們執行了審批,並且開始了進程,”Lucovsky說道,“因此我們選擇了Win32運行NT,替代了OS/2子系統。”他說,那壹刻,這個產品變成了Windows NT。
NT的模塊式結構為這個改變提供了便利。“應該感謝我們的微內核體系,它減弱了內核與應用程序環境的關聯程度,比如POSIX和Win32。我們不必改變內核,也不必從頭開始編程,”Lucovsky告訴我們,“日程計劃的內容不必更改,我們在兩周的時間裏運行命令行應用程序。這時是1990年9月。”
Thompson詳細闡述了NT基礎的重要性:“我們的核心體系非常堅固,所以我們才能使NT從適應1990年的386-25,壹直發展到今天適應嵌入式設備、64路64位多處理器的機器和以1000美元為單位的刀片式服務器。我們可以為其提供全系列的服務。”
1990年9月是Windows NT真正的轉折點,同時也是Dave Thompson加入NT團隊的時間,他先前領導微軟的Lanman for OS/2 3.1高級開發團隊。“我們經受了轉變,”Thompson告訴我們,“我們的隊伍從28人增加到300人。我們有了第壹個真正的產品計劃。”
NT大事記
1988年10月31日:David Cutler抵達微軟
1988年11月:NT項目開始運作
1993年7月27日:Windows NT 3.1發售
1994年9月21日:Windows NT 3.5發售
1995年5月30日:Windows NT 3.51發售
1996年7月31日:Windows NT 4.0發售
2000年2月17日:Windows 2000發售
2001年10月25日:Windows XP發售
2003年4月24日:Windows Server 2003發售
1993年7月,Windows NT的第壹個版本Windows NT 3.1發布了,版本號的命名與當時的16位Windows產品壹致。那個版本的NT有桌面和服務器兩個版本,並使用域形式的分布式安全機制。從那時起,NT團隊開始連續地發布產品,所有的開發都基於相同的底層代碼。
第二個發布版本Windows NT 3.5(代碼名為Daytona)在1994年9月投放市場。“Daytona是壹個非常有價值的項目,”Thompson說,“我們把焦點放在尺寸和性能上,放在對3.1的功能進行完善上。Daytona有了顯著的改進和增強。”Daytona最初的主題是尺寸、性能、壓縮以及Netware兼容性。其中的兩個想法具有當時的時代特征:1990年以前,雙倍壓縮是壹個熱門話題,因為當時硬盤很昂貴;Netware也是當時占優勢的網絡操作系統。“我們最終停止了壓縮項目,”Thompson說,“但是Netware兼容性部分是具有戰略意義的。Novell對NT桌面系統是矛盾的,他們不知道自己是否希望創建壹個客戶端。我們提供了幫助,但是他們保持混亂,並且……我們做出了自己的。它是壹個更好的Netware客戶端,被用戶使用了幾年,盡管最後他們也做了壹個。這個客戶端使NT桌面系統可以成為Netware的客戶端,因為Netware當時是市場上的主流服務器系統。否則我們的NT桌面將賣不出去。”
Daytona也得益於新的編譯器技術,它使微軟可以壓縮代碼尺寸,也使NT桌面成為真正的低端系統。“結果是可統計的,”Thompson說。
Windows NT 3.51是配合Power PC發布的,因為它是圍繞Power PC設計的,在3.5版本中沒有提供對Power PC的支持。由於IBM經常延遲Power PC芯片組的發布,導致了壹個孤立的NT發布。“NT 3.51的發布非常不值,”Thompson說,與對Daytona的評價正相反。“Daytona完成後,為了等待IBM完成Power PC,我們大概用了9個月進行錯誤修正。但是正因為如此,NT 3.51是非常穩固的,我們的客戶喜歡它。”NT 3.51最終於1995年5月開始銷售。
接下來的Windows NT 4.0,開始采用Shell Update Release(SUR),這是另壹個得益於NT模塊化結構的挑戰性任務。“我們希望創建壹個使用95外殼的桌面,但是它使用NT技術。”Lucovsky告訴我們,“我們最終遷移了Win32 GUI組件,並使其作為進程內驅動。性能是受影響的壹個方面,在壹個不同的進程中運行這個API會帶來問題。因此將代碼遷移到作為運行時的相同上下文,將解決大量問題。我們不必為GDI和USER做死鎖檢測。它是壹個重大工作,但它解決了大量令人頭疼的問題。”NT 4.0於1996年7月投放市場,它是NT系列產品的壹個分水嶺。
Windows擠掉NT
接下來的發布中,Windows NT放棄了NT這個名字,成為簡單的Windows。Thompson說這個決定來自市場隊伍。“壹個家夥從Windows市場部調到NT市場部,並且說我們將在所有地方使用Windows這個名字。起初,改變名稱令我們所有人都感覺不舒服,因為NT有很好的聲譽。但是由於伴隨Windows 2000壹起推出的可靠性,人們開始談論究竟Windows 2000比舊的NT要好多少,盡管它們基於相同的體系結構。所以這是壹個偶然事件,Windows 2000沒有壹個代碼名是因為Jim Allchin不喜歡。”Thompson說。
自從完成Windows 2000之後,Windows隊伍所作的最大決定是在Whistler產品中,分別發布客戶端和服務器,即現在的Windows XP和Windows Server 2003。“這使得我們將焦點集中於服務器客戶,他們現在更多地要求穩固性,”Thompson告訴我們,“桌面軟件將按照PC制造者的銷售周期同步發售。這與服務器周期不同。”
David Thompson,微軟公司Windows服務器事業部副總裁。1990年加入微軟公司,在轉入Windows NT項目組之前,領導和負責公司的LAN Manager for OS/2項目。在開發Windows NT期間,Thompson領導的開發團隊在NT聯網子系統方面作出優異貢獻,不僅保證了該產品可以與微軟產品協調工作,而且保持了與其他公司產品的兼容性。
Mark Lucovsky,微軟公司著名軟件工程師和服務器構架設計師。1988年與Dave Cutler壹起加入微軟公司。他們都是前Digital Equipment Corporation(DEC)公司的傑出軟件設計師。Lucovsky憑借在早期將NT從基於OS/2的系統遷移到32位Windows應用程序過程中的傑出貢獻和技術敏銳,受到眾多工程師的敬佩。
——Mark Lucovsky
NT系列操作系統從Windows NT發展到Windows 2000、XP,到現在的Windows Server 2003,盡管細節部分在戲劇性地改變,但有壹個關鍵元素壹直沒有改變,這就是build操作。在微軟內部,事實上每壹天至少有壹個Windows產品被編譯或生成為可執行代碼,開發隊伍可以立即對它進行測試。對於Windows Server 2003,這個過程在微軟公司的26號大樓中達到了極致,在那裏,成排的PC和CD復制機始終處於幾個工程師連續監視下。
“回想早年的日子,我們開始只有6個人,”Mark Lucovsky告訴我們,“現在Windows團隊有5000個成員,加上額外的5000合作夥伴,生產了超過5000萬行的Windows Server 2003代碼。讓所有人員遵從統壹的領導制造代碼是壹個巨大的任務。生成他們的工作結果,編譯並連接為可執行程序或其他組件,最後組成壹個Windows的CD,這個過程持續12到13小時,每壹天都在進行。這是曾經嘗試過的最大的軟件工程任務。沒有其他軟件項目可與之相比。”幾乎在每壹天,微軟編譯所有的東西——全部的5000萬行代碼,“我們始終在改進開發環境。”Lucovsky強調。
“當我們開動機器時,我們編譯全部的內容,”他說,“我們必須能夠在任何時間點再生這個系統。開發者Check-In代碼,我們按下按鈕並產生系統。我們應該能夠在未來3年內,使用不同的工具、編譯器以及腳本再生系統。”
David Thompson詳細介紹了這個過程。“關鍵在於我們整年地生成系統,並從三個方面推進它,”他說,“首先是產品本身,其次是我們設計產品的方法,第三是我們與廣大客戶的交互途徑。產品的進化是完美的,我們現在使用了全新的源碼控制(Source code control)系統。我們從已有的技術開始,Mark Lucovsky親自領導了新系統的開發,我們每天都會生成壹個階段性(Staged)Build,這些階段性Build將形成最後完整的Build。我們在持續發展的同時維持了穩定性——我們了解我們每天的進度。”
吃掉它:微軟端出狗食
“有壹天我收到了85個Check-In,那是我們當時可以有的最大數量,現在我們每天可以接收1000個以上,這是壹個完全不同的比例,盡管現在白板實際上是電子的——基於Web的。”
——David Thompson
Lucovsky回憶了壹些往事,第壹個NT原型是在他的辦公室裏生成的,然後他發出壹封郵件告訴NT團隊,NT Build準備就緒。於是NT團隊的50多個人將“吃掉他們自己的狗食”,在他們自己的系統上測試這個Build並進行壓力測試。“我們過去只是圍繞這個Build工作並寫下我們發現的問題,”Lucovsky說,“這就是為什麽它是pre-NT 3.51,現在我們有7個Build實驗室。Dave Thompson有自己的Build實驗室,覆蓋1200個人。主要的Build實驗室進行官方Build,它每天進出上千人。貫穿大學的主幹服務器自動地將通知傳送到各個地點。”
Thompson說:“起初,我們可以每天在固定時間Check-In代碼然後停止開發,接著開始生成新系統。最終,我們將團隊增加到85人,並將過程系列化以進行更多的控制。我們都為Dave Cutler工作,他掌管生成實驗室大約有壹周,然後要求每個人在實驗室白板上寫下自己的Check-In請求,並使其成為強制模式。我也在那裏待了壹段時間,有壹天我收到了85個Check-In,那是我們當時可以有的最大數量,現在我們每天可以接收1000個以上。這是壹個完全不同的比例。盡管現在白板實際上是電子的——基於Web的。”
“其他軟件項目無法與之相比,”Lucovsky說,“但是有壹件事是不變的,就是生成Windows所需的時間。不管是該產品的哪壹代,都需要12小時來編譯並連接系統。”隨著生產過程能力的增長,Windows也隨之增大,開發過程變得更為復雜,因此微軟在每天的生成中進行更多的代碼檢查。“Build實驗室的CPU連續不停地工作12個小時,從Windows 2000以後我們適應了這個過程。現在,我們將源代碼彼此分隔開來並使用新的生成環境。這是壹個多機環境,使我們可以更快地生產。但是由於所有的代碼都要進行分析,因此仍然需要12小時。”
Thompson告訴我們,對於NT團隊來說,完全“吞掉”他們自己的代碼是必需的,並且是與微軟的自然條件並存的。“回想當年,這是我們壹直在做的事之壹,今天當我們談起email程序時都感到很可笑。當時第壹次在PC上運行NT時,我們的Email程序無法工作,因為它是壹個DOS程序,而我們當時還沒有DOS兼容模式。所以我們將內部的Email程序WizMail改造成Win32的,這樣我們就可以只在NT系統上工作了。”
Thompson補充道:“當妳被迫自己使用系統時,如果妳看到了漏洞以及性能問題,妳必須找到那個負責人並要求他修正問題。”Thompson加入NT團隊時,他的壹個主要職責就是將文件服務賦予NT,這樣它就可以被用作源代碼服務器。它需要的信任,特別是自NT使用NTFS文件系統之後。“網絡組非常認真地工作,”他說,“同時確保其做好內部布署的準備。壹旦它開始實施,就不可能回頭。很顯然,如果文件服務失敗,那將是壹場災難。所以那是我們的非常時期。”
後來,隨著Windows NT 4.0開發的結束,Thompson的隊伍采用了活動目錄(AD),這是微軟的第壹個目錄服務,它於1996年在Professional Developers Conference(PDC)公開發表。“在AD之前,我們在基礎構造中使用NT域,”他說,“轉向AD更為復雜。我們很早就部署了AD,先是我們的團隊,然後是更廣泛的Windows小組。在1999年4月,我們在雷德蒙大學正式使用了AD。”
Thompson說,微軟謹慎地在公司的其他級別實施AD,大學在上壹年使用Windows Server 2003實現了多森林AD拓撲。“對所有的基礎服務器,我們總是在內部進行完全的部署,然後推廣到JDP(Joint Development Partners),他們進行測試,並在250個使用場景中將其產品化。我們收集錯誤報告、功能反饋以及復雜的測試環境,以考驗產品。”
2002年夏天,Windows Server 2003(RC1)的可靠性達到了99.995%。2002年11月,Microsoft.com網站完全采用Windows Server 2003(RC2)部署。“在內部大量使用並接近客戶是關鍵,”Thompson告訴我,“我們現在的產品更加成熟。我們不僅僅售出盒裝產品,還售出範圍廣泛的補充工具、產品、服務以及文檔。”Thompson還談到當前Outlook 11、Exchange Server 2003(Titanium)和Windows Server 2003團隊工作結合得更為緊密,以滿足最終客戶的需求。過去這些產品經常是獨立開發,互不相幹的。
關註產品服務
Lucovsky補充道:“這些年服務也走向成熟,我們為每壹個產品做了大量的工作,提供正確的混合服務包、熱修復、產品開發分支、beta以及JDP客戶。”(在下壹節裏有更多關於開發分支的信息)
“我們確實延長了對產品進行服務的時間。”Thompson說,因為微軟售出壹個服務器產品時,客戶可能使用長達10年之久。Volume或mainstream在過去的7年中提供服務,但是公司壹直在研究提供全程升級和修正的方法。首先,微軟必須確保錯誤修正被應用到所有開發分支。“我們在快速定位安全性缺陷上的工作,意味著我們現在可以更積極主動地發布熱修復,”Thompson強調,“同樣,它使服務包更具彈性,壹個可以像傳遞修正包壹樣傳遞新功能的方法。但是客戶使其更明確,他們只希望得到錯誤修正。盡管這導致了壹個有趣的問題:究竟什麽才算是錯誤?壹個缺失的功能是嗎?客戶經常有他們自己的觀點。不過NT 4 SP3是最後壹個包含主要新功能的服務包。”
影響主幹服務的壹個方面是微軟必須為近期產品的每壹次改變保留測試環境。這意味著Windows 2000的最終版或“黃金”版是壹個分支,Windows 2000 SP1是另壹個,Windows 2000 SP2又是壹個,依此類推。“完全消化對於提供服務包也是很重要的。我們在自己的IT組織保留了壹個獨立的Windows 2000基礎生成品,這樣我們可以隨時生成Windows 2000系統,並在產品環境中測試,”Thompson說,“這樣做代價昂貴,但是值得。”
熱修復被精簡成只修正壹個特定問題,並且不會影響系統的其他部分。Thompson說壹般情況下,客戶只有在受到相關問題影響時,才應用壹個熱修復,但是安全性修正則是另壹回事。“我們希望所有的客戶安裝安全性修正,因此我們對它們非常謹慎,並且做了足夠的測試。它們壹般是可分發的發布(Deployable Releases,GDRs),就像服務包壹樣。”
主幹、樹和分支
正如前面提到的,不同的Windows版本需要壹系列的產品代碼分叉路口,在那裏不同的Windows產品從“主幹”開發中“分支”出去。因此每壹次Windows發行會產生至少兩個不同的版本,在本文撰寫時,Windows Server 2003和Longhorn正在同時開發。因為Windows Server 2003是從XP分離的,因此這個服務器產品基本構建於XP之上。在未來幾年要超越XP的客戶端發行版本Longhorn,實際上是從服務器代碼分支基礎生成的,而不是您所期望的XP。
Lucovsky告訴我們:“這個機制是自覺的,我們對當前Windows版本有壹個主要代碼分支,它成為熱修復和下壹個服務包的源碼基礎。壹旦我們推出壹個服務包,它就成為壹個新的分支,這樣我們就有了兩個分支,用來測試熱修復和服務包。我們不能告訴客戶說安裝SP1並進行熱修復。這在每壹次Windows發行中延續,因此會有兩三個服務包,許多熱修復以及許多安全性修正。其中每壹個都是被管理的,是壹個5000萬行代碼的集合。這是壹個巨大課題。”
另外,對於每壹個開發的主要分支,微軟也有大約16個分支團隊,並允許他們在公***主線上獨立地並行工作。每壹個團隊掌握壹個完整的生成實驗室環境,用來生成包含他們所做更改的完整發行版本,各團隊定期地將經測試的更改整合到主要分支中,這樣他們可以互相交流已測試的工作。
將錯誤消滅在作戰室
“如果有人不在作戰室,我會批評他們,我專踢笨蛋。”
——Todd Wanke
微軟產品主管、Windows Server發行管理處
項目最令人激動的地方是在作戰室,在那裏戰鬥團隊每周5到6天,每天會面2到3次。現在Windows Server進入了開發的最後階段。“戰鬥團隊每天對項目進展進行度量並做出報告。”Thompson告訴我們,說作戰室令人震驚毫不誇張。“現在壹切都是自動的,但是想當初我們剛來時,都要將我們的工作寫在紙上。那時作戰室有大約15到20個人。現在大不相同了。”
Todd Wanke掌管Windows Server 2003的作戰室,我們驚訝地發現他非常迷人。但是在作戰室工作時,他是壹個鐵腕人物,他到處發號施令,產品組成員只能耐心地忍受殘酷的會議進程。
作戰室的工作狀況是這樣的,每天早上9:30,來自不同Windows Server 2003功能團隊的代表進行會面並篩選錯誤。他們排隊進入26號大樓的3243房間,它的門上標著手寫的“Argument Clinic”。在房子中央有壹個大會議桌,但是許多參與者都站著,房子裏總是塞滿了人。我們參加戰鬥團隊會議的那壹天,這是第壹次允許外界人員進入Windows Server的聖地,也是整個NT和Windows開發歷史中的第二次,那壹天團隊討論了大約50個錯誤,大部分是簡單的商標錯誤,盡管那天不允許我們參與壹些特殊錯誤的討論(因此我們很晚才進入,最重大的論題是在最後壹刻將Windows .NET Server 2003改名為Windows Server 2003)。
每壹個錯誤都被記入壹個遞增的錯誤跟蹤系統,伴隨著令人眼花的信息,包括錯誤是如何發現的、是否有客戶受到了影響,以及錯誤被根本解決的完整歷史。Wanke快速地審閱錯誤,並叫來相關功能團隊的成員,讓他們說明修正進展的情況。例如,如果IIS存在壹個或多個錯誤,則IIS團隊的代表需要列席,他不僅要說明錯誤,還要說明客戶是否會受影響、修正對系統其他部分的影響,以及修正將在多長時間內完成。在開發過程的最後,如果錯誤不是十分嚴重,它將被“傳”給下壹個Windows發行版本——Longhorn。