作者：周思博 (Joel Spolsky)
譯：Paul May 梅普華
Sunday, June 13, 2004
屬於 Joel on Software, https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/
這陣子你應該聽過某種理論：「微軟要完蛋了。只要 Linux 在桌上型市場有些進展，而 web 應用程式又取代桌上型系統的應用程式，這個強盛帝國就會崩潰了。」
雖然 Linux 的確是微軟的心頭大患，不過至少要預言這個 Redmond 公司滅亡還言之過早。微軟銀行裡的現金多得不得了，而且仍是非常的賺錢，還要很久很久才可能倒。微軟可以胡搞個十年才會開始有點危險，而且你永遠不會知道……他們可能在最後一刻變身成刨冰公司。所以別這麼快就看衰他們。90 年代初期大家都認為 IBM 徹底完蛋了，因為大型主機（mainframe）已經成為歷史！那時候 Robert X. Cringely 預言主機時代會在 2000 年 1 月 1 日結束，屆時所有用 COBOL 寫的程式都會出問題。由於原始碼都早已遺失（據稱），所以沒有人會去修正這件程式，大家都會針對主從架構的平台把這些程式全部重寫過。
好吧，猜猜結果如何。大型主機仍然與我們同在，2000 年 1 月 1 日什麼事都沒發生，而 IBM 則是變身成一家巨大的老牌技術顧問公司，同時恰巧也在製造便宜塑膠電話。所以只由少數幾個資料就推斷出微軟要完蛋的理論，實在是有點誇大了。
不過大多數人並未注意到一個較不為人知的現象：微軟在戰略上最重要的寶物 Windows API 要輸了。Windows 與 Office 的利潤豐厚，幾乎貢獻微軟所有的收入，還養活大量不賺錢或賺很少的產品線。這些賺錢產品的特權和微軟的壟斷勢力都是以 Windows API 為基石。不過它對開發人員不再那麼有吸引力了。生金蛋的鵝還沒死，不過已經得了還沒人注意到的絕症。
既然我已經說了，請容我為前一段的大言不慚和炫耀說聲抱歉。我想我看起來開始像那些商業小報的評論主筆，喋喋不休地談論 Windows API 這個微軟的策略資產。我打算在這裡用幾頁的篇幅，來解釋我真正的意思並闡明我的論點。在我解釋清楚之前請不要直接下任何結論。這會是篇很長的文章，我得解釋什麼是 Windows API；我也得說明它為什麼是微軟最重要的策略式資產，還要解釋它會怎麼輸掉以及輸掉這件事長期的含意。另外既然是在談大趨勢，難免也得誇大其詞和泛泛空談囉。
還記得作業系統的定義嗎？它負責管理一台電腦的資源讓應用程式能執行。大家其實並不太在意作業系統；比較重視那些依賴作業系統的應用程式。像是文書處理器、即時通訊、電子郵件、應付帳款管理、有 Paris Hilton 照片的網站等等。作業系統本身並沒什麼用。大家會買作業系統是因為上面可以執行有用的應用程式。因此最有用的作業系統就是擁有最有用應用程式的作業系統。
由這裡可以合理推出一個結論，如果你想要賣作業系統，最重要的就是讓軟體開發者願意替你的作業系統寫軟體。所以 Steve Ballmer 才會跳上舞台大喊「開發者、開發者、開發者、開發者。」這對微軟實在是太重要了。微軟沒有公然發放Windows 開發工具，唯一的理由就是怕不小心砍斷競爭開發工具商的生路（嗯，是指還活著的那些）。因為有各種開發工具可以選擇，會讓他們的平台更能吸引開發人員。不過他們其實真的想要發放開放工具。你可以透過他們的 Empower ISV 深耕計劃，以大約 375 美元買到五套完整的 MSDN Universal（也就是「除模擬飛行外的所有微軟產品」）。免費的 .NET runtime 附有命令列版本的 .NET 語言編譯器... 也是免費的。現在 C++ 編譯器也免費了。微軟盡各種方法鼓勵開發者支持 .NET 平台，只是為了不要害死 Borland 這些公司才收斂一點。
好吧，這樣說當然是有點蠢。蘋果和 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 寫道：「有人指控微軟在 OS 升級時惡意地妨害應用程式時我會覺得很生氣。如果有任何程式不能在 Windows 95 執行，我會視為個人的失敗。我有很多個晚上沒睡去修正別人的程式，只是為了讓它們能在 Windows 95 執行。」
很多開發人員和工程師都不同意這種作法。他們認為如果應用程式做了壞事或依賴某些未公開的行為，應該讓它們在 OS 升級後直接掛掉。蘋果公司的麥金塔 OS 開發人員一直都在這個陣營。這也是很少麥金塔早期的程式還能動的原因。舉例來說，很多開發人員為了加速自己的麥金塔應用程式，會把中斷跳躍表的指標複製出來直接呼叫，而不按正常方法使用處理器的中斷功能。雖然蘋果的官方麥金塔程式設計聖經 Inside 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 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：下一代的 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 的宣傳是以關聯式資料庫方式製作檔案系統，以達成搜尋功能的一種作法，卻忽略了事實上要達成搜尋功能的真實作法就是要達成搜尋功能（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 開發的。
接下來又出現了 .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 伺服器上執行並不需要 Windows 的用戶端系統。這正是個關鍵點，後面寫到 web 時會深入探討。
現在微軟有太多的開發人員在做事，徹底重做整個 Windows API 還不夠看，他們必須重做兩次。去年的 PDC 中他們預先發表了下一個重大的作業系統改版，這個代號 Longhorn 的系統除了其他東西之外，將會有一組代碼為 Avalon 的全新使用介面 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 的所有新開發工具，因為微軟有太多該死的員工在做開發工具！
微軟是在 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 版本，也可以做一個在PC上執行的 "rich client" 應用程式。基本的優缺點很單純：Web 應用程式比較容易部署，而 rich client 應用程式反應較快所以使用介面比較有趣。
Web 應用程式比較容易部署是因為不需要安裝。Web 應用程式的安裝等於只是在網址列輸入一個 URL。今天我要安裝 Google 的新電郵程式，只要按 Alt+D、gmail，再按 Ctrl+Enter 就好了。相容性問題還有與其他軟體相衝的問題都少太多了。產品所有的使用者都在用相同的版本，所以你永遠不必支援各種舊版本。你可以用任何喜歡的開發環境，因為只要裝在自己的伺服器上執行就好了。在這個星球上幾乎每台還可以用的電腦，自然而然都能用你的應用程式。而你客戶的資料也很理所當然能用於這星球上任何一台還可以的電腦上。
不過這必須付出使用介面的平順作為代價。下面是幾個 web 應用程式做不好的例子：
這些都不算大問題，其中有些很快就會被聰明的 Javascript 開發人員解決。有兩個新的 web 應用程式 Gmail 以及 Oddpost（都是電郵程式）做得相當不錯，避開或完全解決了部份的問題。另外使用者似乎也不在意 UI 小問題或 web 介面的緩慢。不知道為什麼，不管我如何努力宣揚 rich client 會，呃，比較豐富，我認識的人幾乎全都對 web 式的電子郵件軟體十分滿意。
所以 Web 使用介面已經有 80 分了，就算不靠新的 web 瀏覽器還是有機會達成 95 分。這對大多數人來說已經夠好了，當然對開發人員來說也夠了，而且他們也已經實際把幾乎所有重要的新應用程式都寫成 web 應用程式。
這表示微軟的 API 突然間已經不那麼重要了。Web 並不需要 Windows。
微軟並不是沒注意到這件事發生。他們當然知道，所以他們在局勢浮現時就猛踩煞車。他們不再在未來計畫裡承諾像 HTA 和 DHTML 這類的新技術。Internet Explorer 團隊似乎也消失了；他們有好幾年似乎完全沒有動作。微軟不可能容許 DHTML 變得比現在更好，這對他們的核心事業 rich client 來說實在太危險了。微軟最近的重大思想基因（memo）是：「微軟把公司的未來賭在 rich client 上。」這句話會遍佈 Longhorn 相關的每頁簡報上。來自 Avalon 團隊的 Joe Beda 說道：「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 都無法忍受再回來看這些東西。
雖然我很不想這樣說，不過大量的開發人員早就移到 web 而且拒絕再回來。大部份的 .NET 開發人員都是用 ASP.NET 針對微軟的 web 伺服器進行開發。ASP.NET 很出色。我從事 web 開發已經十年，而它真的是比其他工具先進一個世代。不過 ASP.NET 是伺服器技術，所以用戶端可以用任意的桌面系統。何況 ASP.NET 還能在 Linux 上用Mono執行得相當好呢。
這些東西沒有一個對微軟有利，對微軟得力於 API 權勢的利益也一樣。新的 API 是 HTML，而能讓 HTML 唱歌的人將會是應用程式開發市場的新贏家。
這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.