|
 |
Bill DeWitt wrote:
> Simon de Vet <sde### [at] istar ca> wrote :
> >
> > "I agree" is winning, 52% to 48%!
> >
>
> So the guy presents a biased one sided article and then askes for a vote
> afterwards... It depends on what your definition of "Propaganda" is...
Well, from what I can see, he actually gave a fair article. Unless, of course,
you were complaining that he was giving an article biased in Microsoft's favor.
If you read some of the findings, it get to be quite clear what is going on.
Here are some exerpts that went out on a Java developer mailing list I'm on:
(if nothing else, skim down to the bottom and read 412.
VI. MICROSOFT'S RESPONSE TO THE THREAT POSED BY SUN'S IMPLEMENTATION
OF JAVA
386. For Microsoft, a key to maintaining and reinforcing the
applications barrier to entry has been preserving the difficulty of
porting applications from Windows to other platforms, and vice versa.
In 1996, senior executives at Microsoft became aware that the number
of developers writing network-centric applications in the Java
programming language had become significant, and that Java was likely
to increase in popularity among developers. Microsoft therefore became
interested in maximizing the difficulty with which applications
written in Java could be ported from Windows to other platforms, and
vice versa.
A. Creating a Java Implementation for Windows that Undermined
Portability and Was Incompatible with Other Implementations
387. Although Sun intended Java technologies eventually to allow
developers to write applications that would run on multiple operating
systems without any porting, the Java class libraries have never
exposed enough APIs to support full-featured applications. Java
developers have thus always needed to rely on platform-specific APIs
in order to write applications with advanced functionality.
Recognizing this, Sun sponsored a process for the creation of a
software method that would allow developers writing in Java to rely
directly upon APIs exposed by a particular operating system in a way
that would nevertheless allow them to port their applications with
relative ease to JVMs running on different operating systems.
388. On March 12, 1996, Sun signed an agreement granting Microsoft the
right to distribute and make certain modifications to Sun's Java
technologies. Microsoft used this license to create its own Java
development tools and its own Windows-compatible Java runtime
environment. Because the motivation behind the Sun-sponsored effort
ran counter to Microsoft's interest in preserving the difficulty of
porting, Microsoft independently developed methods for enabling
"calls" to "native" Windows code that made porting more difficult than
the method that Sun was striving to make standard. Microsoft
implemented these different methods in its developer tools and in its
JVM. Microsoft also discouraged its business allies from aiding Sun's
effort. For example, Gates told Intel's CEO in June 1996 that he did
not want the Intel Architecture Labs cooperating with Sun to develop
methods for calling upon multimedia interfaces in Windows.
389. Since they were custom-built for enabling native calls to
Windows, and because they were developed by the firm with the most
intimate knowledge of Windows, the native methods that Microsoft
produced were slightly easier for developers to use than the method
that derived from the Sun-sponsored effort, and Java applications
using Microsoft's methods tended to run faster than ones calling upon
Windows APIs with Sun's method. If a developer relied on Microsoft's
methods rather than Sun's, however, his Java application would be much
more difficult to port from the Windows-compatible JVM to JVMs
designed to run on different operating systems.
390. Microsoft easily could have implemented Sun's native method along
with its own in its developer tools and its JVM, thereby allowing Java
developers to choose between speed and portability; however, it
elected instead to implement only the Microsoft methods. The result
was that if a Java developer used the Sun method for making native
calls, his application would not run on Microsoft's version of the
Windows JVM, and if he used Microsoft's native methods, his
application would not run on any JVM other than Microsoft's version.
Far from being the unintended consequence of an attempt to help Java
developers more easily develop high-performing applications,
incompatibility was the intended result of Microsoft's efforts. In
fact, Microsoft would subsequently threaten to use the same tactic
against Apple's QuickTime. Microsoft continued to refuse to implement
Sun's native method until November 1998, when a court ordered it to do
so. It then took Microsoft only a few weeks to implement Sun's native
method in its developer tools and JVM.
391. Although the Java class libraries have yet to provide enough
functionality to support full-featured applications, they have
gradually expanded toward that goal. In 1997, Sun added a class
library called Remote Method Invocation, or "RMI," which allowed Java
applications written to call upon it to communicate with each other in
certain useful ways. Microsoft was not willing to stand by and allow
Java developers to rely on new Java class libraries unimpeded. The
more that Java developers were able to satisfy their need for
functionality by calling upon the Java class libraries, the more
portable their applications would become. Microsoft had developed a
set of Windows-specific interfaces to provide functionality analogous
to the functionality RMI offered; it wanted Java developers to rely on
this Windows-specific technology rather than Sun's cross-platform
interface. Microsoft thus refused to include RMI as a standard
component of the Java runtime environment for Windows that it shipped
with Internet Explorer 4.0.
392. The license agreement it had signed with Sun the previous year
obligated Microsoft to offer RMI, at a minimum, on its developer Web
site. Microsoft did so, but with respect to the RMI beta release, it
buried the link in an obscure location and neglected to include an
entry for it in the site's index. Referring to RMI and any Java
developers who might access Microsoft's site looking for it, a
Microsoft employee wrote to his approving manager, "They'll have to
stumble across it to know it's there. . . . I'd say it's pretty
buried."
393. It is unclear whether Microsoft ultimately placed RMI in a more
prominent place on its developer Web site. Even if it did, the fact
that RMI was not shipped with Microsoft's Java runtime environment for
Windows meant that Java developers could not rely on its being
installed on consumers' PC systems. If developers wanted their Java
applications to call upon communications interfaces guaranteed to be
present on Windows users' systems, they had no choice but to rely on
the Microsoft-specific interfaces instead of RMI. Microsoft undertook
the effort to remove RMI from the rest of the Java class libraries,
instead of simply leaving it in place and allowing developers to
choose between it and Windows-specific interfaces, for the sole
purpose of making it more difficult for Java developers to write
easily portable applications.
394. In a further effort intended to increase the incompatibility
between Java applications written for its Windows JVM and other
Windows JVMs, and to increase the difficulty of porting Java
applications from the Windows environment to other platforms,
Microsoft designed its Java developer tools to encourage developers to
write their Java applications using certain "keywords" and "compiler
directives" that could only be executed properly by Microsoft's
version of the Java runtime environment for Windows. Microsoft
encouraged developers to use these extensions by shipping its
developer tools with the extensions enabled by default and by failing
to warn developers that their use would result in applications that
might not run properly with any runtime environment other than
Microsoft's and that would be difficult, and perhaps impossible, to
port to JVMs running on other platforms. This action comported with
the suggestion that Microsoft's Thomas Reardon made to his colleagues
in November 1996: "[W]e should just quietly grow j++ [Microsoft's
developer tools] share and assume that people will take more advantage
of our classes without ever realizing they are building win32-only
java apps." Microsoft refused to alter its developer tools until
November 1998, when a court ordered it to disable its keywords and
compiler directives by default and to warn developers that using
Microsoft's Java extensions would likely cause incompatibilities with
non-Microsoft runtime environments.
B. Inducing Developers to Use the Microsoft Implementation of Java
Rather than Sun-Compliant Implementations
395. If all Microsoft had done to combat the growth of easily portable
Java applications had been to increase the incompatibility between its
Java implementation and ones complying with Sun's standards, the
effect might have been limited. For if Sun could have assured
developers that a Windows-compatible Java runtime environment that
complied with Sun's standards would be installed on as many Windows
PCs as Microsoft's version, and that it would run Java applications as
well as Microsoft's, developers might have considered the cost in
portability associated with relying on Microsoft-specific technologies
and instead written their Java applications using Sun's developer
tools. When Netscape announced in May 1995 that it would include with
every copy of Navigator a copy of a Windows JVM that complied with
Sun's standards, it appeared that Sun's Java implementation would
achieve the necessary ubiquity on Windows.
396. Determined to induce developers to write Java applications that
relied on its version of the runtime environment for Windows rather
than on Sun-compliant ones, Microsoft made a large investment of
engineering resources to develop a high-performance Windows JVM. This
made Microsoft's version of the runtime environment attractive on its
technical merits. To hinder Sun and Netscape from improving the
quality of the Windows JVM shipped with Navigator, Microsoft pressured
Intel, which was developing a high-performance Windows-compatible JVM,
to not share its work with either Sun or Netscape, much less allow
Netscape to bundle the Intel JVM with Navigator. Gates was himself
involved in this effort. During the August 2, 1995 meeting at which he
urged Intel to halt IAL's development of platform-level software,
Gates also announced that Intel's cooperation with Sun and Netscape to
develop a Java runtime environment for systems running on Intel's
microprocessors was one of the issues threatening to undermine
cooperation between Intel and Microsoft. By the spring of 1996, Intel
had developed a JVM designed to run well on Intel-based systems while
complying with Sun's cross-platform standards. Microsoft executives
approached Intel in April of that year and urged that Intel not take
any steps toward allowing Netscape to ship this JVM with Navigator.
397. By bundling its version of the Windows JVM with every copy of
Internet Explorer and expending some of its surplus monopoly power to
maximize the usage of Internet Explorer at Navigator's expense,
Microsoft endowed its Java runtime environment with the unique
attribute of guaranteed, enduring ubiquity across the enormous Windows
installed base. As one internal Microsoft presentation from January
1997 put it, the company's response to cross-platform Java entailed
"[i]ncreased IE share -- integrat[ion] with Windows." Partly as a
result of the damage that Microsoft's efforts against Navigator
inflicted on Netscape's business, Netscape decided in 1998 that it
could no longer afford to do the engineering work necessary to
continue bundling up-to-date JVMs with Navigator. Consequently, it
announced that, starting with version 5.0, Navigator would cease to be
a distribution vehicle for JVMs compliant with Sun's standards.
398. The guaranteed presence of Microsoft's runtime environment on
every Windows PC and the decreasing likelihood that the primary host
of the Sun-compliant runtime environment (Navigator) would be present,
induced many Java developers to write their applications using
Microsoft's developer tools, for doing so guaranteed that those
applications would run in the Java environment most likely to be
installed on a Windows user's PC. Owing to Microsoft's deliberate
design decisions, more developers using Microsoft's Java developer
tools meant that more Java applications would rely on the Windows-
specific technologies in Microsoft's runtime environment and thus
would not be portable.
399. Microsoft was not content to rely solely on its anti-Navigator
efforts to ensure that its Java runtime environment would be the only
one guaranteed to be present on Windows PC systems. After all,
Netscape was not the only ISV capable of placing copies of a runtime
environment on users' systems. Many developers of network-centric
applications were just as capable of bundling compatible runtime
environments with their applications as they were of bundling browsing
software. If the right runtime environment already came bundled with
the right browsing software, all the more convenient for the ISV. If
not (as would increasingly be the case after Netscape stopped bundling
a runtime environment with Navigator), though, the ISV could still
separately obtain the desired runtime environment and bundle it with
every copy of its product.
400. Recognizing ISVs as a channel through which Java runtime
environments that complied with Sun's standards could find their way
onto Windows PC systems, Microsoft induced ISVs to distribute
Microsoft's version instead of a Sun-compliant one. First, Microsoft
made its JVM available to ISVs separately from Internet Explorer so
that those uninterested in bundling browsing software could
nevertheless bundle Microsoft's JVM. Microsoft's David Cole revealed
the motivation for this step in a message he wrote to Jim Allchin in
July 1997: "[W]e've agreed that we must allow ISVs to redistribute the
Java VM standalone, without IE. ISVs that do this are bound into
Windows because that's the only place the VM works, and it keeps them
away from Sun's APIs."
401. Microsoft took the further step of offering valuable things to
ISVs that agreed to use Microsoft's Java implementation. Specifically,
in the First Wave agreements that it signed with dozens of ISVs in
1997 and 1998, Microsoft conditioned early Windows 98 and Windows NT
betas, other technical information, and the right to use certain
Microsoft seals of approval on the agreement of those ISVs to use
Microsoft's version of the Windows JVM as the "default." Microsoft and
the ISVs all read this requirement to obligate the ISVs to ensure that
their Java applications were compatible with Microsoft's version of
the Windows JVM. The only effective way to ensure compatibility with
Microsoft's JVM was to use Microsoft's Java developer tools, which in
turn meant using Microsoft's methods for making native calls and
(unless the developers were especially wary and sophisticated)
Microsoft's other Java extensions. Thus, a very large percentage of
the Java applications that the First Wave ISVs wrote would run only on
Microsoft's version of the Windows JVM. With that in mind, the First
Wave ISVs would not have any reason to distribute with their Java
applications any JVM other than Microsoft's. So, in exchange for
costly technical support and other blandishments, Microsoft induced
dozens of important ISVs to make their Java applications reliant on
Windows-specific technologies and to refrain from distributing to
Windows users JVMs that complied with Sun's standards. The record
contains no evidence that the relevant provision in the First Wave
agreements had any purpose other than to maximize the difficulty of
porting Java applications between Windows and other platforms.
Microsoft remained free to hold the First Wave ISVs to this provision
until a court enjoined its enforcement in November 1998.
402. In addition to the First Wave agreements, Microsoft entered an
agreement with at least one ISV that explicitly required it to
redistribute Microsoft's JVM to the exclusion of any other and to rely
upon Microsoft's native methods to the exclusion of any other methods.
Such agreements were also prohibited by the November 1998 injunction.
403. Microsoft anticipated that the Java language would become a
popular medium in the multimedia arena. It thus wanted to ensure that
the Java software created to deliver multimedia content would not rely
on Java implementations that fostered portability. RealNetworks
developed the most popular software for the creation and play-back of
streaming multimedia content. Therefore, Microsoft sought to ensure
that, to the extent Java developers relied on RealNetworks'
technologies, they would not be relying on a Java implementation that
complied with Sun's standards. So, in the July 18, 1997 agreement that
it entered with RealNetworks, Microsoft conditioned its agreement to
distribute RealNetworks' media player with Internet Explorer on
RealNetworks' agreement to exert its best efforts to ensure that its
player primarily use Windows-specific technology, rather than any
analogous interfaces that Sun or Netscape might develop, to display
multimedia content. Absent this obligation, there would have been no
technical reason why RealNetworks could not have designed its media
player to support both Microsoft's technologies and ones developed by
Sun or Netscape. Although RealNetworks subsequently announced that it
planned to continue developing its own fundamental streaming software,
the July 18 agreement limited the extent to which that software would
include Java technologies that complied with Sun's standards.
C. Thwarting the Expansion of the Java Class Libraries
404. As discussed above, Microsoft's effort to lock developers into
its Windows- specific Java implementation included actions designed to
discourage developers from taking advantage of Java class libraries
such as RMI. Microsoft went further than that, however. In pursuit of
its goal of minimizing the portability of Java applications, Microsoft
took steps to thwart the very creation of cross-platform Java
interfaces. The incorporation of greater functionality into the Java
class libraries would have increased the portability of the
applications that relied on them, while simultaneously encouraging
developers to use Sun-compliant implementations of Java. In one
instance of this effort to stunt the growth of the Java class
libraries, Microsoft used threats to withhold Windows operating-system
support from Intel's microprocessors and offers to include Intel
technology in Windows in order to induce Intel to stop aiding Sun in
the development of Java classes that would support innovative
multimedia functionality.
405. In November 1995, Microsoft's Paul Maritz told a senior Intel
executive that Intel's optimization of its multimedia software for
Sun's Java standards was as inimical to Microsoft as Microsoft's
support for non-Intel microprocessors would be to Intel. It was not
until 1997, though, that Microsoft prevailed upon Intel to not support
Sun's development of Java classes that would have allowed developers
to include certain multimedia features in their Java applications
without sacrificing portability.
406. In February 1997, one of Intel's competitors, called AMD,
solicited support from Microsoft for its "3DX" technology, which
provided sophisticated multimedia support for games. Microsoft's
Allchin asked Gates whether Microsoft should support 3DX, despite the
fact that Intel would oppose it. Gates responded: "If Intel has a real
problem with us supporting this then they will have to stop supporting
Java Multimedia the way they are. I would gladly give up supporting
this if they would back off from their work on JAVA which is terrible
for Intel." Near the end of March, Allchin sent another message to
Gates and Maritz. In it he wrote, "I am positive that we must do a
direct attack on Sun (and probably Oracle). . . . Between ourselves
and our partners, we can certainly hurt their (certainly Sun's)
revenue base. . . . We need to get Intel to help us. Today, they are
not." Two months later, Eric Engstrom, a Microsoft executive with
responsibility for multimedia development, wrote to his superiors that
one of Microsoft's goals was getting "Intel to stop helping Sun create
Java Multimedia APIs, especially ones that run well (ie native
implementations) on Windows." Engstrom proposed achieving this goal by
offering Intel the following deal: Microsoft would incorporate into
the Windows API set any multimedia interfaces that Intel agreed to not
help Sun incorporate into the Java class libraries. Engstrom's efforts
apparently bore fruit, for he testified at trial that Intel's IAL
subsequently stopped helping Sun to develop class libraries that
offered cutting-edge multimedia support.
D. The Effect of Microsoft's Efforts to Prevent Java from Diminishing
the Applications Barrier to Entry
407. Had Microsoft not been committed to protecting and enhancing the
applications barrier to entry, it might still have developed a high-
performance JVM and enabled Java developers to call upon Windows APIs.
Absent this commitment, though, Microsoft would not have taken efforts
to maximize the difficulty of porting Java applications written to its
implementation and to drastically limit the ability of developers to
write Java applications that would run in both Microsoft's version of
the Windows runtime environment and versions complying with Sun's
standards. Nor would Microsoft have endeavored to limit Navigator's
usage share, to induce ISVs to neither use nor distribute non-
Microsoft Java technologies, and to impede the expansion of the Java
class libraries, had it not been determined to discourage developers
from writing applications that would be easy to port between Windows
and other platforms. Microsoft's dedication to the goal of protecting
the applications barrier to entry is highlighted by the fact that its
efforts to create incompatibility between its JVM and others resulted
in fewer applications being able to run on Windows than otherwise
would have. Microsoft felt it was worth obstructing the development of
Windows-compatible applications where those applications would have
been easy to port to other platforms. It is not clear whether, absent
Microsoft's interference, Sun's Java efforts would by now have
facilitated porting between Windows and other platforms enough to
weaken the applications barrier to entry. What is clear, however, is
that Microsoft has succeeded in greatly impeding Java's progress to
that end with a series of actions whose sole purpose and effect were
to do precisely that.
VII. THE EFFECT ON CONSUMERS OF MICROSOFT'S EFFORTS TO PROTECT THE
APPLICATIONS BARRIER TO ENTRY
408. The debut of Internet Explorer and its rapid improvement gave
Netscape an incentive to improve Navigator's quality at a competitive
rate. The inclusion of Internet Explorer with Windows at no separate
charge increased general familiarity with the Internet and reduced the
cost to the public of gaining access to it, at least in part because
it compelled Netscape to stop charging for Navigator. These actions
thus contributed to improving the quality of Web browsing software,
lowering its cost, and increasing its availability, thereby
benefitting consumers.
409. To the detriment of consumers, however, Microsoft has done much
more than develop innovative browsing software of commendable quality
and offer it bundled with Windows at no additional charge. As has been
shown, Microsoft also engaged in a concerted series of actions
designed to protect the applications barrier to entry, and hence its
monopoly power, from a variety of middleware threats, including
Netscape's Web browser and Sun's implementation of Java. Many of these
actions have harmed consumers in ways that are immediate and easily
discernible. They have also caused less direct, but nevertheless
serious and far-reaching, consumer harm by distorting competition.
410. By refusing to offer those OEMs who requested it a version of
Windows without Web browsing software, and by preventing OEMs from
removing Internet Explorer -- or even the most obvious means of
invoking it -- prior to shipment, Microsoft forced OEMs to ignore
consumer demand for a browserless version of Windows. The same actions
forced OEMs either to ignore consumer preferences for Navigator or to
give them a Hobson's choice of both browser products at the cost of
increased confusion, degraded system performance, and restricted
memory. By ensuring that Internet Explorer would launch in certain
circumstances in Windows 98 even if Navigator were set as the default,
and even if the consumer had removed all conspicuous means of invoking
Internet Explorer, Microsoft created confusion and frustration for
consumers, and increased technical support costs for business
customers. Those Windows purchasers who did not want browsing software
-- businesses, or parents and teachers, for example, concerned with
the potential for irresponsible Web browsing on PC systems -- not only
had to undertake the effort necessary to remove the visible means of
invoking Internet Explorer and then contend with the fact that
Internet Explorer would nevertheless launch in certain cases; they
also had to (assuming they needed new, non-browsing features not
available in earlier versions of Windows) content themselves with a PC
system that ran slower and provided less available memory than if the
newest version of Windows came without browsing software. By
constraining the freedom of OEMs to implement certain software
programs in the Windows boot sequence, Microsoft foreclosed an
opportunity for OEMs to make Windows PC systems less confusing and
more user-friendly, as consumers desired. By taking the actions listed
above, and by enticing firms into exclusivity arrangements with
valuable inducements that only Microsoft could offer and that the
firms reasonably believed they could not do without, Microsoft forced
those consumers who otherwise would have elected Navigator as their
browser to either pay a substantial price (in the forms of
downloading, installation, confusion, degraded system performance, and
diminished memory capacity) or content themselves with Internet
Explorer. Finally, by pressuring Intel to drop the development of
platform-level NSP software, and otherwise to cut back on its software
development efforts, Microsoft deprived consumers of software
innovation that they very well may have found valuable, had the
innovation been allowed to reach the marketplace. None of these
actions had pro-competitive justifications.
411. Many of the tactics that Microsoft has employed have also harmed
consumers indirectly by unjustifiably distorting competition. The
actions that Microsoft took against Navigator hobbled a form of
innovation that had shown the potential to depress the applications
barrier to entry sufficiently to enable other firms to compete
effectively against Microsoft in the market for Intel-compatible PC
operating systems. That competition would have conduced to consumer
choice and nurtured innovation. The campaign against Navigator also
retarded widespread acceptance of Sun's Java implementation. This
campaign, together with actions that Microsoft took with the sole
purpose of making it difficult for developers to write Java
applications with technologies that would allow them to be ported
between Windows and other platforms, impeded another form of
innovation that bore the potential to diminish the applications
barrier to entry. There is insufficient evidence to find that, absent
Microsoft's actions, Navigator and Java already would have ignited
genuine competition in the market for Intel-compatible PC operating
systems. It is clear, however, that Microsoft has retarded, and
perhaps altogether extinguished, the process by which these two
middleware technologies could have facilitated the introduction of
competition into an important market.
412. Most harmful of all is the message that Microsoft's actions have
conveyed to every enterprise with the potential to innovate in the
computer industry. Through its conduct toward Netscape, IBM, Compaq,
Intel, and others, Microsoft has demonstrated that it will use its
prodigious market power and immense profits to harm any firm that
insists on pursuing initiatives that could intensify competition
against one of Microsoft's core products. Microsoft's past success in
hurting such companies and stifling innovation deters investment in
technologies and businesses that exhibit the potential to threaten
Microsoft. The ultimate result is that some innovations that would
truly benefit consumers never occur for the sole reason that they do
not coincide with Microsoft's self-interest.
Post a reply to this message
|
|
