作者：周思博 (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才会跳上舞台 (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 c 1999-2006 by Joel Spolsky. All Rights Reserved -- * Origin: ★ 交通大学资讯科学系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>