MICROSOFT对SUN实现JAVA所构成的威胁的回应
- 对于Microsoft来说，维护和加强应用程序进入壁垒的关键是保持将应用程序从Windows移植到其他平台的难度，反之亦然。1996年，Microsoft的高级管理人员意识到，用Java编程语言编写以网络为中心的应用程序的开发人员的数量已经变得很大，并且Java可能会在开发人员中越来越受欢迎。
因此，Microsoft开始对最大化用Java编写的应用程序从Windows移植到其他平台的难度感兴趣，反之亦然。
A. 为 Windows 创建破坏可移植性且与其他实现不兼容的 Java 实现
- 尽管Sun最终希望Java技术允许开发人员编写无需任何移植即可在多个操作系统上运行的应用程序，但Java类库从未公开足够的API来支持功能齐全的应用程序。因此，Java 开发人员始终需要依赖特定于平台的 API 来编写具有高级功能的应用程序。
认识到这一点，Sun赞助了一个创建软件方法的过程，该方法允许用Java编写的开发人员直接依赖于特定操作系统公开的API，同时允许他们相对轻松地将他们的应用程序移植到运行在不同操作系统上的JVM。
- 12 年 1996 月 <> 日，Sun 签署了一项协议，授予 Microsoft 分发和对 Sun 的 Java 技术进行某些修改的权利。Microsoft使用此许可证创建了自己的 Java 开发工具和自己的 Windows 兼容 Java 运行时环境。由于Sun赞助的努力背后的动机与Microsoft保持移植难度的兴趣背道而驰，Microsoft独立开发了启用“调用”“本机”Windows代码的方法，这使得移植比Sun努力制定标准的方法更加困难。Microsoft在其开发人员工具和JVM中实现了这些不同的方法。Microsoft还劝阻其商业盟友不要帮助孙的努力。
例如，盖茨在1996年<>月告诉英特尔的首席执行官，他不希望英特尔架构实验室与Sun合作开发在Windows中调用多媒体接口的方法。
- 由于它们是为启用对Windows的本机调用而定制的，并且因为它们是由具有最熟悉Windows知识的公司开发的，因此Microsoft生成的本机方法对于开发人员来说比从Sun赞助的努力中派生的方法稍微容易一些，并且使用Microsoft方法的Java应用程序往往比使用Sun的方法调用Windows API的应用程序运行得更快。然而，如果开发人员依赖于Microsoft的方法而不是Sun的方法，那么他的Java应用程序将更难从Windows兼容的JVM移植到设计用于在不同操作系统上运行的JVM。
- Microsoft可以很容易地在其开发人员工具和JVM中实现Sun的本机方法以及自己的方法，从而允许Java开发人员在速度和可移植性之间进行选择;但是，它选择只执行Microsoft方法。结果是，如果Java开发人员使用Sun方法进行本机调用，则他的应用程序将无法在Microsoft版本的Windows JVM上运行，并且如果他使用Microsoft的本机方法，则他的应用程序将不会在Microsoft版本以外的任何JVM上运行。
不兼容远非试图帮助Java开发人员更轻松地开发高性能应用程序的意外结果，而是Microsoft努力的预期结果。事实上，Microsoft随后威胁要对苹果的QuickTime使用相同的策略。Microsoft继续拒绝实施Sun的原生方法，直到1998年<>月法院命令它这样做。然后Microsoft几周就在其开发人员工具和JVM中实现了Sun的本机方法。
- 尽管 Java 类库尚未提供足够的功能来支持功能齐全的应用程序，但它们已逐渐朝着这一目标扩展。1997年，Sun添加了一个名为远程方法调用（RMI）的类库，它允许编写调用它的Java应用程序以某些有用的方式相互通信。Microsoft不愿意袖手旁观，允许Java开发人员不受阻碍地依赖新的Java类库。
Java 开发人员越能通过调用 Java 类库来满足他们对功能的需求，他们的应用程序就越可移植。Microsoft开发了一套特定于Windows的接口，以提供类似于RMI提供的功能的功能;它希望Java开发人员依赖于这种Windows特定的技术，而不是Sun的跨平台界面。因此，Microsoft拒绝将RMI作为Internet Explorer 4.0附带的Windows的Java运行时环境的标准组件。 - 它去年与Sun签署的许可协议要求Microsoft至少在其开发者网站上提供RMI。Microsoft这样做了，但关于RMI测试版，它将链接埋在一个不起眼的位置，并且忽略了在网站的索引中包含它的条目。提到RMI和任何可能访问Microsoft网站的Java开发人员寻找它，一位Microsoft员工写信给他的批准经理，“他们必须偶然发现它才能知道它在那里。我会说它被埋葬了。
- 目前尚不清楚Microsoft是否最终将RMI放在其开发者网站上更显眼的位置。即使有，RMI没有随Microsoft的WindowsJava运行时环境一起提供的事实意味着Java开发人员不能依赖它安装在消费者的PC系统上。
如果开发人员希望他们的Java应用程序调用保证存在于Windows用户系统上的通信接口，他们别无选择，只能依赖特定于Microsoft的接口而不是RMI。Microsoft努力从其余的Java类库中删除RMI，而不是简单地将其保留在原地并允许开发人员在它和Windows特定的接口之间进行选择，其唯一目的是使Java开发人员更难编写易于移植的应用程序。
- 为了增加为其Windows JVM编写的Java应用程序与其他Windows JVM之间的不兼容性，并增加将Java应用程序从Windows环境移植到其他平台的难度，Microsoft设计了Java开发人员工具，以鼓励开发人员使用某些“关键字”和“编译器指令”编写Java应用程序，这些“关键字”和“编译器指令”只能由Microsoft版本的Java运行时环境正确执行。窗户。
Microsoft鼓励开发人员使用这些扩展，方法是提供默认启用的扩展的开发人员工具，并且未能警告开发人员使用它们会导致应用程序可能无法在除Microsoft以外的任何运行时环境中正常运行，并且很难，甚至可能不可能移植到在其他平台上运行的JVM。
这一行动与Microsoft的 Thomas Reardon 在 1996 年 32 月向他的同事提出的建议相吻合：“我们应该悄悄地发展 j++ [Microsoft 的开发者工具] 共享，并假设人们会更多地利用我们的类，而从未意识到他们正在构建仅限 win1998 的 Java 应用程序。Microsoft拒绝更改其开发人员工具，直到 <> 年 <> 月，法院命令它默认禁用其关键字和编译器指令，并警告开发人员使用 Microsoft 的 Java 扩展可能会导致与非Microsoft运行时环境不兼容。
诱导开发人员使用 Java 的Microsoft实现，而不是符合 Sun 的实现
- 如果Microsoft为对抗易于移植的Java应用程序的增长所做的一切就是增加其Java实现与符合Sun标准的Java实现之间的不兼容性，那么效果可能是有限的。
因为如果Sun可以向开发人员保证，符合Sun标准的Windows兼容Java运行时环境将安装在与Microsoft版本一样多的Windows PC上，并且它将运行Java应用程序以及Microsoft，那么开发人员可能会考虑与依赖特定于Microsoft的技术相关的可移植性成本，而是使用Sun的开发人员工具编写Java应用程序。
当Netscape在1995年<>月宣布它将在每个Navigator副本中包含一个符合Sun标准的Windows JVM副本时，Sun的Java实现似乎将在Windows上实现必要的普及。 - 为了鼓励开发人员编写依赖于其Windows运行时环境版本而不是Sun兼容的运行时环境的Java应用程序，Microsoft投入了大量的工程资源来开发高性能的Windows JVM。这使得Microsoft版本的运行时环境因其技术优点而具有吸引力。
为了阻止Sun和Netscape提高Navigator附带的Windows JVM的质量，Microsoft向正在开发高性能Windows兼容JVM的英特尔施压，要求其不要与Sun或Netscape共享其工作，更不用说允许Netscape将Intel JVM与Navigator捆绑在一起了。
盖茨本人也参与了这项工作。在 2 年 1995 月 <> 日的会议上，盖茨敦促英特尔停止 IAL 开发平台级软件，他还宣布英特尔与 Sun 和 Netscape 合作为在英特尔微处理器上运行的系统开发 Java 运行时环境是威胁破坏英特尔与Microsoft之间合作的问题之一。
到1996年春天，英特尔开发了一种JVM，旨在在基于英特尔的系统上运行良好，同时符合Sun的跨平台标准。Microsoft高管于当年四月与英特尔接触，敦促英特尔不要采取任何措施允许Netscape与Navigator一起发布此JVM。 - 通过将其Windows JVM版本与Internet Explorer的每个副本捆绑在一起，并消耗其一些剩余的垄断能力，以Navigator为代价最大限度地利用Internet Explorer，Microsoft赋予其Java运行时环境独特的属性，即在庞大的Windows安装基础中保证，持久的无处不在。
正如 1997 年 1998 月的一份内部Microsoft报告所说，该公司对跨平台 Java 的反应需要“与 Windows 集成的 IE 份额”。部分由于Microsoft对Navigator的努力对Netscape的业务造成了损害，Netscape在<>年决定不再承担继续将最新的JVM与Navigator捆绑在一起所需的工程工作。
因此，它宣布，从5.0版本开始，Navigator将不再是符合Sun标准的JVM的分发工具。 - 保证每台 Windows PC 上都存在 Microsoft 的运行时环境，并且存在符合 Sun 标准的运行时环境 （Navigator） 的主要主机的可能性降低，促使许多 Java 开发人员使用 Microsoft 的开发人员工具编写他们的应用程序，因为这样做保证了这些应用程序将在最有可能安装在 Windows 用户的 PC 上的 Java 环境中运行。
由于Microsoft深思熟虑的设计决策，更多的开发人员使用Microsoft的Java开发人员工具意味着更多的Java应用程序将依赖于Microsoft运行时环境中的Windows特定技术，因此将无法移植。
- Microsoft并不满足于仅仅依靠其反导航器的努力来确保其Java运行时环境是唯一保证存在于Windows PC系统上的环境。毕竟，Netscape并不是唯一能够在用户系统上放置运行时环境副本的ISV。
许多以网络为中心的应用程序的开发人员能够将兼容的运行时环境与其应用程序捆绑在一起，就像捆绑浏览软件一样。如果正确的运行时环境已经与正确的浏览软件捆绑在一起，那么 ISV 就更加方便了。
但是，如果不是这样（在Netscape停止将运行时环境与Navigator捆绑在一起之后，ISV仍然可以单独获取所需的运行时环境，并将其与其产品的每个副本捆绑在一起。 - 将ISV视为符合Sun标准的Java运行时环境可以找到进入Windows PC系统的渠道，Microsoft诱导ISV分发Microsoft的版本而不是符合Sun的版本。首先，Microsoft将其JVM与Internet Explorer分开提供给ISV，以便那些对捆绑浏览软件不感兴趣的人仍然可以捆绑Microsoft的JVM。
Microsoft的 David Cole 在 1997 年 <> 月写给 Jim Allchin 的一封信中透露了这一步骤的动机：“我们已经同意，我们必须允许 ISV 在没有 IE 的情况下独立重新分发 Java VM。这样做的ISV被绑定到Windows中，因为这是VM工作的唯一地方，并且使它们远离Sun的API。 - Microsoft采取了进一步措施，为同意使用Microsoft的Java实现的ISV提供有价值的东西。具体来说，在1997年和1998年与数十家ISV签署的第一波协议中，Microsoft早期的Windows 98和Windows NT测试版，其他技术信息，以及使用这些ISV同意使用Microsoft版本的Windows JVM作为“默认”的某些Microsoft批准印章的权利。
Microsoft和ISV都阅读了此要求，以要求ISV确保其Java应用程序与Microsoft版本的Windows JVM兼容。确保与Microsoft的JVM兼容的唯一有效方法是使用Microsoft的Java开发人员工具，这反过来意味着使用Microsoft的方法进行本机调用，并且（除非开发人员特别谨慎和复杂）Microsoft的其他Java扩展。
因此，第一波ISV编写的Java应用程序中的很大一部分只能在Microsoft版本的Windows JVM上运行。考虑到这一点，第一波ISV没有任何理由随其Java应用程序分发除Microsoft以外的任何JVM。
因此，为了换取昂贵的技术支持和其他乏味的东西，Microsoft诱使数十个重要的ISV使其Java应用程序依赖于Windows特定的技术，并避免向Windows用户分发符合Sun标准的JVM。
该记录没有证据表明第一波协议中的相关条款除了最大化在Windows和其他平台之间移植Java应用程序的难度之外，还有任何其他目的。Microsoft仍然可以自由地要求第一波独立软件供应商遵守这一规定，直到法院于1998年<>月禁止执行该条款。 - 除了第一波协议之外，Microsoft还与至少一个ISV签订了一项协议，明确要求它重新分发Microsoft的JVM，以排除任何其他方法，并依赖Microsoft的本机方法排除任何其他方法。1998年<>月的禁令也禁止这种协议。
- Microsoft预计Java语言将成为多媒体领域的流行媒介。因此，它希望确保为提供多媒体内容而创建的Java软件不会依赖于促进可移植性的Java实现。RealNetworks开发了最流行的软件，用于创建和播放流媒体内容。因此，Microsoft试图确保Java开发人员在一定程度上依赖于RealNetworks的技术，他们不会依赖于符合Sun标准的Java实现。
因此，在18年1997月<>日与RealNetworks签订的协议中，Microsoft同意将RealNetworks的媒体播放器与Internet Explorer一起分发为条件，RealNetworks同意尽最大努力确保其播放器主要使用Windows特定的技术，而不是Sun或Netscape可能开发的任何类似界面来显示多媒体内容。
如果没有这一义务，RealNetworks就没有技术上的理由不能设计其媒体播放器来支持Microsoft的技术以及Sun或Netscape开发的技术。
尽管RealNetworks随后宣布计划继续开发自己的基础流媒体软件，但18月<>日的协议限制了该软件包含符合Sun标准的Java技术的程度。
