From The Joel on Software Translation Project

微软如何输掉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则是变身成一家巨大的老牌技术顾问公司，同时恰巧也在制造便宜塑胶电话。所以只由少数几个资料就推断出微软要完蛋的理论，实在是有点夸大了。

不过大多数人并未注意到一个较不为人知的现象：微软在战略上最重要的宝物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上好的桌面应用程序比麦金塔多太多了，所以麦金塔的用户实在很难当。

而这正是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或是多种脚本语言其中之一。如果你的程序语言能让你抓一块内存来用，又不用考虑用完后要如何释放，你用的就是会管理内存的程序语言，那么你的效率会远远超过那些使用得明确管理内存的语言的程序员。当你听到某些人夸耀他们的程序语言生产力有多好时，他们的生产力可能大多是自动化内存管理所贡献的，只是他们弄错原因而已。

赛车迷可能会因而写信骂我，不过就我的经验而言，在正常驾驶时好的自排只有在一种状况下会不如手排。软件开发也是类似的：几乎在所有的状况下，自动化内存管理都比手动内存管理更好，而且能让程序员生产力提升许多。

在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）还有向后相容问题与不可能弄懂的字串回传机制全部一扫而空，取而代之的是个单一干凈只有一种字串的面向对象介面。一个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完全结束，结果还在使用的人实在太多，于是他们只好承诺会对那个老爷系统再多支持几年。

这些勇敢的新策略（.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应用程序做不好的例子：

1. 创造一个快速绘图的程序
2. 写一个能标示红色波浪底线的即时拼字检查程序
3. 在使用者按到浏览器的关闭盒时，警告使用者将会遗失其工作成果
4. 不必连到服务器来回沟通一遍，就能依据使用者的变更来更新小部份的显示，
5. 建立一个不需滑鼠的快速键盘驱动介面
6. 让大家在没有连上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执行得相当好呢。

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