【译】How Microsoft Lost the API War
這是你最近聽到的一個理論：“微軟已經完成了。?一旦Linux在桌面上取得一些進展，Web應用程序取代桌面應用程序，強大的帝國就會倒下。“
盡管Linux對微軟來說是一個巨大的威脅，但事實確實存在一些事實，但至少可以說，雷德蒙德公司即將滅亡的預測還為時過早。?微軟在銀行擁有大量現金，而且仍然非常有利可圖。?它還有很長的路要走。?在它開始處于遙遠的危險之前，它可以做出一切錯事，而且你永遠不會知道......他們可以在最后一分鐘重塑自己作為一個剃光冰公司。?所以不要這么快就把它們寫下來。?在90年代早期，每個人都認為IBM完全結束了：大型機是歷史！?那時候，Robert X. Cringely預測大型機的時代將在2000年1月1日結束，屆時所有用COBOL編寫的應用程序都會抓住，而不是修復那些應用程序，據稱源代碼早就應用了迷路了，每個人都會為客戶端 - 服務器平臺重寫這些應用程序。
好吧，猜猜看。?大型機仍然在我們身邊，2000年1月1日沒有發生任何事情，IBM重新發明了自己作為一家大型技術咨詢公司，也恰好生產廉價的塑料電話?。?從幾個數據點到微軟完成的理論的推斷實際上是非常嚴重的夸張。
但是，人們對這一現象的了解程度很低，而這種現象基本上沒有被注意到：微軟的皇冠戰略寶石Windows API已經失傳。?作為微軟壟斷力量和令人難以置信的盈利的Windows和Office特許經營權的基石，它幾乎占據了微軟的所有收入，并涵蓋了大量無利可圖或利潤微薄的產品線，Windows API對開發人員不再感興趣。?產下金蛋的鵝并沒有完全死亡，但它確實有一種終末疾病，一種沒有人注意到的疾病。
既然我已經說過了，請允許我為前一段的宏觀和浮夸道歉。?我認為我開始聽起來像是那些繼續談論微軟戰略資產Windows API的編輯作者。?在這里，我將花幾頁時間來解釋我正在談論的內容，并證明我的觀點是正確的。?在我解釋我在說什么之前，請不要跳到任何結論。?這將是一篇很長的文章。?我需要解釋一下Windows API是什么;我需要證明它為什么是微軟最重要的戰略資產;?我需要解釋它是如何丟失的，以及它在長期內的含義。?而且因為我在談論大趨勢，我需要夸大和概括。
開發人員，開發人員，開發人員，開發人員
還記得操作系統的定義嗎？?這是管理計算機資源以便應用程序可以運行的東西。?人們對操作系統并不十分關心;?他們關心操作系統可能實現的那些應用程序。?文字處理器。?即時通訊。?電子郵件。?應付賬款。?有巴黎希爾頓照片的網站。?操作系統本身并不那么有用。?人們購買操作系統是因為它上面運行著有用的應用程序。?因此，最有用的操作系統是具有最有用的應用程序的操作系統。
合乎邏輯的結論是，如果您正在嘗試銷售操作系統，最重要的是讓軟件開發人員想要為您的操作系統開發軟件。?這就是為什么史蒂夫鮑爾默在舞臺上大喊“開發人員，開發人員，開發人員，開發人員。”這對于微軟來說非常重要，因為他們不能完全放棄?Windows的開發工具，因為他們不想無意中削減將氧氣排除在競爭性開發工具供應商（以及剩下的那些）之外，因為他們的平臺擁有各種開發工具，這使得它對開發人員更具吸引力。?但他們真的想放棄開發工具。?通過他們的Empower ISV程序，您可以獲得五套完整的MSDN Universal（也稱為“?基本上每個Microsoft產品，除了Flight Simulator?”），價格約為375美元。?.NET語言的命令行編譯器包含在免費的.NET運行時中......也是免費的。?C ++編譯器現在是免費的?。?任何可以鼓勵開發人員為.NET平臺構建的東西，并且只是沒有消除像Borland這樣的公司。
為什么Apple和Sun不能銷售電腦
嗯，當然，這有點愚蠢：當然Apple和Sun可以銷售電腦，但不能銷售兩個最賺錢的電腦市場，即企業臺式機和家用電腦。?蘋果仍處于市場份額非常低的個位數，而桌面上唯一有太陽的人是在Sun.?（請理解我在這里談論大趨勢，因此當我說“無人”這樣的事情時，我的意思是“少于10,000,000人”，依此類推等等。）
為什么？?因為Apple和Sun計算機不運行Windows程序，或者如果它們運行，它會處于某種昂貴的仿真模式，而這種模式并不是那么好用。?請記住，人們為他們運行的應用程序購買計算機，并且Windows可用的桌面軟件比Mac更加出色，因此很難成為Mac用戶。
邊欄什么是“API”的東西？
如果您正在編寫一個程序，比如一個文字處理程序，并且您想顯示一個菜單，或者要編寫一個文件，您必須要求操作系統為您執行此操作，使用一組非常特定的函數調用。每個操作系統都有所不同。這些函數調用稱為API：它是操作系統（如Windows）為應用程序開發人員提供的接口，例如構建文字處理程序和電子表格的程序員等等。?它是程序員可以使用的一組成千上萬的詳細和繁瑣的函數和子程序，它們使操作系統做有趣的事情，如顯示菜單，讀寫文件，以及更多深奧的東西，比如如何拼出一個在塞爾維亞語中給出日期，或者在窗口中顯示網頁等非常復雜的事情。?如果您的程序使用Windows的API調用，則它不適用于具有不同API調用的Linux。?有時它們大致相同。?這是Windows軟件無法在Linux上運行的一個重要原因。?如果你想讓一個Windows程序在Linux下運行，你必須重新實現整個Windows API，它包含數千個復雜的功能：這幾乎與實現Windows本身一樣多，這需要微軟成千上萬的人-年份。?如果你犯了一個小錯誤或遺漏了一個應用程序需要的功能，該應用程序將崩潰。
這就是為什么Windows API對微軟來說是如此重要的資產。
（我知道，我知道，在這一點上，使用Macintoshes的2.3％的人正在熱身他們的電子郵件程序給我發一封關于他們多么喜歡他們的Mac的嚴厲信件。再一次，我說的是大趨勢和概括，所以不要浪費你的時間。我知道你愛你的Mac。我知道它運行你需要的一切。我愛你，你是胡椒，但你只占世界的2.3％，所以這篇文章不是關于你。）
微軟的兩股勢力
微軟內部有兩種相反的力量，我將會提到這一點，有點像舌頭，就像雷蒙德陳營和MSDN雜志營。
Raymond Chen是微軟Windows團隊的開發人員。?他自1992年以來一直在那里，他的博客The Old New Thing充滿了詳細的技術故事，講述了為什么某些事情就像他們在Windows中一樣，甚至是愚蠢的事情，這些都有很好的理由。
雷蒙德博客上最令人印象深刻的事情是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，在調試器中執行了它，發現了bug，并添加了檢查SimCity是否正在運行的特殊代碼?，如果確實如此，則以特殊模式運行內存分配器釋放后仍然可以使用內存?。
這不是一個不尋常的案例。?Windows測試團隊規模巨大，他們最重要的職責之一是保證每個人都可以安全地升級他們的操作系統，無論他們安裝了什么應用程序，這些應用程序將繼續運行，即使這些應用程序做壞事或使用無證件功能或依賴于在Windows?n中碰巧有錯誤但在Windows?n?+1中不再有錯誤的錯誤行為。?事實上，如果你在注冊表的AppCompatibility部分瀏覽，你會看到Windows專門處理的應用程序的完整列表，模擬各種舊的錯誤和古怪的行為，以便它們繼續工作。?Raymond Chen?寫道?：“當人們指責微軟在操作系統升級期間惡意破壞應用程序時，我特別憤怒。?如果任何應用程序無法在Windows 95上運行，我將其視為個人故障。?我花了很多不眠之夜修復第三方程序中的錯誤，這樣他們就可以繼續在Windows 95上運行。“
許多開發人員和工程師不同意這種工作方式。?如果應用程序做了一些不好的事情，或依賴于一些未記錄的行為，他們認為，它應該在操作系統升級時中斷。?Apple的Macintosh操作系統開發人員一直都在這個陣營。?這就是為什么早期的Macintosh應用仍然很少的原因。?例如，許多開發人員過去常常試圖通過從跳轉表中復制指針并直接調用它們而不是像預期那樣使用處理器的中斷功能來使其Macintosh應用程序運行得更快。?即使在Apple的Macintosh官方圣經Macintosh?內部的某個地方，也有一個技術說明“你不能這樣做”，他們做到了，它起作用了，他們的程序運行得更快......直到OS的下一個版本出來了，他們根本沒有跑。?如果制作該應用程序的公司破產（并且大部分都已經破產），那么，運氣不好，冒泡。
相比之下，由于微軟的Raymond Chen Camp，我在1983年為那臺仍然運行良好的原始IBM PC編寫了DOS應用程序。?我知道，當然不僅僅是雷蒙德：它是核心Windows API團隊的整體運作方式?。?但雷蒙德通過他出色的網站The Old New Thing對其進行了最廣泛的宣傳，所以我將其命名為他。
這是一個陣營。?另一個陣營就是我將要稱之為MSDN雜志的陣營，我將在開發人員的雜志上寫下我的名字，這些雜志上有很多令人興奮的文章，關于你可以通過自己使用微軟產品的深奧組合來拍攝自己的所有不同方式軟件。?MSDN雜志夏令營總是試圖說服您使用新的和復雜的外部技術，如COM +，MSMQ，MSDE，Microsoft Office，Internet Explorer及其組件，MSXML，DirectX（請使用最新版本），Windows Media Player和Sharepoint ...分享點！?沒有人?;?一個名副其實的外部依賴項，當您將應用程序發送給付費客戶并且無法正常運行時，每個外部依賴項都將成為一個巨大的問題。?這個技術名稱是DLL Hell。?它在這里工作：它為什么不在那里工作？
Raymond Chen Camp堅持讓開發人員輕松編寫一次并在任何地方運行（在任何Windows機器上）。?MSDN雜志夏令營相信，如果他們愿意付出極其復雜的部署和安裝難題的代價，更不用說龐大的學習曲線，就可以為開發人員提供非常強大的代碼塊，以便他們可以利用這些代碼。?雷蒙德陳陣營就是整合。?請不要讓事情變得更糟，讓我們繼續制作我們已經擁有的東西。?MSDN雜志夏令營需要不斷推出新的巨大技術，而這些技術無人能跟上。
這就是為什么這很重要。
微軟失去了向后兼容性宗教
在微軟內部，MSDN雜志陣營贏得了勝利。
第一個重大勝利是使Visual Basic.NET不能向后兼容VB 6.0。?這實際上是第一次在生活記憶中，當你購買升級到微軟產品時，你的舊數據（即用VB6編寫的代碼）無法完美無聲地導入。?這是微軟升級第一次不尊重用戶使用以前版本的產品所做的工作。
天空似乎沒有下降，不在微軟內部。?VB6開發人員處于起步階段，但無論如何他們都在消失，因為他們中的大多數都是企業開發人員，無論如何都要遷移到Web開發。?真正的長期損害是隱藏的。
憑借這一重大勝利，MSDN雜志陣營接管了。?突然間，改變一切都是可以的。?IIS 6.0推出了一個不同的線程模型，打破了一些舊的應用程序。?我很震驚地發現我們的Windows Server 2003客戶在運行FogBugz時遇到了麻煩。?然后.NET 1.1與1.0完全向后兼容。?現在，這只貓已經不在了，操作系統團隊深入了解并決定不再向Windows API添加功能，而是完全取代它。?我們被告知，我們現在應該開始為WinFX做準備，而不是Win32：下一代Windows API。?各不相同。?基于帶托管代碼的.NET。?XAML。?阿瓦隆。?是的，我承認它遠遠優于Win32。?但不是升級：與過去決裂。
外部開發人員從未對Windows開發的復雜性感到特別滿意，他們已經從微軟平臺中退出，現在正在為網絡開發。?創建雅虎的保羅格雷厄姆?網絡繁榮初期的商店，雄辯地總結道?：“創業公司現在有更多的理由來編寫基于網絡的軟件，因為編寫桌面軟件變得不那么有趣了。如果你現在要編寫桌面軟件，你可以按照微軟的條款，調用他們的API并解決他們的錯誤操作系統。?如果你設法寫下一些起飛的東西，你可能會發現你只是在為微軟做市場研究。“
微軟變得足夠大，開發人員太多，而且他們太沉迷于升級收入，所以他們突然決定重新發明一切?并不是一個太大的項目。?哎呀，我們可以做兩次。?舊的微軟，Raymond Chen的微軟，可能已經實現了像新的圖形系統Avalon這樣的東西，它們可以在任何版本的Windows上運行，并且可以與需要它們的應用程序捆綁在一起。?沒有技術理由不這樣做。?但微軟需要給你一個購買Longhorn的理由，他們試圖推出的是一次大變革，類似于Windows取代DOS時發生的大變革。?麻煩的是，Longhorn并不是Windows XP的一大進步;?沒有像Windows那樣大的DOS。?它可能不足以讓人們像購買Windows一樣購買所有新的計算機和應用程序。?好吧，也許它會，微軟當然需要它，但到目前為止我看到的并不是很有說服力。?微軟所做的很多賭注都是錯誤的。?例如?，WinFS作為一種通過使文件系統成為關系數據庫來進行搜索工作的方式而被廣告，忽略了這樣一個事實，即使搜索工作的真正方法是使搜索工作。?不要讓我為我可以使用查詢語言搜索的所有文件鍵入元數據。?請幫我一個忙，快速搜索該死的硬盤，查找我輸入的字符串，使用全文索引和1973年無聊的其他技術。
自動變速器贏得了一天
不要誤會我的意思......我認為.NET是一個很好的開發環境，帶有XAML的Avalon比用于Windows編寫GUI應用程序的舊方法有了很大的進步。?.NET的最大優點是它具有自動內存管理功能。
我們很多人在20世紀90年代認為，在程序編程和面向對象編程之間進行大戰，我們認為面向對象編程可以大大提高程序員的工作效率。我也這么認為。?有些人仍然認為。?事實證明我們錯了。?面向對象的編程是方便的花花公子，但它并不是真正提出的生產力助推器。?我們在編程中獲得的真正顯著的生產力提升來自于自動管理內存的語言。?它可以用引用計數或垃圾收集;?它可以是Java，Lisp，Visual Basic（甚至1.0），Smalltalk或任何一種腳本語言。?如果你的編程語言允許你抓住一大塊內存而不考慮它完成后它將如何發布，那么你使用的是托管內存語言，你會比某些人更有效率使用您必須明確管理內存的語言。?每當你聽到有人吹噓他們的語言有多高效時，他們可能從自動化內存管理中獲得大部分生產力，即使他們錯誤地歸因于它。
側邊欄?
為什么自動內存管理會讓您更高效？1）因為您可以編寫f（g（x））而不必擔心如何從g中釋放返回值，這意味著您可以使用返回有趣的復雜數據類型和函數的函數來轉換有趣的復雜數據類型，從而允許您在更高的抽象層次上工作。?2）因為您不必花時間編寫代碼來釋放內存或跟蹤內存泄漏。?3）因為您不必仔細協調功能的出口點，以確保正確清理事物。
賽車愛好者可能會發送給我討厭的郵件，但我的經驗是，只有一種情況，在正常駕駛中，良好的自動變速器不如手動變速箱。?類似地，在軟件開發中：幾乎在所有情況下，自動內存管理都優于手動內存管理，從而使程序員的工作效率大大提高。
如果您在Windows的早期開發桌面應用程序，Microsoft提供了兩種方法：編寫直接調用Windows API的C代碼并管理自己的內存，或者使用Visual Basic并為您管理內存。?這些是我在過去13年左右中最常用的兩個開發環境，我從內到外了解它們，我的經驗是Visual Basic的效率要高得多。?我經常編寫相同的代碼，一次是在C ++中調用Windows API，一次是在Visual Basic中，而C ++總是花費三到四倍的工作量。?為什么？?內存管理。?查看原因的最簡單方法是查看需要返回字符串的任何Windows API函數的文檔。?仔細觀察圍繞誰為字符串分配內存的概念進行了多少討論，以及如何協商需要多少內存。?通常，你必須在第一次調用時調用該函數兩次?，你告訴它你已經分配了零字節，并且它失敗了“沒有足夠的內存分配”消息，并且方便地告訴你需要分配多少內存。?如果你足夠幸運，不要調用返回字符串列表或整個可變長度結構的函數。?在任何情況下，打開文件，編寫字符串以及使用原始Windows API關閉它等簡單操作都可能需要一頁代碼。?在Visual Basic中類似的操作可以占用三行。
所以，你有這兩個編程世界。?每個人都已經決定托管代碼的世界遠遠優于非托管代碼的世界。?Visual Basic曾經（并且可能仍然是）有史以來最暢銷的語言產品，并且開發人員更傾向于使用C或C ++進行Windows開發，盡管“Basic”在產品名稱中的事實使得硬核程序員避開了它它是一種相當現代的語言，具有一些面向對象的特性和很少的剩余垃圾（行號和LET語句已經走了呼啦圈）。?VB的另一個問題是部署需要運行VB運行時，這對于通過調制解調器分發的共享軟件來說是一個大問題，更糟糕的是，讓其他程序員看到你的應用程序是在（?羞恥?！）Visual Basic中開發的。
一個運行時來統治它們
隨之而來的是.NET。?這是一個宏偉的項目，是一個一勞永逸地清理整個混亂的超級統一項目。?當然，它會有內存管理。?它仍然會有Visual Basic，但它會獲得一種新的語言，它與Visual Basic幾乎相同，但具有大括號和分號的C語法。?最重要的是，新的Visual Basic / C混合體將被稱為Visual C＃，因此您不必再告訴任何人您是“基本”程序員。?所有那些可怕的Windows函數及其尾部和鉤子以及向后兼容性錯誤和不可能弄清楚的字符串返回語義都將被消除，取而代之的是一個只有一種字符串的干凈的面向對象的接口。?一個運行時來統治它們。?它過去挺美。?從技術上講，他們把它拉了下來。?.NET是一個很好的編程環境，可以管理您的內存，并且具有豐富，完整和一致的操作系統接口，以及用于基本操作的豐富，超完整和優雅的對象庫。
然而，人們并沒有真正使用.NET。
哦，當然，其中一些是。
但是通過創建一個全新的，全新的編程環境來統一Visual Basic和Windows API編程的混亂的想法，這個編程環境不是一種，而是兩種，而是三種語言（或者有四種語言？）有點像獲取的想法兩個爭吵的孩子停止爭吵，大喊“閉嘴！”比其中任何一個人都大聲說話。?它只適用于電視。?在現實生活中，當你對兩個人大聲爭吵地大喊“閉嘴！”時，你只是創造了一個更響亮的三方論證。
（順便說一句，對于那些追隨神秘但充滿政治色彩的博客聯合供稿格式的人，你可以看到同樣的事情發生在那里.RSS變得支離破碎，有幾個不同的版本，不準確的規格和許多政治斗爭，并且通過創建另一種稱為Atom的格式來清理所有內容的嘗試導致了幾個不同版本的RSS加上一個版本的Atom，不準確的規范和大量的政治斗爭。當你試圖通過創建第三個替代方案來統一兩個相反的力量時，你最后得到了三種對立的力量。你沒有統一任何東西而且你沒有真正修復任何東西。）
因此，現在不是.NET統一和簡化，我們有一個很大的6路混亂，每個人都試圖找出使用哪種開發策略，以及他們是否能負擔得起將現有應用程序移植到.NET。
無論微軟在他們的營銷信息中如何保持一致（“只使用.NET信任我們！”），他們的大多數客戶仍在使用C，C ++，Visual Basic 6.0和經典ASP，更不用說所有其他開發工具了。來自其他公司。?而那些使用.NET的人正在使用ASP.NET來開發Web應用程序，這些應用程序在Windows服務器上運行但不需要Windows客戶端?，這是我在談論網絡時會談到的關鍵點。
哦，等等，還有更多！
現在微軟有這么多的開發人員開始發現它不足以重新發明整個Windows API：他們必須重新發明兩次?。?在去年的PDC上，他們預先宣布了他們的操作系統的下一個主要版本，代號為Longhorn?，其中包含一個全新的用戶界面API，代號為Avalon?，從頭開始重建，以利用現代計算機的快速顯示適配器和實時3D渲染。?如果你今天使用微軟的“官方”最新和最好的Windows編程環境WinForms開發Windows GUI應用程序，你將不得不在兩年內重新開始支持Longhorn和Avalon。?這解釋了為什么WinForms完全死產。?希望你沒有投入太多。?Jon Udell發現微軟的一張幻燈片標有“我如何在Windows窗體和Avalon之間選擇？”并詢問?“為什么我必須在Windows窗體和Avalon之間進行選擇？”這是一個很好的問題，而且他找不到很好的答案。
所以你已經擁有了Windows API，你已經擁有了VB，現在你已經擁有了幾種語言版本的.NET，并且不會過于依賴任何一種，因為我們正在制作Avalon，你看到了，它只能運行在最新的微軟操作系統上，沒有人會在這個系統上運行。?而且我個人還沒有時間深入學習.NET，而且我們還沒有將Fog Creek的兩個應用程序從經典ASP和Visual Basic 6.0移植到.NET，因為我們沒有投資回報。?沒有。?就我而言，它只是Fire和Motion?：微軟希望我不再為我們的錯誤跟蹤軟件和內容管理軟件添加新功能，而是浪費幾個月的時間將其移植到另一個編程環境中，這樣做不會帶來好處單個客戶，因此不會再獲得一次銷售，因此完全浪費了幾個月，這對微軟來說非常好，因為他們也有內容管理軟件和錯誤跟蹤軟件，所以他們不想更好而不是讓我浪費時間旋轉周期追趕風味，然后浪費一兩年做一個Avalon版本，同時他們為自己的競爭軟件添加功能。?Riiiight?。
沒有日常工作的開發人員有時間跟上Redmond推出的所有新開發工具，只是因為微軟制造開發工具的員工太多了！
它不是1990年
微軟在20世紀80年代和90年代長大，當時個人電腦的增長如此驚人，以至于每年售出的新電腦數量超過整個安裝基數。?這意味著，如果您制作的產品只能在新電腦上使用，即使沒有人切換到您的產品，也可能在一兩年內接管全世界。?這就是Word和Excel如此徹底地取代WordPerfect和Lotus的原因之一：微軟只是等待下一波硬件升級浪潮，并將Windows，Word和Excel出售給購買下一輪臺式電腦的公司（在某些情況下是第一輪） ）。?因此，在許多方面，Microsoft從未需要學習如何獲得已安裝的基礎，以便從產品N切換到產品N + 1。?當人們購買新計算機時，他們很樂意在新計算機上獲得所有最新的微軟內容，但升級的可能性要小得多。?當PC行業像野火一樣成長時，這并不重要，但是現在全世界已經飽和了PC，其中大部分都是Just Fine，謝謝你，微軟突然意識到最新的東西需要更長的時間才能到達那里。?當他們試圖“生命終結”Windows 98時，事實證明仍然有這么多人使用它，?他們不得不承諾支持那個老吱吱作響的奶奶多年。
不幸的是，這些勇敢的新策略，如.NET和Longhorn以及Avalon，試圖創建一個新的?API來鎖定人們，如果每個人仍然使用他們自1998年以來的足夠好的計算機，就不能很好地工作。即使Longhorn發貨當它應該在2006年，我不相信一分鐘，它需要幾年才能有足夠的人擁有它甚至值得考慮作為一個開發平臺。?開發人員，開發人員，開發人員和開發人員都沒有購買微軟關于如何開發軟件的多重人格混亂的建議。
進入網絡
我不確定如何在不提及網絡的情況下實現這一目標。?每個開發人員在計劃新的軟件應用程序時都可以選擇：他們可以為Web構建它，或者他們可以構建一個在PC上運行的“富客戶端”應用程序。?基本的優點和缺點很簡單：Web應用程序更易于部署，而富客戶端提供更快的響應時間，從而實現更有趣的用戶界面。
Web應用程序更易于部署，因為不涉及安裝。?安裝Web應用程序意味著在地址欄中鍵入URL。?今天我通過輸入Alt + D，gmail，Ctrl + Enter安裝了Google的新電子郵件應用程序。?與其他軟件共存的兼容性問題和問題要少得多。?您產品的每個用戶都使用相同的版本，因此您永遠不必支持舊版本的混合。?您可以使用您想要的任何編程環境，因為您只需要在自己的服務器上啟動并運行它。?您的應用程序幾乎可以在全球所有合理的計算機上使用?。?您的客戶數據也可以在全球幾乎所有合理的計算機上自動獲取。
但是，用戶界面的平滑性需要付出代價。?以下是一些您在Web應用程序中無法做得很好的示例：
這些都不是大問題。?其中一些將很快由詼諧的Javascript開發人員解決。?兩個新的網絡應用程序，?Gmail和Oddpost?，這兩個電子郵件應用程序，在處理或完全解決其中一些問題方面做得非常體面。?而且用戶似乎并不關心小UI故障和Web界面的緩慢。?幾乎所有我認識的普通人都對基于網絡的電子郵件感到非常滿意，出于某種原因，無論我多么努力讓他們相信富客戶，呃，?更富有。
因此，Web用戶界面大約有80％，即使沒有新的Web瀏覽器，我們也可能獲得95％。?對于大多數人來說這是足夠好的，對于那些投票開發幾乎所有重要的新應用程序作為Web應用程序的開發人員來說，這當然足夠了。
這意味著，突然之間，微軟的API并不重要。?Web應用程序不需要Windows?。
并不是說微軟沒有注意到這種情況正在發生。?他們當然做到了，當影響變得清晰時，他們猛烈踩剎車。?有希望的新技術，如HTA和DHTML，已經停止了。?Internet Explorer團隊似乎已經消失了;?幾年來他們已經完全失蹤了。?微軟決不允許DHTML比現有的更好：它對他們的核心業務，富客戶來說太危險了。?微軟最近的一個重要模因是：“?微軟正在把公司押在富客戶身上?。”你會看到有關Longhorn的每個幻燈片演示中的某個地方。?來自Avalon團隊的Joe Beda?表示，“Avalon和Longhorn一般都是微軟在地面上的股份，并表示我們相信你桌面上的電源，在當地坐在那里做很酷的東西，就會存在。?我們正在桌面上投資，我們認為這是一個好地方，我們希望我們能夠開始一陣興奮......“
問題是：現在為時已晚。
我對自己有點傷心，我自己
我自己真的有點難過。?對我而言，Web非常棒，但基于Web的應用程序具有超級，高延遲，不一致的用戶界面，這在日常可用性方面是一個巨大的倒退。?我喜歡我的富客戶端應用程序，如果我不得不使用我每天使用的應用程序的Web版本，那就太瘋狂了：Visual Studio，CityDesk，Outlook，Corel PhotoPaint，QuickBooks。?但這就是開發人員要給我們的東西。?沒有人（再次，我的意思是“少于10,000,000人”）想要再為Windows API開發。?風險投資家不會投資Windows應用程序，因為他們害怕微軟的競爭。?并且大多數用戶似乎并不像我那樣關心糟糕的Web UI。
這就是硬道理：我注意到（并向招聘人員朋友證實了這一點），紐約市的Windows API程序員知道C ++和COM編程，每年收入約為13萬美元，而典型的Web程序員使用托管代碼語言（Java，PHP， Perl，即使是ASP.NET）每年收入約為8萬美元。?這是一個巨大的差異，當我與微軟咨詢服務公司的一些朋友談到這一點時，他們承認微軟已經失去了整整一代開發人員。?雇傭具有COM經驗的人需要130,000美元的原因是因為在過去的八年左右沒有人在學習COM編程，所以你必須找到一個真正高級的人，通常他們已經在管理層，并說服他們找工作作為一個咕嚕咕嚕的程序員，處理（上帝幫助我）?編組和綽號和公寓線程和聚合和撕裂以及其他一百萬個基本上只有Don Box才能理解的東西，甚至Don Box?都不忍心看著它們更多。
就像我討厭說的那樣，很多開發人員早已轉移到網絡上并拒絕退回。大多數.NET開發人員都是ASP.NET開發人員，為Microsoft的Web服務器開發。?ASP.NET很棒;?我已經在網絡開發方面工作了十年，而且它確實比其他所有產品都領先一代。?但它是一種服務器技術，因此客戶可以使用他們想要的任何類型的桌面。?它使用Mono在Linux下運行良好。
對于微軟而言，這一切都不是好兆頭，而且由于它的API功能，它對它的利潤也是如此。?新的API是HTML，應用程序開發市場中的新贏家將是能夠讓HTML唱歌的人。
?
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/
總結
以上是生活随笔為你收集整理的【译】How Microsoft Lost the API War的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： DIY Roomba Virtual W
- 下一篇： PC 远程控制 android手机的方法