微軟如何輸掉API戰爭
作者：周思博 (Joel Spolsky)
譯：Paul May 梅普華
Sunday, June 13, 2004
屬於Joel on Software, http://www.joelonsoftware.com
這陣子你應該聽過某種理論：「微軟要完蛋了。只要Linux在桌上型市場有些進展，而web應用程式又取代桌上型系統的應用程式，這個強盛帝國就會崩潰了。」
雖然Linux的確是微軟的心頭大患，不過至少要預言這個雷蒙公司滅亡還言之過早。微軟銀行裡的現金多得不得了，而且仍是非常的賺錢，還要很久很久才可能倒。微軟可以胡搞個十年才會開始有點危險，而且你永遠不會知道……他們可能在最後一刻變身成刨冰公司。所以別這麼快就看衰他們。90年代初期大家都認為IBM徹底完蛋了，因為大型主機(mainframe)已經成為歷史！那時候Robert X. Cringely預言主機時代會在2000年一月一日結束，屆時所有用COBOL寫的程式都會出問題。由於原始碼都早已遺失(據稱)，所以沒有人會去修正這件程式，大家都會針對主從架構的平台把這些程式全部重寫過。
好吧，猜猜結果如何。大型主機仍然與我們同在，2000年一月一日什麼事都沒發生，而IBM則是變身成一家巨大的老牌技術顧問公司，同時恰巧也在製造便宜塑膠電話 (http://www.google.com/froogle?q=ibm+cordless+telephone&btnG=Search+Froogle)。所以只由少數幾個資料就推斷出微軟要完蛋的理論，實在是有點誇大了。
不過大多數人並未注意到一個較不為人知的現象：微軟在戰略上最重要的寶物Windows API要輸了。Windows與Office的利潤豐厚，幾乎貢獻微軟所有的收入，還養活大量不賺錢或賺很少的產品線。這些賺錢產品的特權和微軟的壟斷勢力都是以Windows API為基石。不過它對開發人員不再那麼有吸引力了。生金蛋的鵝還沒死，不過已經得了還沒人注意到的絕症。
既然我已經說了，請容我為前一段的大言不慚和炫耀說聲抱歉。我想我看起來開始像那些商業小報的評論主筆，喋喋不休地談論Windows API這個微軟的策略資產。我打算在這裡用幾頁的篇幅，來解釋我真正的意思並闡明我的論點。在我解釋清楚之前請不要直接下任何結論。這會是篇很長的文章，我得解釋什麼是Windows API；我也得說明它為什麼是微軟最重要的策略式資產，還要解釋它會怎麼輸掉以及輸掉這件事長期的含意。另外既然是在談大趨勢，難免也得誇大其詞和泛泛空談囉。
開發者、開發者、開發者、開發者
還記得作業系統的定義嗎？它負責管理一台電腦的資源讓應用程式能執行。大家其實並不太在意作業系統；比較重視那些依賴作業系統的應用程式。像是文書處理器、即時通訊、電子郵件、應付帳款管理、有Paris Hilton照片的網站等等。作業系統本身並沒什麼用。大家會買作業系統是因為上面可以執行有用的應用程式。因此最有用的作業系統就是擁有最有用應用程式的作業系統。
由這裡可以合理推出一個結論，如果你想要賣作業系統，最重要的就是讓軟體開發者願意替你的作業系統寫軟體。所以Steve Ballmer才會跳上舞台 (http://www.ntk.net/ballmer/mirrors.html)大喊「開發者、開發者、開發者、開發者。」這對微軟實在是太重要了。微軟沒有公然發放Windows開發工具，唯一的理由就是怕不小心砍斷競爭開發工具商的生路（嗯，是指還活著的那些）。因為有各種開發工具可以選擇，會讓他們的平台更能吸引開發人員。不過他們其實真的想要發放開放工具。你可以透過他們的Empower ISV (http://members.microsoft.com/partner/competency/isvcomp/empower/default.aspx)深耕計劃，以大約375美元買到五套完整的MSDN Universal（也就是「除模擬飛行外的所有微軟產品」）。免費的.NET runtime附有命令列版本的.NET語言編譯器...也是免費的。現在C++編譯器也免費 (http://msdn.microsoft.com/visualc/vctoolkit2003/)了。微軟盡各種方法鼓勵開發者支持.NET平台，只是為了不要害死Borland這些公司才收斂一點。
為什麼蘋果和Sun不能賣電腦
好吧，這樣說當然是有點蠢。蘋果和Sun當然可以賣電腦，但不是在最賺錢的企業桌上型電腦和家用電腦兩個市場。蘋果的佔有率低到只有個位數，而Sun也只有自己公司的人在用。（請理解我這裡談的是大趨勢，所以當我用「沒人」等說法其實是指「少於一千萬人」。請如此類推。）
為什麼呢？因為蘋果和Sun的電腦都不能執行Windows的程式，就算可以也是要用某種昂貴的模擬模式勉強執行。記住，大家是為了要執行應用程式才買電腦的，而Windows上好的桌面應用程式比麥金塔多太多了，所以麥金塔的用戶實在很難當。
|
附欄「API」是什麼東西？
如果你正在寫一支程式（假設是個文書處理器），你想顯示選單或是寫檔案時得呼叫作業系統替你完成，這時會用到一組每個作業系統都不相同的函數。這些函數就叫做API，也就是作業系統(如Windows)提供給應用程式開發者（如寫文書處理器或試算表等等的程式師）的介面。它是一組數量上千，複雜而講究的函數和副程式，可以讓程式師指示作業系統做些有趣的事（如顯示選單和讀寫檔案）、奇怪的事（如把指定的日期用塞爾維亞語表示），以及非常複雜的事（比如在視窗裡顯示一個網頁）。如果你的程式使用了Windows的API，就不能在提供不同API呼叫的Linux上執行。有時候API做的事是差不多的。Windows軟體不能在Linux上執行有一個重要的原因。因為想讓Windows程式在Linux上執行，就得重新實作 (http://www.winehq.com/)整個Windows API。這包括數千個複雜的函數，規模幾乎和實作Windows本身一樣大，其中有些東西微軟用了數千個人年才做出來。如果你犯了個小錯誤或是漏了某個應用程式需要的函數，那個應用程式就會當掉。 |
而這正是Windows API對微軟是極重要資產的原因。
（我知道，我知道，這時候佔全世界電腦人口2.3%的麥金塔用戶，正要打開電子郵件程式寫信我說他們多麼喜愛麥金塔。再次聲明，我在談大趨勢和一般化，所以別浪費你的時間。我知道你愛你的麥金塔，也知道它可以執行所有你需要的東西。我愛你，你是個好人，不過你只是全部的2.3%，所以這篇文章不關你事。）
微軟內的兩股力量
微軟內部有兩股相對的力量，我稱之為（雖然有點諷刺意味）Raymond Chen陣營和MSDN雜誌陣營。
Raymond Chen是微軟Windows團隊的開發人員，從1992年起就在那裡了。他的網誌"The Old New Thing (http://weblogs.asp.net/oldnewthing/)"裡有很多詳細的技術性文章，解釋Windows裡某些東西為什麼會是現在的樣子，甚至很蠢的東西其實也有著很好的理由。
看Raymond的網誌時令人印象最深刻的是這些年來Windows團隊為了維持向後相容，投入難以置信努力 (http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx)的故事 (http://weblogs.asp.net/oldnewthing/archive/2003/12/23/45481.aspx)：
由客戶觀點來看看這個情境。你買了程式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寫道 (http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx)：「有人指控微軟在OS升級時惡意地妨害應用程式時我會覺得很生氣。如果有任何程式不能在Windows 95執行，我會視為個人的失敗。我有很多個晚上沒睡去修正別人的程式，只是為了讓它們能在Windows 95執行。」
很多開發人員和工程師都不同意這種作法。他們認為如果應用程式做了壞事或依賴某些未公開的行為，應該讓它們在OS升級後直接掛掉。蘋果公司的麥金塔OS開發人員一直都在這個陣營。這也是很少麥金塔早期的程式還能動的原因。舉例來說，很多開發人員為了加速自己的麥金塔應用程式，會把中斷跳躍表的指標複製出來直接呼叫，而不按正常方法使用處理器的中斷功能。雖然蘋果的官方麥金塔程式設計聖經Inside Macintosh裡有段技術註記寫著「你不可以這樣做」，這些人還是照樣做了，程式會動而且跑得更快...結果等下一版作業系統出來這些程式就完全不能動了。如果寫這些應用程式的公司因而沒了生意（大多數的確如此），好吧兄弟，只能怪你們運氣太差了。
對照之下，由於Raymond Chen陣營的努力，我1983年在最早期IBM PC上寫的DOS程式還能正常執行。我知道這當然不只是Raymond一個人，這是整個核心Windows API團體的工作精神，不過Raymond用他出色的網站The Old New Thing (http://weblogs.asp.net/oldnewthing/)把它公佈出來，所以我才用他的名字。
這是其中一個陣營。另一個陣營我稱之為MSDN雜誌陣營，是以某一本開發人員雜誌來命名，這本雜誌充滿了讓人興奮的文章，都在教你用各種在自己軟體裡結合微軟產品的神秘方法來害死自己。MSDN雜誌陣營總是試圖說服你用新而複雜的外部技術，比如COM+、MSMQ、MSDE、Microsoft Office、Internet Explorer及其元件、MSXML、DirectX（請用最新版）、Windows Media Player、以及Sharepoint... Sharepoint！這個沒有人有的東西名符其實的有一大堆壯觀的外部關聯，當你要把應用程式發行給付錢的客戶時，每個關聯都會變成大麻煩，而且沒有辦法弄好。這種事的技術性名稱叫DLL地獄。在我這裡能動，為什麼在那裡不會動了？
Raymond Chen陣營相信，讓開發人員寫一次程式能到處(好吧，在所有的Windows上)執行，可以讓他們更容易做事。而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。而現在秘密終於揭露，OS團隊也心領神會，決定不再為Windows API增加新功能而是完全取代掉。我們被告知不要再用Win32了，現在要開始準備迎接WinFX (http://www.gartner.com/DisplayDocument?doc_cd=118261)：下一代的Windows API。全部都不一樣了。現在依據的是用受控代碼(managed code)的.NET、XAML、Avalon。是的，我得承認遠遠優於Win32。不過這並不是升級，而是對過去的破壞。
Windows開發的複雜困擾了外界的開發人員，他們被微軟整個平台打敗了，現去已經在發展web平台了。在dotcom興旺初期建立了Yahoo! Store的Paul Graham很有力地總結 (http://www.paulgraham.com/road.html)：「新創公司現在有更多的理由去寫Web-based軟體，因為桌面軟體寫起來已經不那麼好玩了。現在想寫桌面軟體就要照微軟的規矩，呼叫他們的API還要應付他們多蟲的OS。另外如果你真的寫出什麼熱門的東西，可能會發現自己只是在替微軟做市場研究。」
微軟已經大到有太多的開發人員，這些人太沈溺於增加收益，因此他們突然決定把每件事徹底重做過並不是太了不起的計畫。該死的，我們還可以做兩次啊。舊的微軟（Raymond Chen的微軟）可能會把Avalon（新的繪圖系統）這種東西實作成一系列的DLL，不但能在任何版本的Windows上執行，還可以和需要用到的應用程式包在一起。並沒有任何技術上的理由不這樣做，不過微軟必須找個藉口讓你買Longhorn。他們想弄出大量的改變，就像Windows取代DOS時那麼多的變化。問題是Longhorn並沒有比Windows XP先進太多；根本不到Windows超越DOS的那種程度。或許它的吸引力並不足讓人像對Windows那樣，為它買全新的電腦和應用程式。好吧，或許它有這個能耐，微軟一定得讓它有，不過就我目前所看到的實在沒什麼說服力。微軟很多東西都賭錯了。舉例來說 (http://weblog.infoworld.com/udell/2004/06/02.html#a1012)，WinFS的宣傳是以關聯式資料庫方式製作檔案系統，以達成搜尋功能的一種作法，卻忽略了事實上要達成搜尋功能的真實作法就是要達成搜尋功能(the real way to make searching work is by making searching work)。不要讓我替所有檔案輸入提示資料然後用查詢語言去搜尋。只要幫我個忙去搜尋該死的硬碟，快速地找到我打的字串，隨便你用全文檢索或其他1973年就有的技術。
自動排檔獲得最後勝利
不想把我想錯了... 我認為.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個位元組，函數會傳回「配置記憶體不足」的訊息，順便還告訴你需要配置多少記憶體。這還是簡單的情形，如果運氣不好呼叫到的函數要傳回字串的串列或是整個長度不定的結構就更麻煩了。不管如何，像開檔案寫入字串然後關閉檔案之類簡單的操作，直接呼叫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)還有向後相容問題與不可能弄懂 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Resources/VersionInformation/VersionInformationReference/VersionInformationFunctions/GetFileVersionInfo.asp)的字串回傳機制全部一掃而空，取而代之的是個單一乾淨只有一種字串的物件導向介面。一個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伺服器上執行並不需要Windows的用戶端系統。這正是個關鍵點，後面寫到web時會深入探討。
噢，等一下，還有其他東西要出來！
現在微軟有太多的開發人員在做事，徹底重做整個Windows API還不夠看，他們必須重做兩次。去年的PDC中他們預先發表了下一個重大的作業系統改版，這個代號Longhorn的系統除了其他東西之外，將會有一組代碼為Avalon的全新使用介面API。這組API是運用現代電腦快速顯示硬體及即時3D成像能力重新建立的。如果你現在正在開發Windows GUI應用程式，而且是用微軟「官方」最新最偉大的Windows程式設計環境WinForms的話，為了支援Longhorn和Avalon兩年內就得重來一遍了。這說明了為什麼WinForms完全的難產。希望你在這上面還沒有投資太多。Jon Udell找到一份標題為「如何在Windows Forms和Avalon間選擇？」微軟的投影片，裡頭問道 (http://weblog.infoworld.com/udell/2004/06/09.html#a1019)：「我們為什麼要在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完全結束，結果還在使用的人實在太多，於是他們只好承諾 (http://www.windows-help.net/microsoft/98-lifecycle.html)會對那個老爺系統再多支援幾年。
這些勇敢的新策略（.NET、Longhorn、Avalon之類的玩意）試圖建立一組新API把大家鎖住。問題是大家都還在用1998時買來還很好用的電腦，這種策略是不太行不通的。即使Longhorn照計畫在2006推出（我根本不相信），大概還得多等幾年，擁有的人數才會多到能考慮作為開發平台。開發者們才不會聽從微軟教我們如何開發軟體的多重人格失調建議呢！
進入Web
我不知道自己怎麼能寫這麼久還沒提到Web。每個開發人員在計畫新軟體應用程式時都要做一個選擇，他們可以做成web版本，也可以做一個在PC上執行的"rich client"應用程式。基本的優缺點很單純：Web應用程式比較容易部署，而rich client應用程式反應較快所以使用介面比較有趣。
Web應用程式比較容易部署是因為不需要安裝。Web應用程式的安裝等於只是在網址列輸入一個URL。今天我要安裝Google的新電郵程式，只要按Alt+D、gmail，再按Ctrl+Enter就好了。相容性問題還有與其他軟體相衝的問題都少太多了。產品所有的使用者都在用相同的版本，所以你永遠不必支援各種舊版本。你可以用任何喜歡的開發環境，因為只要裝在自己的伺服器上執行就好了。在這個星球上幾乎每台還可以的電腦自然而然都能用你的應用程式。而你客戶的資料也很理所當然能用於這星球上任何一台還可以的電腦上。
不過這必須付出使用介面的平順作為代價。下面是幾個web應用程式做不好的例子：
- 創造一個快速繪圖的程式
- 寫一個能標示紅色波浪底線的即時拼字檢查程式
- 在使用者按到瀏覽器的關閉盒時，警告使用者將會遺失其工作成果
- 不必連到伺服器來回溝通一遍，就能依據使用者的變更來更新小部份的顯示，
- 建立一個不需滑鼠的快速鍵盤驅動介面
- 讓大家在沒有連上Internet時繼續作業
這些都不算大問題，其中有些很快就會被聰明的Javascript開發人員解決。有兩個新的web應用程式Gmail (https://gmail.google.com/)以及Oddpost (http://www.oddpost.com/)（都是電郵程式）做得相當不錯，避開或完全解決了部份的問題。另外使用者似乎也不在意UI小問題或web介面的緩慢。不知道為什麼，不管我如何努力宣揚rich client會，呃，比較豐富，我認識的人幾乎全都對web式的電子郵件軟體十分滿意。
所以Web使用介面已經有80分了，就算不靠新的web瀏覽器還是有機會達成95分。這對大多數人來說已經夠好了，當然對開發人員來說也夠了，而且他們也已經實際把幾乎所有重要的新應用程式都寫成web應用程式。
這表示微軟的API突然間已經不那麼重要了。Web並不需要Windows。
微軟並不是沒注意到這件事發生。他們當然知道，所以他們在局勢浮現時就猛踩煞車。他們不再在未來計畫裡承諾像HTA (http://msdn.microsoft.com/workshop/author/hta/overview/htaoverview.asp)和DHTML這類的新技術。Internet Explorer團隊似乎也消失了；他們有好幾年似乎完全沒有動作。微軟不可能容許DHTML變得比現在更好，這對他們的核心事業rich client來說實在太危險了。微軟最近的重大思想基因(memo)是：「微軟把公司的未來賭在rich client上。」這句話會遍佈Longhorn相關的每頁簡報上。來自Avalon團隊的Joe Beda說道 (http://channel9.msdn.com/ShowPost.aspx?PostID=948)：「Avalon(大體上還有Longhorn)是微軟的基石。這句話表示我們相信你桌面的威力，能夠完成各種了不起的東西，而且是不可或許的。我們正在持續投入桌面，我們認為這會是個好地方，而且我們希望自己能啟動一波振奮...」
問題是現在已經太遲了。
我本身對這有一點點難過
我本身對這真的有一點點難過。對我來說Web是很不錯，不過Web應用程式的使用介面既爛又慢也不一致，就日常使用來說實在是倒退一大步。我愛我的rich client應用程式，如果日常使用的應用程式(Visual Studio、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 threading、aggregate、tearoff，還有其他一百萬件基本上只有Don Dox會的東西。事實上連Don Box無法忍受再回來看這些東西 (http://news.com.com/2100-1046_3-5148148.html)。
雖然我很不想這樣說，不過大量的開發人員早就移到web而且拒絕再回來。大部份的.NET開發人員都是用ASP.NET針對微軟的web伺服器進行開發。ASP.NET很出色。我從事web開發已經十年，而它真的是比其他工具先進一個世代。不過ASP.NET是伺服器技術，所以用戶端可以用任意的桌面系統。何況ASP.NET還能在Linux上用Mono (http://www.go-mono.com/)執行得相當好呢。
這些東西沒有一個對微軟有利，對微軟得力於API權勢的利益也一樣。新的API是HTML，而能讓HTML唱歌的人將會是應用程式開發市場的新贏家。
這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.