【译】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/