微软如何输掉API战争

作者：周思博(Joel Spolsky)
译：Paul May 梅普华
Sunday, June 13, 2004
属于Joel on Software, http://www.joelonsoftware.com

这阵子你应该听过某种理论：「微软要完蛋了。只要Linux在桌上型市场有些进展，而web应用程式又取代桌上型系统的应用程式，这个强盛帝国就会崩溃了。」

虽然Linux的确是微软的心头大患，不过至少要预言这个Redmond公司灭亡还言之过早。微软银行里的现金多得不得了，而且仍是非常的赚钱，还要很久很久才可能倒。微软可以胡搞个十年才会开始有点危险，而且你永远不会知道……他们可能在最后一刻变身成刨冰公司。所以别这么快就看衰他们。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才会跳上舞台大喊「开发者、开发者、开发者、开发者。」这对微软实在是太重要了。微软没有公然发放 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团队为了维持向后相容，投入[难以置信努力](http://weblogs.asp.net/oldnewthing/archive/2003/10/15/ 55296.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写道：「有人指控微软在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开发的。

一个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間選擇？」微軟的投影片，裡頭問道：「我們為什麼要在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以及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](http://www.go- mono.com/)执行得相当好呢。

这些东西没有一个对微软有利，对微软得力于API权势的利益也一样。新的API是HTML，而能让HTML唱歌的人将会是应用程式开发市场的新赢家。