# 四十二、微软公司是如何败北API之战的
这阵子你应该听过某种理论:「微软要完蛋了。只要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 Ballme「才会跳上舞台大喊「开发 者、开发者、开发者、开发者。」这对微软实在是太重要了。微软没有公然发放 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团队为了维持向后相 容,投入难以置信努力的故事:
由客户观点来看看这个情境。你买了程序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写道:「有人指控微软在0S 升级时恶意地妨害应用程序时我会觉得很生气。如果有任何程序不能在Windows 95执行,我会视为个人的失败。我有很多个晚上没睡去修正别人的程序,只是为 了让它们能在Windows 95执行。」
很多开发人员和工程师都不同意这种作法。他们认为如果应用程序做了坏事或依 赖某些未公开的行为,应该让它们在OS升级后直接挂掉。苹果公司的麦金塔OS 开发人员一直都在这个阵营。这也是很少麦金塔早期的程序还能动的原因。举例 来说,很多开发人员为了加速自己的麦金塔应用程序,会把中断跳跃表的指标 复制出来直接呼叫,而不按正常方法使用处理器的中断功能。虽然苹果的官方麦 金塔程序设计圣经/ns/de 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 Playe「、以及 Sharepoint… Sharepoint!这个没夜人有的东西名符其实的有一大堆壮观的夕A 斑关联,当你要把应用程序发行给付钱的客户时,每个关联都会变成大麻烦,而且没有办法弄好。这种事的技术性名称叫DLL地狱。在我这里能动,为什么在那 里不会动了?
Raymond Chen阵营相信,让开发人员写一次程序能到处(好吧,在所有的Wi ndows 上)执行,可以让他们更容易做事。而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。
而现在秘密终于揭露,0S团队也心领神会,决定不再为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的宣传 是以关系数据库方式制作文件系统,以达成搜寻功能的一种作法,却忽略了事实 上要达成搜寻功能的真实作法就是要达成搜寻功康Ct/?e rea/ way to ma/ce searc^/ng wor/c /s by ma/c/ng searc^/ng wor/c)。不要让我替所有档案输入提 示数据然后用查询语言去搜寻。只要帮我个忙去搜寻该死游硬盘,決遽姻找至夕我 打的字符串,随便你用全文检索或其他W73年就有的技术。
## 自动排档获得最后胜利
不想把我想错了…我认为.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个字节,函数会传回「配置内存不足」的讯息,顺便还告诉你需要配置多少内存。这还是简单的情形,如果运气不好呼叫到的函数要传回字符审游 审/f或是整个长度不定的结构就更麻烦了。不管如何,像开档案写入字符串然后 关闭档案之类简单的操作,直接呼叫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服务器上执行并不憲要W/’ndows游客户端系统。这 正是个关键点,后面写到web时会深入探讨。
## 噢,等一下,还有其他东西要出来!
现在微软有太多的开发人员在做事,彻底重做整个Windows API还不够看,他们 必须重做两次。去年的PDC中他们预先发表了下一个重大的操作系统改版,这个 代号Aon^orn的系统除了其他东西之外,将会有一组代码为Aw/on的全新使用 接口 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, 再按Ct「l+Ente「就好了。兼容性问题还有与其他软件相冲的问题都少太多了。产 品所有的用户都在用相同的版本,所以你永远不必支持各种旧版本。你可以用 任何喜欢的开发环境,因为只要装在自己的服务器上执行就好了。在这个星/发上 几乎每台还可以用的计算机,自然而然都能用你的应用程序。而你客户的数据也 很理所当然能用于这星球上任何一台还可以的计算机上。
不过这必须付出使用接口的平顺作为代价。下面是几个web应用程序做不好的例子:
1. 创造一个快速绘图的程序
2. 写一个能标示红色波浪底线的实时拼写检查
3. 在使用者按到浏览器的关闭盒时,警告使用者将会遗失其工作成果
4. 不必连到服务器来回沟通一遍,就能依据使用者的变更来更新小部份的显 示,
5. 建立一个不需鼠标的快捷键盘驱动接口
6. 让大家在没有连上Internet时继续作业
这些都不算大问题,其中有些很快就会被聪明的Javascript开发人员解决。有两 个新的web应用程序Gmail以及Oddpost (都是电邮程序)做得相当不错,避开或 完全解决了部份的问题。另外使用者似乎也不在意UI小问题或web接口的缓慢。 不知道为什么,不管我如何努力宣扬rich client会,呃,比较丰富,我认识的 人几乎全都对web式的电子邮件软件十分满意。
所以Web使用接口已经有80分了,就算不靠新的web浏览器还是有机会达成95分。 这对大多数人来说已经够好了,当然对开发人员来说也够了,而且他们也已经实 际把几乎所有重要的新应用程序都写成web应用程序。
这表示微软的API突然间已经不那么重要了。Web#不憲要W/ndows。
微软并不是没注意到这件事发生。他们当然知道,所以他们在局势浮现时就猛踩 煞车。他们不再在未来计划里承诺像HTA和DHTML这类的新技术。Internet Explore「团队似乎也消失了;他们有好几年似乎完全没有动作。微软不可能容许 DHTML变得比现在更好,这对他们的核心事业rich client来说实在太危险了。微 软最近的重大思想基因(memo)是:「微软把公司放未来齡在rich c/ient上。」 这句话会遍布Longhorn相关的每页简报上。来自Avalon团队的Joe Beda说道: 「Avalon (大体上还有Longhorn)是微软的基石。这句话表不我们相信你桌面的 威力,能够完成各种了不起的东西,而且是不可或许的。我们正在持续投入桌面, 我们认为这会是个好地方,而且我们希望自己能启动一波振奋…」
问题是现在已经太迟了。
## 我本身对这有一点点难过
我本身对这真的有一点点难过。对我来说Web是很不错,不过Web应用程序的使用 接口既烂又慢也不一致,就日常使用来说实在是倒退一大步。我爱我的rich c l ient应用程序,如果日常使用的应用程序(Visual Stud io、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 thread i ng、aggregate、tearoff,还 W其 他一百万件基本上只有Don Dox会的东西。事实上连Don Box都无法忍受再回来看 这些东西。
虽然我很不想这样说,不过大量的开发人员早就移到web而且拒绝再回来。大部 份的.NET开发人员都是用ASP.NET针对微软的web伺服器进行开发。ASP.NET很出 色。我从事web开发已经十年,而它真的是比其他工具先进一个世代。不过ASP.NET 是服务器技术,所以客户端可以用任意的桌面系统。何况ASP.NET还能在Linux 上用Mono执行得相当好呢。
这些东西没有一个对微软有利,对微软得力于API权势的利益也一样。新的API 是HTML,而能让HTML唱歌的人将会是应用程序开发市场的新赢家。
- 第一部分 位与字节:编程实践点滴
- 一、语言的选择
- 二、深入底层
- 三、joel测试:改进代码的12个步骤
- 四、每一位软件开发人员必须、绝对要至少具备UNICODE 与字符集知识(没有任何例外!)
- 五、轻松写就功能规格说明书 - 第1节:为什么烦心?
- 六、轻松写就功能规格说明书 - 第2节:什么是规格说明书?
- 七、轻松写就功能规格说明书 - 第3节:但是……如何?
- 八、轻松写就功能规格说明书 - 第4节:技巧
- 九、轻松制订软件进度表
- 十、每日连编是朋友
- 十一、难伺候的故障修复
- 十二、软件开发中的5个世界
- 十三、稿纸原型开发
- 十四、不要被太空架构师所吓倒
- 十五、开火与运动
- 十六、人员技能
- 十七、源于计算机学科的三个错误思想
- 十八、二元文化
- 十九、自动获取用户故障报表
- 第二部分 开发人员的管理
- 二十、面试游击指南
- 二十一、重金激励害多利少
- 二十、二不配备测试人员的五个首要(错误)原因
- 二十三、任务换人有害无益
- 二十四、绝不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序设计界的LordPalmerston
- 二十八、评测
- 第三部分 Joel对常态问题的遐想
- 二十九、RickChapman解读愚昧
- 三十、在这个国家狗是干什么的? 我们有多么天真?
- 三十一、作为哼哈二将,只管去做事
- 三十二、两个故事
- 三十三、巨无霸麦当劳与天才厨师JamieOliver
- 三十四、没有什么像IT看起来那么简单
- 三十五、提防非自主开发综合症
- 三十六、策略I:BEN&JERRY公司与AMAZON
- 三十七、策略II:鸡与蛋问题
- 三十八、策略III:让我回去!
- 三十九、策略IV:大件与80/20神话
- 四十、策略V:公开源代码的经济因素
- 四十一、墨菲法则肆掠的礼拜
- 四十二、微软公司是如何败北API之战的
- 第四部分 对.NET稍多的评说
- 四十三、微软精神失常了
- 四十四、我们的.NET对策
- 四十五、请问,我可以使用连接程序吗