# 四十二、微軟公司是如何敗北API之戰的
這陣子你應該聽過某種理論:「微軟要完蛋了。只要Linux在桌上型市場有些進 展,而web應用程序又取代桌上型系統的應用程序,這個強盛帝國就會崩潰了。」
雖然Linux的確是微軟的心頭大患,不過至少要預言這個Redmond公司滅亡還言之 過早。微軟銀行里的現金多得不得了,而且仍是非常的賺錢,還要很久很久才 可能倒。微軟可以胡搞個十年才會開始有點危險,而且你永遠不會知道他 們可能在最后一刻變身成刨冰公司。所以別這么快就看衰他們。90年代初期大 家都認為IBM徹底完蛋了,因為大型主機(mainframe)已經成為歷史!那時候 Robert X. Cringely預言主機時代會在2000年一月一日結束,屆時所有用COBOL 寫的程序都會出問題。由于原始碼都早已遺失(據稱),所以沒有人會去修正這 件程序,大家都會針對主從架構的平臺把這些程序全部重寫過。
好吧,猜猜結果如何。大型主機仍然與我們同在,2000年一月一日什么事都沒發 生,而IBM則是變身成一家巨大的老牌技術顧問公司,同時恰巧也在制造便宜塑 料電話。所以只由少數幾個數據就推斷出微軟要完蛋的理論,實在是有點夸大了。
不過大多數人并未注意到一個較不為人知的現象:微軟在戰略上最重要的寶物 Windows API要輸了。Windows與Office的利潤豐厚,幾乎貢獻微軟所有的收入, 還養活大量不賺錢或賺很少的產品線。這些賺錢產品的特權和微軟的壟斷勢力 都是以Windows API為基石。不過它對開發人員不再那么有吸引力了。生金蛋的 鵝還沒死,不過已經得了還沒人注意到的絕癥。
既然我已經說了,請容我為前一段的大言不慚和炫耀說聲抱歉。我想我看起來開 始像那些商業小報的評論主筆,喋喋不休地談論Windows API這個微軟的策略資 產。我打算在這里用幾頁的篇幅,來解釋我真正的意思并闡明我的論點。在我解 釋清楚之前請不要直接下任何結論。這會是篇很長的文章,我得解釋什么是 Windows API;我也得說明它為什么是微軟最重要的策略式資產,還要解釋它會 怎么輸掉以及輸掉這件事長期的含意。另外既然是在談大趨勢,難免也得夸大其 詞和泛泛空談啰。
## 開發者、開發者、開發者、開發者
還記得操作系統的定義嗎?它負責管理一臺計算機的資源讓應用程序能執行。大 家其實并不太在意操作系統;比較重視那些依賴操作系統的應用程序。像是文書 處理器、實時通訊、電子郵件、應付帳款管理、有Paris Hilton照片的網站等等。 操作系統本身并沒什么用。大家會買操作系統是因為上面可以執行有用的應用程 序。因此最有用的操作系統就是擁有最有用應用程序的操作系統。
由這里可以合理推出一個結論,如果你想要賣操作系統,最重要的就是讓軟件開 發者愿意替你的操作系統寫軟件。所以Steve Ballme「才會跳上舞臺大喊「開發 者、開發者、開發者、開發者。」這對微軟實在是太重要了。微軟沒有公然發放 Windows開發工具,唯一的理由就是怕不小心砍斷競爭開發工具商的生路(嗯, 是指還活著的那些)。因為有各種開發工具可以選擇,會讓他們的平臺更能吸引 開發人員。不過他們其實真的邀要發放開放工具。你可以透過他們的Empower ISV 深耕計劃,以大約375美元買到五套完整的MSDN Universal (也就是「除模擬飛行外的所有微軟產品」)。免費的.NET runtime附有命令行版本的.NET語言編譯 程序…也是免費的。現在C++編譯程序也免費了。微軟盡各種方法鼓勵開發者支 持.NET平臺,只是為了不要害死Borland這些公司才收斂一點。
## 為什么蘋果和Sun不能賣計算機
好吧,這樣說當然是有點蠢。蘋果和Sun當然可以賣計算機,但不是在最賺錢的 企業桌面計算機和家庭計算機兩個市場。蘋果的占有率低到只有個位數,而Sun 也只有自己公司的人在用。(請理解我這里談的是大趨勢,所以當我用「沒人」 等說法其實是指「少于一千萬人」。請如此類推。)
為什么呢?因為蘋果和Sun的計算機都不能執行Windows的程序,就算可以也是要 用某種昂貴的仿真模式勉強執行。記住,大家是為了要執行應用程序才買計算機 的,而Windows上好的桌面應用程序比麥金塔多太多了,所以麥金塔的用戶實在 很難當。
## 附欄「API」是什么東西?
如果你正在寫一支程序(假設是個字處理器),你想顯示選單或是寫檔案時得呼 叫操作系統替你完成,這時會用到一組每個操作系統都不相同的函數。這些函數 就叫做API,也就是操作系統(如Windows)提供給應用程序開發者(如寫字處理器 或電子表格等等的程序員)的接口。它是一組數量上千,復雜而講宄的函數和子 程序,可以讓程序員指示操作系統做些有趣的事(如顯示選單和讀寫檔案)、奇 怪的事(如把指定的日期用塞爾維亞語表示),以及非常復雜的事(比如在窗口 里顯不一個網頁)。如果你的程序使用了 Windows的API,就不能在提供不同API 呼叫的Linux上執行。有時候API做的事是差不多的。Windows軟件不能在Linux上 執行有一個重要的原因。因為想讓Windows程序在Linux上執行,就得重新實作整 個Windows API。這包括數千個復雜的函數,規模幾乎和實作Windows本身一樣大, 其中有些東西微軟用了數千個人年才做出來。如果你犯了個小錯誤或是漏了某個 應用程序需要的函數,那個應用程序就會當掉。
而這正是Windows API對微軟是極重要資產的原因。
(我知道,我知道,這時候占全世界計算機人口2.3%的麥金塔用戶,正要打開電 子郵件程序寫信我說他們多么喜愛麥金塔。再次聲明,我在談大趨勢和一般化, 所以別浪費你的時間。我知道你愛你的麥金塔,也知道它可以執行所有你需要的 東西。我愛你,你是個好人,不過你只是全部的2.3%,所以這篇文章不關你事。)
## 微軟內的兩股力量
微軟內部有兩股相對的力量,我稱之為(雖然有點諷刺意味)Raymond Chen辟營 熱MSDN雜志陣營。
Raymond Chen是微軟Windows團隊的開發人員,從1992年起就在那里了。他的網 志”The Old New Thing”里有很多詳細的技術性文章,解釋Windows里某些東西為 什么會是現在的樣子,甚至很蠢的東西其實也有著很好的理由。
看Raymond的網志時令人印象最深刻的是這些年來Windows團隊為了維持向后相 容,投入難以置信努力的故事:
由客戶觀點來看看這個情境。你買了程序X和Y還有Z,后來升級到Windows XP。現在計算機會亂 當機,而且程序Z還不能動。你會告訴朋友:「不要升級到Windows XP。它會亂當機而且跟程序Z 不兼容。」你會去查看看是不是程序X造成當機嗎?或是去查出其實程序Z用了未公開的窗口訊息 所以不會動嗎?當然不會。你只會把整盒Windows XP拿回去退費。(程序X和Y和Z都是幾個月前 買的。30天內退貨的時限已經超過,你也只能退Windows XP了。)
我最初是由熱賣游戲SimCity的某位作者聽到這些事的。他說他的程序里有只大 蟲,會在釋放內存后馬上又用到,這是個大問題,在DOS上恰巧能動,不過在 Windows就會出事,因為釋放的內存立刻就會被其他程序拿去用。Windows團隊的 測試人員測遍各種常見的應用程序,要確定是否都能正常執行,可是SimCity 一直當機。他們把這個狀況回報給Windows開發人員,開發人員就反組譯SimCity 用除錯器逐行追查找出問題,然后加上特別的程序檢查代碼檢查SimCity是否正在執 行,如栗有的話就把內存配置程序切成特殊模式,讓內存在釋放后還可以使用。
這并不是特例。Windows測試團隊非常巨大,而他們最重要的責任之一就是要保 證不管裝了什么程序,每個人都要能安然無事地升級操作系統,而且即使這些程 序做了壞事或呼叫未公開函數,或是依賴在Windows n有但n+1版修好的問題,都 必須能繼續執行。事實上如果你在registry登錄數據庫的AppCompatibility區到 處看看,就會看到一大堆要特別處理的應用程序,Windows會仿真各種舊問題和 古怪的行為讓這些程序能繼續執行。Raymond Chen寫道:「有人指控微軟在0S 升級時惡意地妨害應用程序時我會覺得很生氣。如果有任何程序不能在Windows 95執行,我會視為個人的失敗。我有很多個晚上沒睡去修正別人的程序,只是為 了讓它們能在Windows 95執行。」
很多開發人員和工程師都不同意這種作法。他們認為如果應用程序做了壞事或依 賴某些未公開的行為,應該讓它們在OS升級后直接掛掉。蘋果公司的麥金塔OS 開發人員一直都在這個陣營。這也是很少麥金塔早期的程序還能動的原因。舉例 來說,很多開發人員為了加速自己的麥金塔應用程序,會把中斷跳躍表的指標 復制出來直接呼叫,而不按正常方法使用處理器的中斷功能。雖然蘋果的官方麥 金塔程序設計圣經/ns/de Macintosh里有段技術注記寫著「你不可以這樣做」, 這些人還是照樣做了,程序會動而且跑得更快…結果等下一版操作系統出來這些 程序就完全不能動了。如果寫這些應用程序的公司因而沒了生意(大多數的確如 此),好吧兄弟,只能怪你們運氣太差了。
對照之下,由于Raymond Chen陣營的努力,我1983年在最早期IBM PC上寫的DOS 程序還能正常執行。我知道這當然不只是Raymond—個人,這是整個核心Windows API團體的工作稽神,不過Raymond用他出色的網站The Old New Thing把它公布 出來,所以我才用他的名字。
這是其中一個陣營。另一個陣營我稱之為MSDN雜志陣營,是以某一本開發人員雜 志來命名,這本雜志充滿了讓人興奮的文章,都在教你用各種在自己軟件里結 合微軟產品的神秘方法來害死自己。MSDN雜志陣營總是試圖說服你用新而復雜的外部技術,比如COM+、MSMQ、MSDE、Microsoft Office、Internet Explorer 及其組件、MSXML、DirectX (請用最新版)、Windows Media Playe「、以及 Sharepoint… Sharepoint!這個沒夜人有的東西名符其實的有一大堆壯觀的夕A 斑關聯,當你要把應用程序發行給付錢的客戶時,每個關聯都會變成大麻煩,而且沒有辦法弄好。這種事的技術性名稱叫DLL地獄。在我這里能動,為什么在那 里不會動了?
Raymond Chen陣營相信,讓開發人員寫一次程序能到處(好吧,在所有的Wi ndows 上)執行,可以讓他們更容易做事。而MSDN雜志陣營則認為要提供一些功能很 強的程序給開發人員使用,才能讓他們更輕松,前提是開發人員愿意承受難以置 信的復雜部署和安裝麻煩,更別提巨大的學習曲線了。Raymond陣營想的是強化 (consolidation)。請不要讓事情變得更糟,只要讓我們原有的東西能遂’續動就 好了。MSDN雜志陣營則是得一直生產出大量的技術,卻沒有人能跟得上。
下面是這件事要緊的原因。
## 微軟失去向后兼容的信仰
在微軟內部,MSDN雜志陣營已經贏了這場戰役。
第一個大勝利是讓Visual Basic.NET不必向后與VB 6.0相容。這是記憶中第一次 買了微軟產品的升級版后,無法安靜而完美的匯入舊魏據(也就是你用VB6寫的 程序)。這也是第一次微軟的升級版不尊重用戶用該產品之前版本所做的成果。
而且天似手還沒有塌下來,至少微軟內部沒出事。VB6開發人員極力反對,不過 反正他們也正在消失中,因為這些人大多都是企業開發人員,反正正在轉移到web 開發。真正的長期傷害就被隱藏起來了。
MSDN雜志陣營挾著這次大勝接管一切。突然間改東西變得理所當然了。IIS 6.0 用了不同的線程模型,讓某些舊應用程序不能動。我很震驚地發現用Windows Server 2003的客戶不能執行FogBugz。然后.NET 1.1不能完全向后兼容于1.0。
而現在秘密終于揭露,0S團隊也心領神會,決定不再為Windows API增加新功能 而是完全取代掉。我們被告知不要再用Win32了,現在要開始準備迎接WinFX:下 一代的Windows API。全部都不一樣了。現在依據的是用受控代碼(managed code) 的.NET、XAML、Avalon。是的,我得承認遠遠優于Win32。不過這并不是升級, 而是對過去的破壞。
Windows開發的復雜困擾了外界的開發人員,他們被微軟磨個平臺打敗了,現在 已經在發展web平臺了。在dotcom興旺初期建立了 Yahoo! Store的Paul Graham 很有力地總結:「新創公司現在有更多的理由去寫Web-based軟件,因為桌面軟 件寫起來已經不那么好玩了。現在想寫桌面軟件就要照微軟的規矩,呼叫他們的 API還要應付他們多蟲的OS。另外如果你真的寫出什么熱門的東西,可能會發現 自己只是在替微軟做市場研宄。」
微軟已經大到有太多的開發人員,這些人太沈溺于增加收益,因此他們突然決定 把每洋事徹底重做過并不:是太了不起的計劃。該死的,我們還可以做兩次啊。 舊的微軟(Raymond Chen的微軟)可能會把Avalon (新的繪圖系統)這種東西實 作成一系列的DLL,不但能在任何版本的Windows上執行,還可以和需要用到的應 用程序包在一起。并沒有任何技術上的理由不這樣做,不過微軟必須找個借口 讓你買Longhorn。他們想弄出大量的改變,就像Windows取代DOS時那么多的變 化。問題是Longhorn并沒有比Windows XP先進太多;根本不到Windows超越DOS 的那種程度。或許它的吸引力并不足讓人像對Windows那樣,為它買全新的計算 機和應用程序。好吧,或許它有這個能耐,微軟一定得讓它有,不過就我目前 所看到的實在沒什么說服力。微軟很多東西都賭錯了。舉例來說,WinFS的宣傳 是以關系數據庫方式制作文件系統,以達成搜尋功能的一種作法,卻忽略了事實 上要達成搜尋功能的真實作法就是要達成搜尋功康Ct/?e rea/ way to ma/ce searc^/ng wor/c /s by ma/c/ng searc^/ng wor/c)。不要讓我替所有檔案輸入提 示數據然后用查詢語言去搜尋。只要幫我個忙去搜尋該死游硬盤,決遽姻找至夕我 打的字符串,隨便你用全文檢索或其他W73年就有的技術。
## 自動排檔獲得最后勝利
不想把我想錯了…我認為.NET是個很偉大的開發環境,我也相信搭配XAML的 Avalon比Windows舊GUI應用程序的寫法先進許多。.NET最大的優勢就是擁有自動 化的內存管理。
我們很多人都認為1990年代最大的戰爭就是程序化程序設計與面向對象程序設 計間的戰爭,而且我們認為面向對象程序設計能讓程序員的生產力大幅提升, 我當時也是其中之一,而有些人到現在也還是這么認為。不過結果我們錯了,面 向對象程序員設計是很方便的好東西,不過并不能像它承諾地大幅提升生產力。 真正讓程序員大幅提升生產力的,其實是那些會替你自動管理內存的程序語言。 它可以是參照計數(reference counting)或垃圾收集(garbage collection); 可以是Java、Lisp、Visual Basic (連1.0版也算)、Smalltalk或是多種腳本語 言其中之一。如果你的程序語言能讓你抓一塊內存來用,又不用考慮用完后要如 何釋放,你用的就是會管理內存的程序語言,那么你的效率會遠遠超過那些使 用得明確管理內存的語言的程序員。當你聽到某些人夸耀他們的程序語言生產力 有多好時,他們的生產力可能大多是自動化內存管理所貢獻的,只是他們弄錯 原因而已。
> 附欄
>
> 為什么自動化內存管理能大幅提升生產力? 1)因為你可以寫f(g(x))卻不用擔 心要如何釋放g的傳回值,這表示你的函數可以回傳很復雜數據型態,而這樣的函 數能讓你以更高階層的抽象想法來作業。2)因為你不必花任何時間寫程序代碼去 釋放內存或追查內存漏洞(memory leak)。3)因為你不再需要小心安排函數的離 開點以確保內存都有釋放干凈。
賽車迷可能會因而寫信罵我,不過就我的經驗而言,在正常駕駛時好的自排只有 在一種狀況下會不如手排。軟件開發也是類似的:幾乎在所有的狀況下,自動化 內存管理都比手動內存管理更好,而且能讓程序員生產力提升許多。
在Windows初期要開發桌面應用程序,微軟提供兩種作法,可以寫C程序直接呼叫 Windows API并自行管理自己的內存,或者用Visual Basic并把內存交給它管理。 這也是我個人過去13年來用得最多的兩個開發環境,用到熟得不得了,而我的經 驗是Visual Basic的生產力好賽常多。我時常會寫褙局游程序,用C++呼叫 Windows API寫一次,用Visual Basic也寫一次,C++通常要花三到四倍的工作時 間。為什么呢?答案是內存管理。要了解原因最簡單的方法,就是去看任何會傳 回字符串的Windows API函數文件。仔細看看有多少篇幅在討論該字符串的內存 由誰配置,或是如何協商需要的內存數量。通常你得呼叫函數兩次,第一次告訴 它你配置了 0個字節,函數會傳回「配置內存不足」的訊息,順便還告訴你需要配置多少內存。這還是簡單的情形,如果運氣不好呼叫到的函數要傳回字符審游 審/f或是整個長度不定的結構就更麻煩了。不管如何,像開檔案寫入字符串然后 關閉檔案之類簡單的操作,直接呼叫Windows API都需要一整頁的程序代碼。在 Visual Basic類似的操作只要三行。
所以你有了這兩種程序設計的世界。每個人都斷定受控代碼的世界遠比未受控代 碼世界更優越。Visual Basic是有史以來(恐怕現在還是)賣得最好的程序語言 產品,而且開發人員在發展Windows程序時會優先選它而非C或C++。不過產品名 稱里有”Basic”這個事實卻讓硬派程序員回避,雖然它其實是個相當現代的程序 語言,有很多面向對象功能而殘留的臟東西也極少(行號和LET敘述早就不見了)。 VB的另一個問題是部署時需要附上VB runtime。這對透過調制解調器散播的共享 件是個大問題,而更糟的是VB runtime會讓其他程序員發現你的應用程序是用 (可恥的!)Visual Basic開發的。
## 一個Runtime全部搞定
接下來又出現了.NET。這是個宏大的計劃,一個要把所有臟污一次清干凈的超級 偉大一統計畫。當然它會有內存管理,也有Visual Basic不過已經是種新語言。 精神基本上還是與原Visual Basic—樣,不過改用大括號和分號等類似C的語法。 而最好的一點是這個新的Visual Basic/C合體叫做Visual C#,所以再也不用對 別人說你是一個”Basic”程序員了。所有那些可怕的Windows函數,加上它們那些 尾巴和掛入功能(hook)還有向后兼容問題與不可能弄懂的字符串回傳機制全 部一掃而空,取而代之的是個單一干凈只有一種字符串的面向對象接口。一個 Runtime全部搞定。真是漂亮。就技術面而言他們也的確成功了。.NET是個偉大 的程序設計環境,可以管理你的內存并提供一組豐富完整且一致的操作系統接口, 另外還有一組豐富而超完整又優雅的對象庫提供各種基本的操作。
不過,大家還是沒有真正大量使用.NET。
噢,當然某些人是有啦。
不過建立一個完全茲激的程序設計環境來一統Visual Basic和Windows API程序 設計的混亂,而且這個新環境并不是用一種或二種語言,而是有三種程序語言(或 許是四種嗎?),這種作法實在有點像用壓倒性的音量大喊「閉嘴!」讓兩個 小孩停止吵架。這種作法只有在電視上行得通。在真實世界里,如果你對兩個大 聲吵架的人喊「閉嘴!」,結果只會變成三個人在吵架。
(順便一提,網志聚合器格式是個神秘而充滿政治味的世界,有在注意的讀者可 以看到那里面發生的事情是一樣的。RSS已經變得支離破碎了,原因是有數個不 多的版本,規格不正確又有很多政治斗爭。有人試圖建立叫Atom的另一#游式來 消弭混亂,結果只是在RSS的眾多版本外再加一個Atom而已,規格還是不正確而 政治斗爭依舊很多。當你創造第三方案想藉以一統兩股對抗的力量時,最后只會 變成三股敵對的力量。你并不會一統什么也沒有真的修正什么。)
于是我們現在并沒有出現.NET的一統和單純,反而是擁有六重的復雜,每個人都 試圖在這團亂中找出所用的開發策略,以及是否有本錢把應用程序移植到.NET。
不管微軟的市場信息有多么一致(「只用.NET就對了?把我們當白癡啊!」), 他們大部份客戶還是在用C、C++、Visual Basic 6.0以及原本的ASP,更別提其 他那些來自別的公司的各種開發工具了。而在用.NET的都是在用ASP.NET來開發 web應用程序,只會在Windows服務器上執行并不憲要W/’ndows游客戶端系統。這 正是個關鍵點,后面寫到web時會深入探討。
## 噢,等一下,還有其他東西要出來!
現在微軟有太多的開發人員在做事,徹底重做整個Windows API還不夠看,他們 必須重做兩次。去年的PDC中他們預先發表了下一個重大的操作系統改版,這個 代號Aon^orn的系統除了其他東西之外,將會有一組代碼為Aw/on的全新使用 接口 API。這組API是運用現代計算機快速顯示硬件及實時3D成像能力重新建立的。 如果你現在正在開發Windows GUI應用程序,而且是用微軟「官方」最新最偉大 的Windows程序設計環境WinForms的話,為了支持Longhorn和Avalon兩年內就得 重來一遍了。這說明了為什么WinForms完全的難產。希望你在這上面還沒有投資 太多。Jon Udell找到一份標題為「如何在Windows Forms和Avalon間選擇?」微 軟的投影片,里頭問道:「我們為什么要在Windows Forms和Avalon間選擇一個 呢?」真是個好問題,而且還是個他找不到好答案的問題。
所以你有了 Windows API,有了 VB,現在還有.NET,雖然有多種程序語言可選,
不過不要跟任何一種牽涉太深,因為我們正在制作Avalon而你知道它只能在最 新的微軟操作系統上執行,而這個系統要等很久很久才會出現。就我個人來說 還沒空很深入的學習.NET,而我們也沒有把Fog Creek的兩套產品由傳統的ASP及 Visual Basic 6.0移植到.NET,因為投資完全不?會存濃解。以我來看這只是邊開 火邊移動的掩護行動。微軟會很樂意看到我們停止為我們的問題追蹤軟件和內 容管理軟件增加新功能,然后浪費幾個月把它們移植到別的程序開發環境上,這 個動作不會對任何一個客戶有好處,因此也不會讓我們多賣出一套軟件。這對 微軟非常好,因為他們有內容管理軟件也有問題追蹤軟件,因此他們最高興我浪 費時間空轉追逐流行,然后再浪費一兩年做Avalon的版本,而同時他們卻在自 己的相同產品上一直加新功能。完全丑■磁。
有正職的開發人員不會有時間追得上來自Redmond的所有新開發工具,因為微軟 有太多該死的員工在做開發工具!
## 這不是1990年代
微軟是在1980和1990年代長大的,當時個人計算機的成長非常的快速,每年新賣 出的計算機都超過原有的計算機數量。這也表示如果你做的產品只能給新計算機 用,即使沒有人改思你的產品,一兩年內還是可以攻下全世界的市場。這也是 Word和Excel能如此徹底地取代WordPerfect和Lotus的原因:微軟只要等下一波 硬體升級,把Windows和Word以及Excel賣給更新桌面計算機企業就好了(有些 還是第一次買計算機)。所以微軟在很多方面從來不需要學習讓現有的客戶由 第N版產品轉換到N+1版。當人們拿到新計算機時,會很樂意在新計算機上搭配微 軟所有的新東西,不過升級的意愿就低很多了。當PC產業如野火般成長時這并不 打緊。不過現在這個世界的PC已經飽和了,而且大部份的PC都用得很好。謝謝你,
微軟突然了解到最新版的東西沒那么好推了。他們想把Windows 98完全結束,結 果還在使用的人實在太多,于是他們只好承諾會對那個老爺系統再多支持幾年。
這些勇敢的新策略(.NET、Longhorn、Avalon之類的玩意)試圖建立一組,新API 把大家鎖住。問題是大家都還在用1998時買來還很好用的計算機,這種策略是 不太行不通的。即使Longhorn照計劃在2006推出(我根本不相信),大概還得多 等幾年,擁有的人數才會多到能考慮作為開發平臺。開發者們才不會聽從微軟 那些多重人格失調的軟件開發建議呢!
## 進入Web
我不知道自己怎么能寫這么久還沒提到Web。每個開發人員在計劃新軟件應用程 序時都要做一個選擇,他們可以做成web版本,也可以做一個在PC上執行的”rich client”應用程序。基本的優缺點很單純:Web應用程序比較容易部署,而rich client應用程序反應較快所以使用界面比較有趣。
Web應用程序比較容易部署是因為不需要安裝。Web應用程序的安裝等于只是在網 址列輸入一個URL。今天我要安裝Google的新電郵程式,只要按Alt+D、gmail, 再按Ct「l+Ente「就好了。兼容性問題還有與其他軟件相沖的問題都少太多了。產 品所有的用戶都在用相同的版本,所以你永遠不必支持各種舊版本。你可以用 任何喜歡的開發環境,因為只要裝在自己的服務器上執行就好了。在這個星/發上 幾乎每臺還可以用的計算機,自然而然都能用你的應用程序。而你客戶的數據也 很理所當然能用于這星球上任何一臺還可以的計算機上。
不過這必須付出使用接口的平順作為代價。下面是幾個web應用程序做不好的例子:
1. 創造一個快速繪圖的程序
2. 寫一個能標示紅色波浪底線的實時拼寫檢查
3. 在使用者按到瀏覽器的關閉盒時,警告使用者將會遺失其工作成果
4. 不必連到服務器來回溝通一遍,就能依據使用者的變更來更新小部份的顯 示,
5. 建立一個不需鼠標的快捷鍵盤驅動接口
6. 讓大家在沒有連上Internet時繼續作業
這些都不算大問題,其中有些很快就會被聰明的Javascript開發人員解決。有兩 個新的web應用程序Gmail以及Oddpost (都是電郵程序)做得相當不錯,避開或 完全解決了部份的問題。另外使用者似乎也不在意UI小問題或web接口的緩慢。 不知道為什么,不管我如何努力宣揚rich client會,呃,比較豐富,我認識的 人幾乎全都對web式的電子郵件軟件十分滿意。
所以Web使用接口已經有80分了,就算不靠新的web瀏覽器還是有機會達成95分。 這對大多數人來說已經夠好了,當然對開發人員來說也夠了,而且他們也已經實 際把幾乎所有重要的新應用程序都寫成web應用程序。
這表示微軟的API突然間已經不那么重要了。Web#不憲要W/ndows。
微軟并不是沒注意到這件事發生。他們當然知道,所以他們在局勢浮現時就猛踩 煞車。他們不再在未來計劃里承諾像HTA和DHTML這類的新技術。Internet Explore「團隊似乎也消失了;他們有好幾年似乎完全沒有動作。微軟不可能容許 DHTML變得比現在更好,這對他們的核心事業rich client來說實在太危險了。微 軟最近的重大思想基因(memo)是:「微軟把公司放未來齡在rich c/ient上。」 這句話會遍布Longhorn相關的每頁簡報上。來自Avalon團隊的Joe Beda說道: 「Avalon (大體上還有Longhorn)是微軟的基石。這句話表不我們相信你桌面的 威力,能夠完成各種了不起的東西,而且是不可或許的。我們正在持續投入桌面, 我們認為這會是個好地方,而且我們希望自己能啟動一波振奮…」
問題是現在已經太遲了。
## 我本身對這有一點點難過
我本身對這真的有一點點難過。對我來說Web是很不錯,不過Web應用程序的使用 接口既爛又慢也不一致,就日常使用來說實在是倒退一大步。我愛我的rich c l ient應用程序,如果日常使用的應用程序(Visual Stud io、CityDesk、Outlook、Corel PhotoPaint、QuickBooks)得改用web版本我會瘋掉。不過這正是開發人 員正在進行的事。沒有人(再提一次,我的意思是「少于一千萬人」)想再用 Windows API開發程序了。創投業也因為害怕微軟的競爭,不會再投資Windows 應用程序了。而大部份使用者似乎并不像我一樣,那么在意不方便的Web使用介 面。
以下是關鍵所在:我注意到(而且也和求才業的朋友確認)紐約市這里會C++和 COM程序設計的Windows API程序員年收入約十三萬美元,而一般用可控代碼語言 (Java、PHP、Perl、甚至ASP.NET)的普通web程序員年收入是八萬美元。這可 是很大的差別,而當我和從事微軟顧問服務的朋友談到這事情時,他們承認微 軟已經失去整個世代的開發人員了。要花十三萬雇一個有COM經驗的人,是因為 過去約八年來沒有人自找麻煩去學COM程序設計,所以你得找個很資深的人來 (通常都已經晉身管理階層),說服他們再做個普通程序員去處理(上帝救救我) marshalling、 monikers、apartment thread i ng、aggregate、tearoff,還 W其 他一百萬件基本上只有Don Dox會的東西。事實上連Don Box都無法忍受再回來看 這些東西。
雖然我很不想這樣說,不過大量的開發人員早就移到web而且拒絕再回來。大部 份的.NET開發人員都是用ASP.NET針對微軟的web伺服器進行開發。ASP.NET很出 色。我從事web開發已經十年,而它真的是比其他工具先進一個世代。不過ASP.NET 是服務器技術,所以客戶端可以用任意的桌面系統。何況ASP.NET還能在Linux 上用Mono執行得相當好呢。
這些東西沒有一個對微軟有利,對微軟得力于API權勢的利益也一樣。新的API 是HTML,而能讓HTML唱歌的人將會是應用程序開發市場的新贏家。
- 第一部分 位與字節:編程實踐點滴
- 一、語言的選擇
- 二、深入底層
- 三、joel測試:改進代碼的12個步驟
- 四、每一位軟件開發人員必須、絕對要至少具備UNICODE 與字符集知識(沒有任何例外!)
- 五、輕松寫就功能規格說明書 - 第1節:為什么煩心?
- 六、輕松寫就功能規格說明書 - 第2節:什么是規格說明書?
- 七、輕松寫就功能規格說明書 - 第3節:但是……如何?
- 八、輕松寫就功能規格說明書 - 第4節:技巧
- 九、輕松制訂軟件進度表
- 十、每日連編是朋友
- 十一、難伺候的故障修復
- 十二、軟件開發中的5個世界
- 十三、稿紙原型開發
- 十四、不要被太空架構師所嚇倒
- 十五、開火與運動
- 十六、人員技能
- 十七、源于計算機學科的三個錯誤思想
- 十八、二元文化
- 十九、自動獲取用戶故障報表
- 第二部分 開發人員的管理
- 二十、面試游擊指南
- 二十一、重金激勵害多利少
- 二十、二不配備測試人員的五個首要(錯誤)原因
- 二十三、任務換人有害無益
- 二十四、絕不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序設計界的LordPalmerston
- 二十八、評測
- 第三部分 Joel對常態問題的遐想
- 二十九、RickChapman解讀愚昧
- 三十、在這個國家狗是干什么的? 我們有多么天真?
- 三十一、作為哼哈二將,只管去做事
- 三十二、兩個故事
- 三十三、巨無霸麥當勞與天才廚師JamieOliver
- 三十四、沒有什么像IT看起來那么簡單
- 三十五、提防非自主開發綜合癥
- 三十六、策略I:BEN&JERRY公司與AMAZON
- 三十七、策略II:雞與蛋問題
- 三十八、策略III:讓我回去!
- 三十九、策略IV:大件與80/20神話
- 四十、策略V:公開源代碼的經濟因素
- 四十一、墨菲法則肆掠的禮拜
- 四十二、微軟公司是如何敗北API之戰的
- 第四部分 對.NET稍多的評說
- 四十三、微軟精神失常了
- 四十四、我們的.NET對策
- 四十五、請問,我可以使用連接程序嗎