(continued from previous page)

C. The Similar Experiences of Other Firms in Dealing with Microsoft

93. Other firms in the computer industry have had encounters with Microsoft similar to the experiences of Netscape described above. These interactions demonstrate that it is Microsoft''s corporate practice to pressure other firms to halt software development that either shows the potential to weaken the applications barrier to entry or competes directly with Microsoft''s most cherished software products.

1. Intel

94. At the same time that Microsoft was trying to convince Netscape to stop developing cross?platform APIs, it was trying to convince Intel to halt the development of software that presented developers with a set of operating?system?independent interfaces.

95. Although Intel is engaged principally in the design and manufacture of microprocessors, it also develops some software. Intel''s software development efforts, which take place at the Intel Architecture Labs (``IAL''''), are directed primarily at finding useful ways to consume more microprocessor cycles, thereby stimulating demand for advanced Intel microprocessors. By early 1995, IAL was in the advanced stages of developing software that would enable Intel 80x86 microprocessors to carry out tasks usually performed by separate chips known as ``digital signal processors.'''' By enabling this migration, the software, called Native Signal Processing (``NSP'''') software, would endow Intel microprocessors with substantially enhanced video and graphics performance.

96. Intel was eager for software developers and hardware manufacturers to write software and build peripheral devices that would implement the enhanced capabilities that its microprocessors and its NSP software together offered. Intel did not believe, however, that the set of APIs and device driver interfaces (``DDIs'''') in Windows had kept pace with the growing ability of Intel''s microprocessors to deliver audio/visual content. Consequently, IAL designed its NSP software to expose Intel''s own APIs and DDIs that, when invoked by developers and hardware manufacturers, would demonstrate the multimedia capabilities of an Intel microprocessor utilizing NSP.

97. Microsoft reacted to Intel''s NSP software with alarm. First of all, the software threatened to offer ISVs and device manufacturers an alternative to waiting for Windows to provide system?level support for products that would take advantage of advances in hardware technology. More troubling was the fact that Intel was developing versions of its NSP software for non?Microsoft operating systems. The different versions of the NSP software exposed the same set of software interfaces to developers, so the more an application took advantage of interfaces exposed by NSP software, the easier it would be to port that application to non? Microsoft operating systems. In short, Intel''s NSP software bore the potential to weaken the barrier protecting Microsoft''s monopoly power.

98. Over time, Microsoft developed additional qualms about Intel''s NSP software. For instance, Intel initially designed the NSP software to be compatible with only Windows 3.1. At the time, Microsoft was preparing to release Windows 95, and the company did not want anything rekindling the interest of ISVs, equipment manufacturers, and consumers in the soon?to? be obsolescent version of Windows. More acute was Microsoft''s concern that users who received NSP software on their Windows 3.1 systems would have difficulty upgrading those systems to Windows 95. By June 1995, Intel had completed a pre?release, or ``beta,'''' version of its NSP software for Windows 95, but Microsoft worried that a commercial version would not be ready by the time OEMs began loading Windows 95.

99. Along with its concerns about contemporaneous compatibility, Microsoft also complained that Intel had not subjected its software to sufficient quality?assurance testing. Microsoft was quick to point out that if Windows users detected problems with the software that came pre?installed on their PC systems, they would blame Microsoft or the OEMs, even if fault lay with Intel. Microsoft''s concerns with compatibility and quality were genuine. Both pre? dating and over?shadowing these transient and remediable concerns, however, was a more abiding fear at Microsoft that the NSP software would render ISVs, device manufacturers, and (ultimately) consumers less dependent on Windows. Without this fear, Microsoft would not have subjected Intel to the level of pressure that it brought to bear in the summer of 1995.