Page

I. INTRODUCTION *

II. RESPONSE TO MICROSOFT¹S "STATEMENTS OF UNDISPUTED FACTS" *

II. STATEMENT OF ADDITIONAL MATERIAL FACTS *

IV. SUMMARY JUDGMENT STANDARD *

V. ARGUMENT *

VI. CONCLUSION *

Page

Plaintiff Caldera, Inc. respectfully submits this Memorandum in Opposition to the following three motions:

1. Defendant¹s Motion for Partial Summary Judgment on Plaintiff¹s "Predisclosure" Claim ("Microsoft¹s Beta Blacklist Memo.");
2. Defendant¹s Motion for Partial Summary Judgment on Plaintiff¹s Alleged "Intentional Incompatibilities" ("Microsoft¹s Intentional Incompatibilities Memo."); and,
3. Defendant¹s Motion for Partial Summary Judgment on Plaintiff¹s Claim of "Perceived Incompatibilities" ("Microsoft¹s AARD Code Memo.").

1. INTRODUCTION

By the late 1980s, Microsoft¹s computer desktop operating system, MS-DOS, was a monopoly "gold mine," upon which Microsoft relied for the majority of its profits. Starting in 1988, DRI, and later Novell, threatened Microsoft¹s DOS monopoly by releasing successive versions of DR DOS, its competing operating system, that were both better and cheaper than MS-DOS. Microsoft responded by engaging in the pattern of predatory acts alleged in Caldera¹s First Amended Complaint.

A key component of Microsoft¹s anticompetitive scheme was to persuade the market that DR DOS was incompatible with Microsoft Windows. Windows was, by all accounts, the single most important application for any DOS to be capable of running during this time period‹and Microsoft knew it. Microsoft also knew that DR DOS was fully compatible with Windows 3.0. Microsoft undertook a plan to ensure that DR DOS would not be fully compatible with the next major release of Windows, Windows 3.1‹and that the market would know it‹by:

• Announcing publicly that DR DOS would not be compatible with Windows 3.1 (See Statement of Additional Material Facts, ¶¶ 22-25, below);
• Blacklisting DRI from the Windows 3.1 beta program, in order to guarantee DRI would not be able to fix incompatibilities during the lengthy, well-publicized Windows 3.1 beta cycle (see id., ¶¶ 26-37); and,
• Coding software incompatibilities between Windows 3.1 and DR DOS including code that prevented users from setting up Windows on DR DOS, code that specifically detected DR DOS and then refused to run, and code that displayed false error messages when it detected DR DOS‹and Microsoft blamed these problems on DR DOS (see id., ¶¶ 38-76).

Each of these predatory acts contributed to creating fear, uncertainty and doubt that DR DOS could not run Windows 3.1 and future versions of Windows. And each act reinforced the other related acts. In combination, these acts materially contributed to eliminating DR DOS as a viable competitor in the desktop operating system market.

Microsoft attempts to "divide and conquer" Caldera¹s Section 2 claim by making separate motions for partial summary judgment directed at each related aspect of Microsoft¹s predatory conduct. Apparently, Microsoft hopes that if each bad act is viewed in isolation the nature of its scheme will not be obvious. In any event, the Tenth Circuit has rejected defendants¹ attempts to take a piecemeal approach in considering Section 2 claims:

Aspen Skiing Co v. Aspen Highlands Skiing Corp., 738 F.2d 1509, 1522 n.18.

This Memorandum summarizes evidence‹much of it out of the mouths of Microsoft¹s senior executives‹that proves Microsoft engaged in a carefully planned and coordinated series of acts which were intended to, and did, exclude DR DOS as a competitor in the desktop operating system market. If Microsoft is correct, i.e., if Microsoft is entitled to summary judgment on Caldera¹s Section 2 claims, then that means the law permits a monopolist to exercise its market power in one market to foreclose competition in another by: secretly making its product incompatible with its competitor¹s complementary product; blaming the incompatibilities on its competitor; precluding the competitor from access to the product causing the incompatibility; and, hiding all of this conduct by doing things such as encrypting code and secretly disabling tools that would help in uncovering the predatory conduct. The Sherman Act does not, and never has, permitted this sort of anticompetitive conduct and Microsoft offers no good reason this Court should permit it.

Microsoft has unlawfully maintained its monopoly by use of exclusionary conduct that does not "further competition on the merits or does so in an unnecessarily restrictive way." Aspen Skiing Co. v. Aspen Highlands Skiing Corp. 472 U.S. 585, 605 n.32 (1985). Its summary judgment motions should be denied.

1. RESPONSE TO MICROSOFT¹S "STATEMENTS OF UNDISPUTED FACTS"

Caldera responds to Microsoft¹s numbered paragraphs as follows:

1. In response to paragraph 1, Caldera admits that DRI developed DR DOS and that DR DOS competed with MS-DOS from 1988 through 1994.
2. Caldera denies paragraph 2. Microsoft suggests that DRI was contemplating developing a Windows competitor when DRI requested to participate in the Windows 3.1 beta program. The facts are otherwise. In late January 1990, DRI and ASCII Corporation of Japan, a long-time partner of DRI, jointly undertook a study to determine the feasibility of developing a graphical user interface ("GUI") that could compete with Microsoft¹s evolving Windows product. See Deposition of Stephen Tucker ("Tucker Dep.") at 97, Record Support, v.4 to Consolidated Statement of Facts. Caldera and ASCII Corporation commenced and conducted the study, named "Cutlass," taking great care to prevent any legal challenges by Microsoft based on DRI¹s participation in the Windows 3.0 beta program. Deposition of Phil Balma ("Balma Dep.") at 106, attached as Ex. 1 to the Declaration of Lynn M. Engel ("Engel Decl."); Tucker Dep. at 113-15, Record Support, v.4 to Consolidated Statement of Facts. The majority of the Cutlass Study work was completed over a 2-3 month period in 1990. See id. at 135. Cutlass was strictly a feasibility study and did not result in the development of a product, or even a prototype. See id. at 161. The final report, entitled "Cutlass Feasibility Study" and circulated in March 1991, concluded that developing a product to compete with Windows was not a viable strategy for DRI due to the substantial expense and "moving target risk" of such an undertaking. Engel Decl., Ex. 2 at 1-1; Ex. 16 to Microsoft¹s Beta Blacklist Memo. Thus, well before it requested participation in the Windows 3.1 beta program, DRI had considered and rejected the idea of developing a Windows competitor. As an alternative to competing with Windows, Dick Williams, DRI¹s President and CEO, decided that DRI¹s primary course should be "to the best of our abilities, [to] cooperate with Microsoft. . . . I believed that the best of all worlds would be for the Windows product with Microsoft to be broadly available, and available to Novell such that we could fully support it. That was number one." Deposition of Dick Williams ("Williams Dep.") at 245, Record Support, v.4 to Consolidated Statement of Facts. Having decided not to challenge Microsoft head-to-head in the GUI market, DRI soon learned that cooperation with Microsoft, even where DRI posed no direct threat, was not an alternative. In July 1991, Microsoft placed DRI on its beta blacklist; in August 1991, when DRI formally requested to become a beta site for Windows 3.1, Microsoft denied the request. See Consolidated Statement of Facts ¶¶ 205-209. Later, in March 1992, having learned the hard way that Microsoft was intent on ensuring that Windows would not work with DR DOS, DRI (which by then had merged with Novell), considered a project that would have made Apple¹s GUI work on Intel computers. See Tucker Dep. at 248-49, Record Support, v.4 to Consolidated Statement of Facts. The project was abandoned before a marketable product was ever developed (a decision largely influenced by Apple¹s unwillingness to proceed). See Tucker Dep. at 255, Record Support, v.4 to Consolidated Statement of Facts.
3. In response to paragraph 3, Caldera admits that Microsoft decided wrongfully to exclude DRI from the Windows 3.1 beta test cycle. Microsoft suggests that DR DOS was a "competitor" to Windows, and that this was the reason for the beta blacklist. Caldera denies this statement. DR DOS did not compete with Windows 3.1; in fact, DR DOS worked in conjunction with Windows 3.1. See Deposition of Paul Maritz ("Maritz Dep."), Record Support, v.2 to Consolidated Statement of Facts at 117. The decision to exclude DRI from the Windows 3.1 beta test cycle was to thwart DR DOS¹ ability to be compatible with Windows 3.1 when it was released, and to spread fear, uncertainty and doubt to that effect. See Consolidated Statement of Facts ¶¶ 201-210.
4. Caldera denies paragraph 4. Windows 3.1 was not an "operating system," but required MS-DOS or DR DOS to run. Windows 3.1 was in many respects nothing more than an add-on to DOS. See Consolidated Statement of Facts ¶ 210. DRI sought to ensure DR DOS was compatible with Windows 3.1; Microsoft sought to thwart that goal and instill fear, uncertainty and doubt in the industry about DR DOS¹ compatibility with Windows. Caldera denies that the purported "operating system competitors" listed by Microsoft were placed on the beta blacklist for reasons having anything to do with direct competition with Windows. Microsoft provides no details or evidence to support its assertion with respect to those particular companies. Caldera has abundant evidence that Microsoft widely implemented the beta blacklist to retaliate against perceived industry enemies, and to retaliate against anyone supporting or promoting DR DOS in any way. See Consolidated Statement of Facts ¶¶ 285-91 & 375-82.
5. Caldera denies paragraph 5. Microsoft asserts a conclusion of law drawn from disputed facts. Microsoft relies heavily on the testimony of Toby Corey, but Mr. Corey was not the person most knowledgeable about this issue. The people most knowledgeable about this issue, i.e., the key developers at DRI (John Constant, Roger Gross and Andy Wightman), set forth facts that flatly contradict Microsoft¹s assertions here. Those facts are confirmed in documents‹indeed, a document Microsoft itself relies on sets forth a chronology that confirms the testimony of Mr. Constant, Mr. Gross and Mr. Wightman. See Exhibit 11 to Microsoft¹s Intentional Incompatibilities Memo. at 3 (May 7, 1992, memo from John Constant to Sturge Sobin). First and most important, DRI did not obtain a pre-release copy of Windows 3.1 until March 18, 1992, just three weeks before the commercial release of Windows 3.1. See id at 3; see also Deposition of John Constant ("Constant Dep.") at 30, Record Support, v.3 to Consolidated Statement of Facts. This release was not a beta release‹it was an engineering release that was a candidate for commercial release‹and the DRI developers never obtained a copy of the Windows 3.1 beta. See id. at 30; see also Deposition of Roger Gross ("Gross Dep.") at 138 (never had a beta release), attached as Ex. 3 to Engel Decl.; Deposition of Andrew Wightman ("Wightman Dep.") at 142, attached as Ex. 4 to Engel Decl. Moreover, by the time the DRI developers received this disk, the beta program had run for nine months and had been completed. Earlier, on February 18-19, 1992, Mr. Wightman had attended a Microsoft Windows developers¹ conference where Microsoft blamed incompatibility problems on DR DOS, not Windows. See Wightman Dep. at 145-46, Engel Decl., Ex. 4. A week later, on February 24, a DRI engineer called Provo to confirm the existence of the incompatibilities. See Exhibit 11 to Microsoft¹s Intentional Incompatibilities Memo. at 3; see also Gross Dep. at 23, Engel Decl., Ex. 3. Shortly after that, on March 9, a customer demonstrated incompatibilities to the DRI engineers. See Exhibit 11 to Microsoft¹s Intentional Incompatibilities Memo. at 3. DRI also heard reports from its customers about problems they were having running DR DOS with the Windows 3.1 beta. Gross Dep. at 38-39, Engel Decl., Ex. 3; Engel Decl., Ex. 5. That is the extent of what happened. Finally, what is most surprising is that Microsoft would try to characterize DRI¹s conduct as illegal given that what little information DRI had about the Windows 3.1 betas was gained (i) from unsolicited customer comments, or (ii) from efforts to mitigate the effects of Microsoft¹s predatory conduct in excluding DRI in the first instance.
6. Caldera denies paragraph 6. Microsoft misquotes paragraph 53 of Caldera¹s First Amended Complaint. That paragraph states that "Novell was able to release an enhanced version of DR DOS supporting Windows 3.1 without substantial technical difficulty." (Emphasis added.) Microsoft¹s statement is misleading insofar as it implies that DRI was able to easily solve the compatibility problems between DR DOS 6.0 and Windows 3.1. DRI had to await release of the final version of Windows 3.1 to ascertain whether it had successfully remedied the compatibility problems. See Constant Dep. at 171-72, Record Support, v.3 to Consolidated Statement of Facts. Microsoft ignores the fact that the beta blacklisting itself made the task of solving the compatibility problems "substantially difficult." The beta blacklist was implemented to create fear, uncertainty and doubt in the market about whether DR DOS was compatible with Windows. Blacklisting furthered this purpose, by making it clear to the market that DRI¹s hands were tied, by allowing Microsoft to publicize the incompatibilities Microsoft created and blamed on DR DOS, and by preventing DRI from detecting and fixing the false error message and software incompatibilities Microsoft had engineered into Windows. See Consolidated Statement of Facts ¶ 214.
7. In response to paragraph 7, Caldera admits that Microsoft released Windows 3.1 for general commercial use in April 1992.
8. In response to paragraph 8, Caldera admits that Microsoft released Windows 3.0 for general commercial use in May 1990. Windows 3.0 was not, however, an "operating system" as stated by Microsoft. It was a graphical user interface that ran in conjunction with, and required, MS-DOS or DR DOS. Even the press release cited by Microsoft confirms Windows 3.0 was merely a "graphical user interface for MS-DOS and PC-DOS based personal computers." Exhibit 30 to Microsoft¹s Beta Blacklist Memo.
9. In response to paragraph 9, Caldera denies Microsoft¹s purported reasons for beginning development of Windows 3.1. Windows 3.1 was developed to fix "several thousand" problems in Windows 3.0. See FTC Deposition of Aaron Reynolds ("Reynolds FTC Dep.") at 122-23, Record Support, v.2 to Consolidated Statement of Facts. Caldera admits that DRI requested to participate in the Windows 3.1 beta program in August 1991 in order to ensure continued compatibility between DR DOS and Windows. See Consolidated Statement of Facts ¶ 209.
10. Caldera denies paragraph 10. On its face, Microsoft asserts a conclusion of law. DRI was not a "competitor" with Microsoft as to Windows 3.1. See ¶ 3, above. As a monopolist, Microsoft had a legal obligation to provide nondiscriminatory access to the Windows 3.1 beta. Caldera admits, however, that Microsoft wrongfully refused DRI access to the Windows 3.1 beta.
11. Caldera denies paragraph 11. The paragraph is misleading, for DRI and Microsoft were not "competitors" as to Windows 3.1, but only as between MS-DOS and DR DOS. DRI did not request to be an MS-DOS beta site; instead, DRI requested to be a Windows 3.1 beta site and in response, Microsoft blacklisted DRI. See Consolidated Statement of Facts ¶¶ 209, 380. Microsoft allowed scores of its other "competitors" into the Windows 3.1 beta cycle because they did not compete with Windows 3.1. See id. ¶ 200 n.22.
12. Caldera denies paragraph 12. Microsoft¹s snippets take Mr. Constant¹s testimony out of context. Mr. Constant testified that Microsoft denied DRI access to Windows 3.1 betas; that customers were justifiably alarmed at this discriminatory exclusion when it was reported; that DRI was unable to reassure the market that compatible versions of DR DOS would be available upon the release of Windows 3.1; and that, in fact, DRI was not able to release its patch until after Windows 3.1 shipped and DRI was able to test all of its work on the final product. See Constant Dep. at 163-64 & 171-72, Record Support, v.3 to Consolidated Statement of Facts.
13. In response to paragraph 13, Caldera admits that DRI had limited access to information about the Windows 3.1 beta releases. Caldera denies that any such access was "illegal." See ¶ 5, above. The only "illegal" conduct was that of Microsoft, as an entrenched monopolist, seeking to eliminate competition in the DOS market by leveraging its uncontested monopoly power in the market for Windows.
14. Caldera denies paragraph 14. See ¶¶ 5 & 13, above. The cited provision of the Novell nondisclosure agreement in no way suggests that what Novell engineers did was contrary to those terms. Microsoft¹s cited testimony of Mr. Constant does not support its assertion that Novell violated its NDA. In any event, Microsoft seeks to draw a legal conclusion based on disputed facts. Moreover, Microsoft itself chose not to enforce the NDAs, for the trade press was reporting‹publicly‹problems encountered running Windows 3.1 with DR DOS. See Exhibit 254  to Consolidated Statement of Facts; Exhibit 23 to Microsoft¹s AARD Code Memo.
15. Caldera denies paragraph 15. See ¶¶ 5 & 13, above.
16. In response to paragraph 16, Caldera admits that DR DOS developers discussed the Windows 3.1 beta problems with Novell engineers, but by that time the damage had already been done to DR DOS¹ reputation for Windows compatibility. See ¶ 5, above. Microsoft had blacklisted DRI in mid-1991; Microsoft released Windows 3.1 some eight to nine months later, on April 6, 1992; DRI was not able to begin, much less complete any efforts to uncover the problems Microsoft had created until March 1992, just weeks before the April 6, 1992, release date. See, e.g., Engel Decl., Exs. 6 & 7.
17. Caldera denies paragraph 17. See ¶¶ 5 & 13, above. To the extent Microsoft asserts DR DOS engineers tested DR DOS with Windows 3.1 within a few weeks of the end of the beta test cycle, Caldera admits this. That, of course, is the legitimate purpose of a beta test cycle. Microsoft¹s statement is misleading, though, for it suggests that testing occurred throughout the beta cycle. It did not. See ¶¶ 5 & 16, above. Thus, Microsoft¹s campaign to create fear, uncertainty and doubt was a success. And Novell still was not ready with fully-tested DR DOS patches at the time Windows 3.1 was released. See ¶ 18, below.
18. Caldera denies paragraph 18. See ¶¶ 5, 13 & 17, above. Microsoft presents no evidence that Novell or DRI had to "reverse engineer" Windows 3.1 to achieve DR DOS compatibility. Furthermore, Mr. Constant¹s testimony is clear that full compatibility was thwarted by the beta blacklist until after Windows 3.1 was commercially released. See Constant Dep. at 171-72, Record Support, v.3 to Consolidated Statement of Facts.
19. Caldera denies paragraph 19. Microsoft overstates the content of Mr. Constant¹s declaration. The declaration is unclear whether the code was shipped before Windows 3.1 was released or shortly thereafter. Moreover, damage to DR DOS had already occurred by the time a fix was coded. Press reports of problems caused by the Nested Task Flag bug had been circulating for at least six months by that time. Exhibit 257 to Consolidated Statement of Facts.
20. Caldera admits paragraph 20, but notes that by that time, Microsoft¹s blacklist/FUD campaign had been successfully creating fear, uncertainty and doubt about DR DOS/Windows compatibility for at least nine months.
21. Caldera denies paragraph 21. See ¶¶ 5 & 13 above. Microsoft¹s statement is surprising in two respects. First, nothing suggests that DRI¹s limited access to information late in the beta cycle was in any way illegal. See ¶ 5, above. Second, DRI did not "gain[] an illegal advantage"‹it simply tried unsuccessfully to mitigate the harm it was suffering as a result of Microsoft¹s illegal conduct.
22. Caldera denies paragraph 22. Microsoft¹s campaign to create fear, uncertainty and doubt about DR DOS compatibility with Windows‹by blacklisting DRI, by introducing incompatibilities, by creating false error messages, and by publicizing these facts‹prevented DRI from competing "based on its own innovation."
23. In response to paragraph 23, Caldera admits that Microsoft spent money developing Windows and MS-DOS. It is worth noting, however, that Microsoft¹s statement is misleading, in that it refuses to acknowledge the distinction between Windows 3.1 and MS-DOS, and that DR DOS competed only with MS-DOS.
24. Caldera denies that paragraph 24 is a complete description of DR DOS. DR DOS was designed to be both compatible with and superior to MS-DOS. See Goodman Report at Exhibit C, Record Support v.6 to Consolidated Statement of Facts.
25. Caldera denies paragraph 25. See ¶ 2, above. It is worth noting that the "Cutlass Feasibility Study" recommended the project be killed in March 1991, long before the Windows 3.1 beta cycle began. See Exhibit 16 to Microsoft¹s Beta Blacklist Memo. at A0808524.
26. Caldera admits paragraph 26, except as follows: Microsoft¹s assertion that the goal was to "combine DR DOS with the GUI environment of OS/2" is misleading. Novell and DRI simply wanted DR DOS to provide a platform for OS/2, just as it already did with Windows. Microsoft overlooks the fact that the ability of DR DOS to run with the OS/2 GUI and with Windows 3.1 in fact confirms that DR DOS was not itself in competition with Windows 3.1.
27. Caldera admits paragraph 27, except as follows: Discussions with Apple regarding the "Star Trek" project began in February or March 1992. Deposition of Toby Corey ("Corey Dep.") at 44, Record Support, v.3 to Consolidated Statement of Facts. Thus, DRI did not even explore this possibility until just before Windows 3.1 was released‹and not until DRI had been improperly excluded from the Windows 3.1 beta cycle for at least seven months. By that time, it was clear that Microsoft would improperly restrict access to Windows¹ betas, and would do all it could to thwart DR DOS compatibility with Windows in the future. See Consolidated Statement of Facts ¶¶ 209 & 380; Corey Dep. at 154-55, Record Support, v.3 to Consolidated Statement of Facts. Indeed, Dick Williams, DRI¹s President and CEO, confirmed that the "number one" strategy "was, to the best of our abilities, cooperate with Microsoft . . . for the Windows product with Microsoft to be broadly available, and available to Novell such that we could fully support it." Williams Dep. at 245, Record Support, v.4 to Consolidated Statement of Facts.

1. Response to Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s Alleged Intentional Incompatibilities.

1. Caldera admits paragraph 1, except as follows: Microsoft suggests that XMS was important in order to run the Windows 3.1 setup program, but in fact it was entirely gratuitous because setup makes no use of XMS.
2. Caldera admits that Microsoft added an XMS internal revision number check to the setup program included with Windows 3.1 and that the version check routine functions the same way whether MS-DOS or DR DOS is present on the user¹s machine. (Although the XMS specification itself states that this number is "mainly for debugging purposes" and nowhere suggests that the number indicates driver capabilities.) Caldera denies that the particular XMS internal revision number check employed was either necessary or included to protect consumers. There were far less restrictive methods available to exclude possibly deficient XMS drivers. See Deposition of Michael Colee ("Colee Dep.") at 66-70, Engel Decl., Ex. 8. As Microsoft itself admits, setup itself makes no use of XMS. Id. at 18 ("Q. Does the setup program utilize services in XMS driver? A. No. Short of querying for the version number. That is the only service that the setup program utilizes."). Logically, then, Microsoft must maintain that setup is performing this check to assist some other component of Windows. According to Colee, this other component was DOSX, the standard mode DOS extender. Id. at 19. However, DOSX performs its own query for the XMS revision number, and is satisfied with 2.28 or higher. See First Supplemental Declaration of Lee Hollaar ("Hollaar Decl.") at ¶ 5. Caldera further denies that Mr. Constant¹s testimony referred to the version check at issue. He was referring instead to Microsoft¹s refusal to provide the XMS 3.0 specification to DR DOS. See Constant Dep. at 181, Record Support, v.3 to Consolidated Statement of Facts.
3. In response to paragraph 3, Caldera admits that the XMS test required internal version 2.60 or higher. Caldera admits further that an error message appeared if the test failed. Caldera denies the remedy was simple or obvious. See Section J, ¶¶ 62 & 63, below.
4. In response to paragraph 4, Caldera admits that Mr. Colee denied knowing that DR DOS returned an internal revision number of 2.50. However, Colee says he "obtain[ed] the design criteria that were to be supplied in writing this code" from a "features specification" from "product management" such as David Cole, so his ignorance of the 2.50 number probably signifies nothing. See Colee Dep. at 20-21, Engel Decl., Ex. 8. Caldera further admits that it revised the internal revision number before the commercial release of Windows 3.1. Caldera denies the task of diagnosing and remedying the problem was a "simple matter," for as Mr. Constant testified, although the change required was small, determining what change had to be made was difficult because Microsoft refused DRI access to the XMS specification and the Windows 3.1 beta. See Constant Dep. at 168-69, Record Support, v.3 to Consolidated Statement of Facts. Finally, although DRI eventually remedied the problem, it was not until late in the beta cycle after the damage had been done. See ¶¶ 5 & 16 to Response to Undisputed Facts Regarding "Predisclosure" Claims, Section II.A., above.
5. Caldera admits paragraph 5, except for the statement that setting the value of the "nested task flag to one . . . was not the behavior one would anticipate on Intel microprocessors." The statement simply makes no sense. In real-mode software such as a DOS operating system, the flag could be set to 1 or 0. As Microsoft¹s expert John Bennett states, "The NT flag has no effect on the execution of the IRET instruction when the processor is executing in real mode." Bennett Report at 11, Engel Decl., Ex. 9. Because the flag only has meaning in protected mode, it is the responsibility of protected-mode software such as Windows to set the flag as appropriate. See Hollaar Decl. at ¶ 3.
6. Caldera denies paragraph 6. The error was caused by code (to be precise, the absence of a single line of code) inside the DOSX component of Microsoft Windows 3.1, not in DR DOS. DOSX contains a software "bug": it fails to clear the Nested Task flag, instead relying on whatever value it might have received in real mode. See Hollaar Decl. at ¶ 3. Moreover, the bug created by Microsoft had no technical benefit whatsoever, and, in fact, made the product improvements it sought to include more difficult, not less difficult to implement. Id. See Reynolds FTC Dep. at 70-72, Record Support, v.2 to Consolidated Statement of Facts. It was the responsibility of Windows, not that of real-mode software, to maintain the Nested Task flag: the flag is maintained properly in other parts of DOSX and in the Enhanced mode VMM. See Hollaar Decl. at ¶ 3. See also Reynolds FTC Dep. at 70-72, Record Support, v.2 to Consolidated Statement of Facts ("I have observed at other times that basically if that bit accidentally gets set, some very bad things will probably eventually get around to happening." (Emphasis added)).
7. In response to paragraph 7, Caldera admits at the end of the beta cycle, long after DR DOS¹ reputation for compatibility with Windows 3.1 had been severely damaged (see, e.g., Barnett Report at 15, Record Support, v.6 to Consolidated Statement of Facts), DRI was able to diagnose and code a work-around for the problem. DR DOS 6 had already been commercially released; the work-around for Microsoft¹s problem appeared in an April 1992 "business update" to DR DOS 6. Microsoft never fixed the bug in its code; it was included in the commercial release of Windows 3.1. See Hollaar Decl. at ¶ 3. In June 1992, Microsoft issued a statement on "Running Windows with DR-DOS" which stated that users of DR DOS "will be unable to start Windows." It gave instructions for reverting to Windows 3.0. Engel Decl., Ex. 10.
8. In response to paragraph 8, Caldera admits that Microsoft included the AARD code in the Christmas Beta of Windows 3.1. Caldera denies the remainder of paragraph 8. The code was designed to detect the presence of DR DOS and create false error messages, which were intended to make users believe that DR DOS was incompatible with Windows. See Hollaar Report at 11 & 13-14, Record Support, v.6 to Consolidated Statement of Facts; see also Statement of Additional Material Facts ¶¶ 43-47. As Brad Silverberg, the Microsoft executive admitted:

What the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR DOS and then go out to buy MS-DOS. Or decide to not take the risk for the other machines he has to buy for in the office.

Exhibits 277 & 278 to Consolidated Statement of Facts.

9. In response to paragraph 9, Caldera admits that the AARD code did not modify DR DOS or prevent DR DOS from running. Caldera denies the remainder of paragraph 9. Microsoft suggests in this paragraph that generating false error messages is not an "incompatibility" for purposes of analyzing its predatory conduct under the antitrust laws. Dr. Hollaar made no such concession. He specifically limited his answer to applying a narrow definition of incompatibility that required the error to interfere with operation of the program. He stated further that under a technical definition of incompatibility, the AARD code created an incompatibility. See Deposition of Lee Hollaar ("Hollaar Dep.") at 90-91, Engel Decl., Ex. 11.
10. In response to paragraph 10, Caldera admits that Microsoft accurately quotes its interrogatory response.
11. Caldera denies paragraph 11. Mr. Dixon testified that he not only was aware of the software locks, but he witnessed the effect they had when users attempted to execute Hanguel versions of Microsoft¹s applications. See Deposition of Richard Dixon ("Dixon Dep.") at 39-45, Record Support, v.3 to Consolidated Statement of Facts. Microsoft has never produced Hanguel versions of its applications. Caldera has located, however, through third party sources, copies of Hanguel versions of Microsoft Windows 3.0 and 3.1. Both programs produce error messages telling users that they should only operate Windows on MS-DOS. See Hollaar Decl. at ¶ 7.
12. Caldera denies paragraph 12. Mr. Dixon testified that he witnessed the software locks preventing Microsoft applications from running on DR DOS. See Dixon Dep. at 39-45, Record Support, v.3 to Consolidated Statement of Facts. Microsoft seems to be suggesting that because Microsoft has been unable to produce copies of its software, the Court should ignore the testimony of a witness who saw the locks.
13. Caldera admits the first part of paragraph 13, but denies the last part. Microsoft asserts that PROTMAN.DOS was created by 3Com and merely included by Microsoft in Windows for Workgroups. Microsoft misquotes Ludwig¹s FTC testimony. According to Microsoft, "The only changes made to PROTMAN.DOS were bug fixes." See Deposition of John Ludwig ("Ludwig Dep.") at 21, Engel Decl., Ex. 12. However, Ludwig also refers to "support added for additional versions of DOS." Id. at 19. That is precisely the area that caused problems for DR DOS. PROTMAN.DOS contains a Microsoft as well as a 3Com copyright notice. Starting with version 5, the MS-DOS kernel contains special provision for PROTMAN that required close coordination with code inside PROTMAN (indeed with precisely the section of code of which Caldera complains). See Ludwig Dep. at 39-40, Engel Decl., Ex. 12.
14. Caldera admits paragraph 14 except as follows: that "DRI could have fixed this problem by having DR DOS report itself as a larger version of MS-DOS" is disingenuous. Simply reporting itself as version 5, for instance, would have produced significant problems.
15. Caldera admits that paragraph 15 accurately characterizes the cited testimony of the two witnesses identified.
16. Caldera admits paragraph 16.
17. Caldera admits paragraph 17.
18. Caldera admits paragraph 18.
19. Caldera admits paragraph 19.
20. Caldera admits that Microsoft packaged DOS and Windows together in Windows 95, and that by doing so Microsoft foreclosed DR DOS from running with the Windows portion of Windows 95. Caldera denies that Windows 95 is integrated. As Caldera shows elsewhere, see Caldera¹s Opposition to Microsoft¹s Motion for Partial Summary Judgment on Plaintiff¹s "Technological Tying" Claim, there is a fully separable copy of MS-DOS, version 7.x, contained in the Windows 95 and Windows 98 boxes. Caldera also denies that Windows 95 "performs some of the functions that MS-DOS performed for earlier versions of Windows." Windows 95 performs all of the functions MS-DOS performed for earlier versions of Windows. Although Windows may not employ them, DOS supplies them.

1. Response to Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s "Perceived Incompatibilities" Claim.

1. Caldera admits paragraph 1 except as follows: Microsoft¹s statement is misleading insofar as support expenses are dwarfed by development expenses. Microsoft itself states as "undisputed fact" that it spent "an enormous amount of money and substantial number of man-hours in designing, developing, testing and marketing Windows 3.1 and MS-DOS. See Undisputed Fact 23 in Microsoft¹s Beta Blacklist Memo.
2. In response to paragraph 2, Caldera admits that Microsoft provides telephone support to a subset of Microsoft customers. Caldera denies the remainder of paragraph 2. The statement in the exhibit Microsoft cites identifies problems created by Windows¹ incompatibilities with other products. See Exhibit 19 to Microsoft¹s AARD Code Memo. at 5. Although Microsoft would like to blame those problems on other vendors, the problems were caused by incompatibilities with Windows. Id. Furthermore, there is no evidence that DR DOS users "often contacted" Microsoft for support. Exhibit 20 to Microsoft¹s AARD Code Memo., the document on which Microsoft relies as support, shows just the opposite to be true. In June 1992, when more than three million copies of DR DOS were in circulation (Ivie Report at 32, Record Support, v.6 to Consolidated Statement of Facts), even by Microsoft¹s count support calls for DR DOS users made up about 2/3 of one percent of total calls. See Exhibit 20 to Microsoft¹s AARD Code Memo. (625 calls out of a total of 93,722 calls). Furthermore, according to the report, Microsoft spent 21,275 hours on support in June. Id. DR DOS callers accounted for 76 of those hours (which amounts to 1/3 of one percent of the time spent). Id. Moreover, Microsoft apparently used these calls not as a means of providing support, but rather as a marketing opportunity, telling callers that Windows did not work with DR DOS and that they should switch to MS-DOS. See Deposition of Jody Clifton ("Clifton Dep.") at 267-68, Engel Decl., Ex. 13; see also Consolidated Statement of Facts ¶¶ 218-29, 230 & 235.
3. In response to paragraph 3, Caldera admits that internal documents suggest that Microsoft considered including an error message in the production release of Windows 3.1 that would have appeared when users attempted to run Windows with DR DOS. However, Caldera denies that Microsoft considered putting in this message due to the "support burden." Microsoft put the false error messages in the Windows 3.1 beta in order to make DR DOS users "uncomfortable" and "suspect the problem is DR DOS and go out and buy MS-DOS." See Exhibit 278 to Consolidated Statement of Facts. Caldera admits that paragraph 3 accurately characterizes the testimony regarding user manuals and "Readme" files, and agrees that if Microsoft¹s intent was to increase the effect of the message, having it appear as an error message would cause users a high level of concern.

4. In response to paragraph 4, Caldera admits that Mr. Frankenberg and Dr. Hollaar testified that they would not have objected to a message identifying a lack of testing, but both Mr. Frankenberg and Dr. Hollaar objected to the error messages actually implemented by Microsoft as deceptive and misleading. See Deposition of Robert Frankenberg ("Frankenberg Dep.") at 320-21, Record Support, v.3 to Consolidated Statement of Facts; Hollaar Report at 13-14, Record Support, v.6 to Consolidated Statement of Facts.

5. In response to paragraph 5, Caldera admits that Microsoft tested pre-release versions of Windows 3.1 with various versions of MS-DOS. Caldera also admits that Microsoft did not devote development resources to fixing incompatibilities between Windows 3.1 and DR DOS. Rather, Microsoft devoted development resources to creating incompatibilities (and the perception of incompatibilities) between Windows 3.1 and DR DOS. See Statement of Additional Material Facts ¶¶ 41-49. Caldera further admits that Microsoft stated publicly that it did not test Windows 3.1 with DR DOS, but the statement, including the statement quoted by Microsoft ("We do no testing at all with DR DOS . . .") was plainly untrue. The statement was made in January 1992, yet in September 1991, during the Windows 3.1 beta cycle, Microsoft distributed a comprehensive DR DOS test plan, that included extensive testing with all versions of Windows. See Exhibit 184 to Consolidated Statement of Facts; see also Deposition of Brad Chase ("Chase Dep.") at 136-38, Record Support, v.1 to Consolidated Statement of Facts; Deposition of Thomas Lennon ("Lennon Dep.") at 198-203, Record Support, v.1 to Consolidated Statement of Facts (describing DR DOS testing efforts by Microsoft, including a "DR Hammerfest" intended to find DR DOS bugs, complete with prizes for those Microsoft programmers who found the most DR DOS bugs). Caldera admits that while Microsoft was blacklisting DRI from the Windows 3.1 beta program, Microsoft made public statements that it was DRI¹s responsibility to make any changes necessary to DR DOS to ensure compatibility with Windows 3.1. Yet, as described more fully below, Microsoft was creating incompatibilities between Windows and DR DOS, telling the industry that the incompatibilities were caused by DR DOS, and denying DRI access to the information necessary to fix the problems. See Statement of Additional Material Facts ¶¶ 42 & 48. See also FTC Deposition of Phillip Barrett ("Barrett FTC Dep.") at 101-02, Engel Decl., Ex. 14 (describing how the problem was with "Bambi," not DR DOS).

6. Caldera admits paragraph 6, except as follows: Windows 3.1 was not an "operating system," but required MS-DOS or DR DOS to run. See Consolidated Statement of Facts ¶ 210. Microsoft¹s description of its beta program and the purpose of the program is incomplete and inaccurate. Microsoft used the Windows 3.1 beta program not only for testing, but also for marketing purposes. See, e.g., Exhibit 24 to Microsoft¹s AARD Code Memo. at 11-12 (noting the marketing purposes underlying the beta program and reporting that only 37% of the beta sites reported problems). See also Consolidated Statement of Facts ¶ 228.

7. Caldera admits paragraph 7. See Consolidated Statement of Facts ¶ 212.

8. Caldera denies paragraph 8. The XMS version check, the Nested Task flag bug, "Bambi," and the AARD code (what Microsoft refers to as the "non-fatal error message") were all part of Microsoft¹s scheme to preclude competition in the DOS market. See, e.g., Bennett Report, Appendix F, Engel Decl., Ex. 9 (showing users encountering both the Nested Task error message ("Standard mode: Fault in MS-DOS Extender" error message) and the AARD code¹s non-fatal error message). Furthermore, these problems were created by Microsoft, not DRI. See Statement of Additional Material Facts ¶¶ 41-49, see also Caldera¹s Response to Undisputed Facts Regarding Intentional Incompatibilities, Section II.B., above.

9. Caldera admits paragraph 9, but notes the incompatibilities reported by the press were incompatibilities created by Microsoft, not DRI. See Statement of Additional Material Facts ¶¶ 41-49; see also Response to Undisputed Facts Regarding Intentional Incompatibilities, Section II.B., above.

10. Caldera admits paragraph 10, except as follows: End-users did not make up only a small subset of beta testers. As Microsoft¹s Exhibit 24 shows, of the 15,106 total beta sites, 5,607 of those sites were corporate sites‹which, of course, are end-users. See Exhibit 24 to Microsoft¹s AARD Code Memo. at 20. Another 255 sites were government sites (again, end-users of the product), and there were several other categories that appear to be end-users. Id. Thus, the single largest category of testers was end-users. See Consolidated Statement of Facts ¶ 228.

11. Caldera denies paragraph 11. As described in Exhibit 24 to Microsoft¹s AARD Code Memo., some sites returned beta applications without signed NDAs and some Windows Developer¹s conference attendees were merely handed copies of the Windows 3.1 beta at the conference without the "beta kit" containing documentation. Exhibit 24 to Microsoft¹s AARD Code Memo. at 7. Later in the beta cycle, beta testers were not required to sign NDAs, but rather were provided copies of NDAs they never had to execute. Id. Moreover, Microsoft selectively enforced the NDAs. Members of the trade press often signed the NDAs. See id. at 10. Microsoft allowed and encouraged disclosure by the trade, Engel Decl., Ex. 15, despite the NDAs, so long as the disclosure was favorable to Microsoft (as reports of Windows 3.1/DR DOS compatibility "problems" were). See Consolidated Statement of Facts ¶ 314.

12. Caldera admits paragraph 12, except as follows: The AARD code was developed by Aaron Reynolds, who had carefully researched and discovered specific differences between DR DOS and MS-DOS. See Statement of Additional Material Facts ¶¶ 44 n.4; see also Consolidated Statement of Facts ¶ 39. The AARD code was intended to detect DR DOS. See Exhibit 194 to Consolidated Statement of Facts (September 27, 1991, e-mail entitled "FYI: Windows message" and sent to Brad Silverberg and Brad Chase: "The check for dr dos better be perfect") see also Consolidated Statement of Facts ¶ 237.

13. Caldera denies paragraph 13. The AARD code was included for the express purpose of creating the impression that DR DOS was incompatible with Windows and to create enough fear and uncertainty to cause users to reject DR DOS. See Hollaar Report at 11-14, Record Support, v.6 to Consolidated Statement of Facts (explaining why Microsoft¹s excuse for the code is inconsistent with the code itself, how it was implemented and the error messages generated by it). Brad Silverberg, the Microsoft executive responsible for the code, summed up the purpose of the code as follows:

Exhibits 277 & 278 to Consolidated Statement of Facts. Nor was there just one message, as Microsoft implies. The code was designed to trigger a false error message at five separate points. And the messages were not innocuous. They failed to explain that an error had not in fact occurred (see Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts (conceding no error had occurred)), they failed to identify that the messages were a product of secret, encrypted detection code, and they left the user with no knowledge about the true cause of the messages. See Hollaar Report at 13-14, Record Support, v.6 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶ 231. Moreover, when users contacted Microsoft support they were not told any of these things‹instead they were told that switching to MS-DOS would solve the problem. See, e.g., Bennett Report, Appendix F at 45-46, Engel Decl., Ex. 9 (Microsoft Compuserve posting responding to users¹ concerns about the error messages: "You should be able to get rid of the message by using MS-DOS instead of DR-DOS"). The effect on DR DOS was devastating. See Barnett Report at 3-4 & 15, Record Support, v.6 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶¶ 218-19, 230 & 235.

14. Caldera admits paragraph 14.

15. In response to paragraph 15, Caldera admits that Microsoft accurately quotes Mr. Frankenberg¹s testimony, but notes that Mr. Frankenberg testified further that a non-fatal error message would indicate an error has in fact occurred. See Frankenberg Dep. at 105, Record Support, v.3 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶ 231.

16. In response to paragraph 16, Caldera admits that the AARD code did not modify DR DOS or prevent DR DOS from running. Caldera denies the remainder of paragraph 16. Microsoft suggests in this paragraph that generating false error messages is not an "incompatibility" for purposes of analyzing Microsoft¹s predatory conduct under the Sherman Act. Dr. Hollaar made no such concession. He specifically limited his answer to applying a narrow definition of incompatibility that required the error to interfere with the actual operation of the program rather than the creation of false error messages. He stated further that under another definition of incompatibility, the AARD code created an incompatibility. See Hollaar Dep. at 90-91, Engel Decl., Ex. 11. Moreover, there is no dispute that the message itself was false. The developer of the code that produced the false error messages conceded that there was in fact "no error." Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts.

17. Caldera admits paragraph 17, except as follows. Microsoft asserts that "very few communications with beta testers of Windows 3.1 occurred outside the CompuServe forum" without offering any support for this proposition. It is clear from the record that beta testers contacted Microsoft directly by telephone. See Exhibit 24 to Microsoft¹s AARD Code Memo. at 5-8. The volume of these communications is unknown, but it was sufficiently high to cause Microsoft to complain about it. Id. at 7.

18. Caldera admits paragraph 18, except as follows. It is not clear that all beta testers were covered by valid NDAs (see ¶ 11, above), nor is it clear that anyone routinely complied with NDAs. See Deposition of Steve Ballmer ("Ballmer Dep.") at 193, Record Support, v.1 to Consolidated Statement of Facts ("Well, the computer industry is not a very tight-lipped ship. If you tell‹a systems design preview is an event we would do for independent software vendors. If you tell 50 independent software vendors something, you're going to find it's under a Non-Disclosure Agreement, the high, high, high, high, high, high probability is that that will be in the press the next week"); see also Consolidated Statement of Facts ¶ 314.

19. Caldera denies paragraph 19. Every single DR DOS user that ran the Windows 3.1 Christmas beta saw the false error messages‹and they saw them every single time they attempted to run the beta. See Hollaar Decl. at ¶ 6. In addition, the record shows not only that users were concerned that the messages were the result of an incompatibility between DR DOS and Windows, but that Microsoft told users who encountered the messages that they should switch from DR DOS to MS-DOS. See Statement of Additional Material Facts ¶ 51; see also Consolidated Statement of Facts ¶¶ 218, 219, 230, 233 & 235; see also ¶ 20, below.

20. Caldera denies paragraph 20. It is surprising that Microsoft asserts that "Microsoft never posted a message in the CompuServe forum stating that the Œnon-fatal error¹ message was the result of incompatibilities between DR DOS and Windows 3.1." Maybe Microsoft intends only to assert that it did not use those exact words, because Microsoft plainly told users that the error messages were caused by DR DOS and switching to MS-DOS would solve the problem. In response to a Compuserve beta forum posting about "Non-fatal error detected: Error #2726" (i.e., the AARD code), Microsoft responded: "You should be able to get rid of the message by using MS-DOS instead of DR-DOS." See Bennett Report, Appendix F, at 45-46, Engel Decl., Ex. 9. Moreover, Microsoft never posted anything to clarify that the false error messages were not caused by any incompatibility between Windows 3.1 and DR DOS. See Consolidated Statement of Facts ¶¶ 230 & 235-36.

21. Caldera denies paragraph 21. Rather than improperly examining a Novell copy of the Windows 3.1 beta, near the end of the beta cycle DRI developers contacted Novell by telephone to confirm reports of errors it had received from customers. See ¶ 5 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above. Meanwhile, Microsoft was busy directing one of its OEM representatives to steal a copy of a DR DOS 6 beta so that Microsoft could test it to come up with other FUD points. See ¶¶ 5 & 14 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above.

22. Caldera denies paragraph 22. DRI was able to modify DR DOS to make it compatible with Windows 3.1 only after the commercial release of Windows 3.1. A version of DR DOS compatible with Windows 3.1 was not released until approximately one month after the commercial release of Windows 3.1. Constant Dep. at 29, Record Support, v.3 to Consolidated Statement of Facts. Moreover, Windows 3.1 is not an operating system. See ¶ 6, above; see also ¶¶ 4, 12 & 16 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above.

23. In response to paragraph 23, Caldera admits that Microsoft, in response to concerns regarding the bad press it was receiving and expected to receive, disabled the false error messages so that they no longer appeared. Caldera denies that Microsoft decided not to include the false error messages in the commercial release of Windows 3.1 "because Microsoft was concerned about possible misperceptions of Microsoft¹s intentions." Microsoft disabled the error messages because the media and the industry were criticizing Microsoft for detecting DR DOS and including false error messages. Reynolds FTC Dep. at 76-77, Record Support, v.2 to Consolidated Statement of Facts.

24. In response to paragraph 24, Caldera admits that the false error messages did not appear when the commercial release of Windows 3.1 was run on top of DR DOS. Caldera denies that Microsoft disabled the code. Microsoft disabled the messages. The Windows 3.1 commercial release still ran the AARD code ran every time a user loaded Windows 3.1.

1. STATEMENT OF ADDITIONAL MATERIAL FACTS

1. Caldera¹s Memorandum In Opposition to Defendant¹s Motion for Partial Summary Judgment on "Product Disparagement" Claims ("Product Disparagement Response") explains that Microsoft¹s DR DOS campaign relied on several related predatory acts to create fear, uncertainty and doubt ("FUD") in the market about the quality and compatibility of DR DOS. Caldera¹s Product Disparagement Response focused principally on Microsoft¹s false and misleading statements. This Statement of Additional Material Facts outlines the related aspects of Microsoft¹s FUD campaign: (1) beta blacklisting, (2) coding false error messages in the Windows 3.1 beta, and (3) creating intentional incompatibilities between DR DOS and Windows. As will be shown, each of these practices reinforced the other, and, combined with Microsoft¹s false and misleading statements and Microsoft¹s other predatory practices, succeeded in eliminating DR DOS as a competitive threat to Microsoft¹s desktop operating system monopoly.

1. 1988-1990: DR DOS Enters the Desktop Operating System Market.

1. By the mid-1980s, Microsoft¹s MS-DOS had a monopoly in the desktop operating system market. Kearl Report at 11, Record Support, v.6 to Consolidated Statement of Facts. Without competition to force product innovation, Microsoft put very little effort into improving MS-DOS for several years. See, e.g., Exhibit 38.
2. In June 1988, Microsoft released MS-DOS 4.0. It was widely perceived to be a poor quality product‹even within Microsoft. Exhibits 18, 38, & 39. One of Microsoft¹s principal developers described MS-DOS 4.0 as follows:

1. It was an embarrassment because it was full of bugs?

1. Yeah, it was buggy and it was not user friendly. There were a number of what we called, somewhat jokingly, user-hostile features that were added.

Deposition of Phillip Barrett ("Barrett Dep.") at 37-38, Engel Decl., Ex. 16.

1. The market was ripe for a competitive DOS. DRI re-entered the DOS market with a new product: DR DOS 3.31. Within Microsoft, Bill Gates conceded that DR DOS was "as good as our dos. . . ." Exhibit 38. Gates recognized the quality of DR DOS, explaining to IBM that MS-DOS "is under extreme attack by high quality clones like DR DOS." Exhibit 39; see also Exhibit 26 ("Initial consensus from [Microsoft¹s] DOS program management is that DRI has a product which competes very favorably against MS-DOS."); Exhibit 25 (PC Week May 9, 1989) ("Digital Research produced DOS the way it should have been done in the first place. . . . It¹s a much cleaner, faster system than MS-DOS . . . and it¹s cheaper.").
2. By May 1989, Bill Gates estimated that competition from DR DOS had caused a 30% to 40% reduction in MS-DOS prices. Exhibit 29.
3. On April 26, 1990, DRI announced the release of DR DOS 5.0, which included several new and important technological improvements‹many of which users had been requesting for some time. See Goodman Report, Exhibit C, Record Support, v.6 to Consolidated Statement of Facts.
4. Software industry experts immediately recognized DR DOS 5.0 to be a superior operating system product that was fully compatible with all popular DOS applications, including Windows 3.0:

PC User Magazine, July 4, 1990:

PC User Verdict: This is the first time I¹ve given any product an all "excellent" verdict, which speaks for itself.

Exhibit 61.

PC Magazine, January 15, 1991:

DR DOS 5.0 does all the things you wish MS DOS did. It¹s features includeŠfull compatibility with MS DOS. . . . Everybody¹s DOS should be this advanced.

Exhibit 106 (emphasis added).

PC Magazine, February 12, 1991:

DR DOS 5.0 will run nearly any program that runs under MS DOS, including Microsoft Windows 3.0. Compatibility is not an issue with DR DOS 5.0.

Exhibit 109 (emphasis added).

5. DR DOS 5.0 won Byte Magazine¹s Award of Distinction (January 1991) and PC Magazine¹s Award for Technical Excellence (January 15, 1991). Exhibits 105 & 106.
6. Within Microsoft, the reviews of DR DOS were equally positive:

DR DOS 5.0 runs every DOS app [application] I know. DR DOS 5.0 works successfully with Windows. . . . DR DOS 5.0 is vastly superior to MS/PC DOS 3.31 and 4.01.

Exhibit 123.

DR DOS 5.0 is a "far superior product. . . ."

Exhibit 120 (Joachim Kempin, Microsoft¹s Director of Worldwide OEM Sales).

7. Microsoft was caught flatfooted. It did not have a competitive product to offer the market. In fact, Microsoft would not release its competing operating system‹MS DOS 5.0‹until June 1991, a full 13 months after DR DOS 5.0 was released. Consolidated Statement of Facts ¶ 307. In response, Microsoft used several related predatory practices to "freeze the market" and otherwise prevent PC users and PC manufacturers ("OEMs") from switching to DR DOS 5.0. See Caldera¹s Responses to Microsoft¹s various summary judgment motions.

1. July 1991: Novell Announces the Merger With DRI.

1. Microsoft executives worried about losing their operating system monopoly. At the annual Microsoft Executive Retreat, Scott Oki, Microsoft¹s Senior Vice President for Sales, Marketing & Services, stated the company¹s strategic agenda:

Maintain control of the desktop systems platform. DOS is still the gold mine. It is the cash cow that allows us to invest in other potential cash cow businesses.

Exhibit 110 (emphasis added).

2. In addition to worrying about DR DOS, Microsoft executives had heard that Novell was thinking about entering the desktop operating system market. In a February 1991 memo to Steve Ballmer, Senior Vice President of Systems, Jim Allchin, Vice President of Advanced Systems, characterized competition from Novell on the desktop as "a severe threat . . . Novell is in the best position to impact our position. . . ." Exhibit 111.
3. In July 1991, Novell announced its pending merger with DRI. Hearing the news, Jim Allchin wrote to Bill Gates:

I thought about it all night. Since I came here I said there were two things that concerned me related to Novell: one Novell partnering with IBM and two Novell coming at us at the desktop. Both fears have now come true.

Given this, I suggest (at least for Systems) that we . . .

consider changing our apps to not run unless the OS [operating system] is our OS [MS-DOS].

Exhibit 280 (emphasis added).

4. Brad Silverberg, the senior executive responsible for MS-DOS and Windows, immediately instructed his development team to find ways to prevent Novell from competing on the desktop. Exhibit 148.
5. Phil Barrett, the MS-DOS 5.0 Development Manager, responded. He observed: "Totally freezing them out will force them to compete on a wider basis and could cause the disaster scenario to occur. Not to mention the thin FTC ice that we would be on." Instead he suggested, ". . . we have an advantage with windows and should press it in the systems area." Engel Decl., Ex. 17 (emphasis added). Brad Silverberg, Vice President, Personal Systems, concurred. Id.
6. At the time, Microsoft was preparing to release the beta version of Windows 3.1, preparatory to a release of the final product in Spring 1992. Brad Silverberg and Jim Allchin decided Microsoft should engineer Windows 3.1 in a way that would create compatibility problems for DR DOS:

Silverberg:

. . . drdos has problems running windows today, and I assume will have more problems in the future.

Allchin:

You should make sure it has problems in the future.

Exhibit 197 (emphasis added).

7. Microsoft¹s fears about DR DOS and Novell became even more severe in September 1991 with the release of DR DOS 6.0. Once again, the industry press was overwhelmingly favorable:

PC User, September 25, 1991:

VERDICT: more of an operating system than MS DOS, with no obvious disadvantages.

Exhibit 193.

PC Week, September 30, 1991:

DR DOS has a lot going for it. DRI had already made significant headway against MS-DOS earlier this year with DR DOS 5.0 and DRI¹s successful "toss your DOS" campaign. Microsoft¹s release of MS-DOS 5.0 this summer was clearly in response to the growing acceptance of DR DOS 5.0.

Now, only months after the release of MS-DOS 5.0, DRI has again stepped ahead with the release earlier this month of DR DOS 6.0, which once again matches and exceeds the features and capabilities of Microsoft¹s product. Starting from a small base, DR DOS is clearly gaining market share.

Exhibit 200 (emphasis added).

8. DR DOS 6.0 won "Best of Comdex," and Byte Magazine¹s "Best Utility Software." Exhibit 228 (Business Wire, October 24, 1991). InfoWorld awarded DR DOS 6.0 a score of 7.6, as compared to 7.1 for MS-DOS. Exhibit 235 (InfoWorld, November 4, 1991). PC/Computing said, "DR DOS 6.0 steals thunder from MS DOS in nearly every area." Exhibit 233 (November 1991). PC Magazine said, "DR DOS 6.0 leapfrogs MS DOS 5.0 with task switching and RAM." Exhibit 244 (November 12, 1991).
9. Once again, Microsoft internal reviews recognized that DR DOS was superior to MS-DOS and that DR DOS had established a big lead over Microsoft in the introduction of new DOS technology. As Novell was about to release DR DOS 7.0, Richard Freedman, the MS-DOS 6.0 Product Manager stated:

Exhibit 350.

David Cole, MS-DOS/Windows Program Manager, worried:

Exhibit 273.

1. Fall 1991: Microsoft Plans to Make Windows 3.1 Incompatible With DR DOS.

1. Fearing loss of its desktop operating system monopoly, Microsoft decided to use Windows to eliminate the DR DOS/Novell threat. With the success of Windows 3.0 and the pending release of Windows 3.1, Microsoft knew most OEMs believed they had to license and offer Windows with their PCs. As Joachim Kempin, Director of Worldwide OEM Sales, said: OEMs "will hurt if they do not ship WIN. . . ." Exhibit 118. Further, Microsoft knew that OEMs would not license DR DOS if they feared it would not run Windows:

Any degree of incompatibility is enough to create fear, uncertainty & doubt among endusers when it comes time to buy new systems‹this suggests PC OEMs will take on a big risk if they ship DR-DOS with their systems.

Exhibit 126; see also Deposition of Sergio Pineda ("Pineda Dep.") at 37, Record Support, v.2 to Consolidated Statement of Facts; Barnett Report at 9 & 15, Record Support, v.6 to Consolidated Statement of Facts.

2. Microsoft¹s attack on DR DOS had five complimentary aspects: (1) Microsoft publicly stated it would take steps to prevent DR DOS from being compatible with Windows; (2) Microsoft excluded DR DOS from the Windows 3.1 beta program so DRI could not detect and fix real and perceived incompatibilities that Microsoft intentionally engineered into Windows 3.1; (3) Microsoft placed a purposely deceptive "error" message in a Windows 3.1 beta that caused the market to believe DR DOS was not compatible; (4) Microsoft reinforced its deceptive "error" message by making false public statements that DR DOS was not compatible and that MS-DOS was "required" to run Windows; and (5) Microsoft intentionally engineered software incompatibilities between Windows 3.1 and DR DOS. See ¶¶ 22-49, below.

1. Microsoft Made Public Statements That Caused the Market to Expect DR DOS Would Not Be Compatible With Windows.

1. Microsoft knew that, since PC users and even OEMs cannot understand every complexity in a new software product‹indeed, few people other than the developers themselves have access to the information necessary to gain such an understanding‹"perception is the most important determining factor." Freedman Dep. at 10-11, Record Support, v.1 to Consolidated Statement of Facts.
2. Brad Silverberg stated Microsoft¹s plan:

We need to create the reputation for problems and incompatibilities to undermine confidence in DR DOS 6; so people will make judgments against it without knowing the details or facts.

Exhibit 227.

3. Microsoft engaged in a public relations campaign to convince the market that Microsoft would take steps to prevent DR DOS from being compatible with Windows. For example, Microsoft instructed its account managers to tell OEMs:

. . . dr dos and windows will get them complaints. . . . in addition, they will get even more questions later as we update ms-dos 6 and windows as dr dos could not be compatible.

Exhibit 159 (emphasis added).

also ask them if they really want to risk their reputation on their brand new machines with a brand new unproven poorly tested os. what if it doesn¹t work with the next version of windows? they could literally blow their whole pc business‹first impressions are hard to overcome if they blow it.

Exhibit 173 (emphasis added).

4. Microsoft even went so far as to state outright that DR DOS was not compatible:

Exhibit 218 (emphasis added).

1. Microsoft Selectively Excluded DR DOS From the Windows 3.1 Beta Program.

1. Brad Silverberg and Steve Ballmer, the two senior Microsoft executives responsible for MS-DOS and Windows, ensured that the market would take these threats seriously and that Microsoft would be able to hide its efforts to manufacture incompatibilities, by excluding DRI from the Windows 3.1 beta program.

Brad Silverberg:

There should be NO HELP for DRI. They are totally on their own. Do we know if DR has Win 3.1? They are NOT an official beta tester.

Steve Ballmer:

brad pls make sure we are not supporting DRI anywhere in the company with this stuff thx

Exhibit 158; see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 19-20 & 22.

2. Microsoft¹s purposes in excluding DR DOS were at least three-fold. Exclusion would: (1) let the market know Microsoft was making it difficult for DR DOS to be compatible; (2) prevent DRI from discovering and fixing the incompatibilities Microsoft planned to engineer into Windows; and (3) prevent DRI from having a Windows-compatible version of DR DOS ready for market at the same time Microsoft released Windows 3.1. See Product Disparagement Response Statement of Additional Material Facts ¶¶ 19 & 21.
3. Microsoft knew it was wrong to selectively exclude DRI. See Product Disparagement Response Statement of Additional Material Facts ¶¶ 18 & 21.
4. Waggener Edstrom, Microsoft¹s public relations firm, warned Brad Silverberg:

PR is going to have limited ability to help you if Microsoft is deliberately and selectively keeping DRI from participating in the beta program. That is, if you are making a special case of them that is not consistent with the way that the beta program is being administered for the rest of the industry.

Exhibit 238. Yet selective exclusion is precisely what Microsoft did. See Product Disparagement Response Statement of Additional Material Facts ¶¶ 22-23.

5. Knowing it was improper to exclude the developers of DR DOS, a product that was complimentary to Windows, Microsoft began propagating the fiction that Windows 3.1 and DR DOS were competitive "operating systems."

Silverberg:

We recently decided to start referring to Windows as an operating system in our communications, not a graphical environment or user interface for dos. we should be consistent in the new usage. thanks.

Exhibit 164.

6. A beta tester asked Brad Silverberg directly:

What is MS¹ official response to the charge that you folks have been deliberately shutting out DRI from the BETA program, and that you¹ve made 3.1 incompatible with DR DOS intentionally? I hear a lot of accusations to this effect, and some of them are down-right libelous. What¹s the word, Brad?

Exhibit 443. Silverberg responded:

Windows is an operating system. That¹s how we view it and certainly a sign of how it will evolve.

Id. (emphasis added); see also Exhibit 443 (Silverberg attempting to justify Microsoft¹s exclusion of DR DOS on the grounds that Windows and DR DOS are direct competitors, "Are the Redskins going to give their game plan in advance to the Bills?").

7. But Microsoft knew that Windows 3.1 was not an "operating system" and, more important, that it did not compete with DOS. Windows 3.1 was, and is, a graphical extension of DOS that requires the underlying DOS operating system‹either MS-DOS or DR DOS‹to run. DR DOS competes with MS-DOS. Microsoft recognized these markets were separate markets‹and the danger of using control of one market to eliminate competition in the other:

David Cole (MS DOS/Windows Group Program Manager):

Uhmm . . . denying DRI the VxD [virtual device driver] smells of an antitrust lawsuit. You¹re not supposed to use your control of one market, in this case Windows, to influence another market, in this case DOS. Err something like that.

Exhibit 99 (emphasis added). The press similarly explained:

PC Week:

Microsoft officials have said they won¹t help Digital Research, Inc. (DRI) resolve incompatibilities between Windows 3.1‹over which the companies don¹t compete‹and DRI¹s DR DOS 6.0, which challenges Microsoft¹s DOS monopoly.

Exhibit 254 (emphasis added); see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 23-25.

8. Microsoft¹s economic expert, Professor Hausman, conceded that Microsoft excluded DR DOS to harm its ability to compete with MS-DOS, even though including DR DOS could have benefited Microsoft¹s sales of Windows 3.1:

Q: . . . and wouldn¹t inclusion . . . if it occurred . . . be a benefit to Windows?

A: It could be a benefit to Windows, but it would be a detriment to the overall Microsoft, and that¹s what they are looking at.

Q: It would be a detriment to Microsoft¹s sales of MS-DOS, right?

A: It could be, yes.

Deposition of Jerry Hausman ("Hausman Dep.") at 104-105, Engel Decl., Ex. 18.; see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 26-27.

9. Blacklisting had the result Microsoft intended. DR DOS¹ exclusion from the Windows beta program was widely known and reported in the press:

Microsoft officials have said they won¹t help Digital Research Inc. (DRI) resolve incompatibilities between Windows 3.1‹over which the companies don¹t compete‹and DRI¹s DR DOS¹s 6.0, which challenges Microsoft¹s DOS monopoly.

Exhibit 254 (PC Week, December 9, 1991) (emphasis added); see also Exhibit 257 (InfoWorld, December 16, 1991) ("Microsoft Balks at Fixing DR DOS, Windows Bugs; DRI Cites Responsibility to Users").

10. DR DOS lost business. For example, in January 1992, DRI was notified, by a potential corporate account of its decision to reject DR DOS 6.0:

What I feel is the most important factor however, is the rift developing between Digital Research and Microsoft. By this I mean Microsoft not allowing you to beta test Windows 3.1. Since the users who would be most inclined to switch to DR DOS are also using Windows, this one factor is of particular concern.

Exhibit 266.

11. Microsoft also ensured that the OEM and developer community knew not only that DR DOS was excluded from the Windows 3.1 beta program, but also that the incompatibilities were the fault of DR DOS, not Microsoft (which, as explained below, was not true). For example, Microsoft hosted a Windows developers conference in February 1992. Wightman Dep. at 309-10, Engel Decl., Ex. 4. The conference was attended by developers and OEMs, including the major OEMs‹DRI¹s key target market. Id. at 310-11. Microsoft charged attendees, who came to hear the "latest information" from Microsoft¹s executives and developers about Windows 3.1. Id. at 310. A newsletter was distributed to attendees. Id. at 314. The newsletter reported that DR DOS was incompatible with Windows 3.1. Id. Jon Lazarus, a Microsoft executive reporting to Steve Ballmer, gave the keynote speech. The first question from the audience following the speech was about DR DOS/Windows 3.1 incompatibilities. Id. In response, Mr. Lazarus did not admit that Microsoft had introduced the Nested Task flag bug, that Microsoft had put code in SmartDrv that would prevent it from running on DR DOS, or that Microsoft had hidden secret detection code in five different Windows modules that displayed false error messages when a user tried to run Windows 3.1 on DR DOS. Instead, he said Microsoft was "doing nothing" to create the incompatibilities and that it was up to DRI to fix the problems. Id. at 314-15. Thus, developers and OEMs left knowing that DRI had been excluded from the Windows 3.1 beta program, and they left with the impression that: (i) the rumors of DR DOS/Windows incompatibilities were true (confirmed in the newsletter), (ii) Microsoft had not created the incompatibilities (which plainly was not true), and (iii) Microsoft would continue to exclude DRI from access to the information it needed to fix the problems (which plainly was true).
12. All of this happened at a critical point in time for DR DOS. During the Windows 3.1 beta cycle, it was negotiating a potential OEM contract with IBM. See Wightman Dep. at 310-12, Engel Decl., Ex. 4. In November 1991, DRI responded to a request from IBM with a DR DOS licensing proposal. Engel Decl., Ex. 19; Wightman Dep. at 311, Engel Decl., Ex. 4. In January 1992, DRI officials met with IBM in Florida to continue the negotiations. Id. at 311-12; Engel Decl., Ex. 20. IBM was expressing a high degree of interest in DR DOS, but Microsoft¹s campaign to create fear, uncertainty and doubt about DR DOS/Windows compatibility worked. IBM expressed concerns about this very issue:

• PROVIDING AND CONTINUING COMPATIBILITY WHEN MICROSOFT WILL CONTINUE TO ASSERT OTHERWISE"

Exhibit 268 at 5 & 8; see also Wightman Dep. at 312, Engel Decl., Ex. 4 (IBM concerned about DR DOS/Windows compatibility during negotiations). IBM ultimately decided not to license DR DOS.

1. Microsoft Ensured That Windows Would Be Incompatible With DR DOS.

1. Microsoft knew, of course, that DR DOS would be compatible with Windows 3.1 unless Microsoft took specific actions to prevent compatibility. DR DOS had proven its ability to support Windows, by ensuring full compatibility with Windows 3.0. See Exhibit 230.
2. As part of the plan, Brad Silverberg directed his Windows developers to "bind [Windows] closer to MS DOS." Exhibit 198. A number of ways to do this were suggested and discussed. Id.
3. On September 30, 1991, David Cole, the MS-DOS/Windows Group Program Manager, summarized (for Silverberg) the development team¹s proposal for creating incompatibilities between Windows 3.1 and DR DOS:

It¹s pretty clear we need to make sure Windows 3.1 only runs on top of MS DOS or an OEM version of it. I checked with legal, and they are working up some text we are suppose to display if someone tries to setup or run Windows on a alien operating system. We are suppose to give the user the option of continuing after the warning. However, we should surely crash at some point shortly later.

Now to the point of this mail. How shall we proceed on the issue of making sure Win 3.1 requires MS DOS. We need to have some pretty fancy internal checks to make sure we are on the right one. Maybe there are several very sophisticated checks so that competitors get put on a treadmill. Aaronr [Aaron Reynolds] had some pretty wild ideas after 3 or so beers, earleh has some too. We need to make sure this doesn¹t distract the team for a couple of reasons 1) the pure distraction factor 2) the less people know about exactly what gets done, the better.

Please advise.

Exhibit 206.

4. Two alternatives were proposed: (1) place some "pretty fancy internal checks" in Windows that will display a "warning" text to "put competitors on a treadmill," and (2) "crash" Windows if a user tries to run it with DR DOS. Microsoft did both‹despite the fact that even Microsoft¹s lawyers advised against creating intentional incompatibilities that would cause Windows to "crash." Exhibit 206.

1. Microsoft Introduced Incompatibilities in Windows 3.1, Including the AARD Code, "Bambi," the XMS Check, and the Nested Task Flag Bug.

1. Having told the market to expect DR DOS¹ incompatibility with Windows, Microsoft followed through on its threat.
2. Although Microsoft has repeatedly denied that it put code in the Windows 3.1 beta that checked for DR DOS, the evidence shows otherwise. Microsoft included code in at least one beta release in a module, called Smartdrv (which was code-named "Bambi") that explicitly checked for DR DOS (via INT 21h function 4452h‹a hexadecimal code that stands for "DR"). The detection technique is the same technique explained in the "Roger Sour" correspondence. See Consolidated Statement of Facts ¶¶ 256-60. Cliff Garrett, a member of Microsoft¹s Strategic Customers & Products OEM Team, stated: "I got the previous mailings info from DR personally. I have a person I can get internals from." Exhibit 202. Later that day, he posted an e-mail stating:

The OFFICIAL way to detect dr. dos is as follows.

1) set the carry flag

2) nt 2lh ax = 4452h

3) the carry will be clear if it is dr. dos, and set if it is pc-docs

Exhibit 201. Using this technique to detect DR DOS, Microsoft programmed the beta to display a fatal error message, "Invalid device interface. Unable to load," and then refuse to run. Users would not know that the message resulted from DR DOS detection code. Even putting aside the fact that Microsoft repeatedly misled the market by denying that it was engaging in this predatory conduct, there is absolutely no technical justification for the code. See Hollaar Decl. at ¶ 4; see also Barrett FTC Dep. at 100-10, Engel Decl., Ex. 14 (describing how original smartdrv problem was not caused by DR DOS and describing his beliefs that Cliff Garrett at Microsoft had contacted DRI using the false name Roger Sour).

3. Microsoft eventually replaced this code with secret, encrypted detection code that produced false error messages when users attempted to setup and run Windows 3.1 with DR DOS. See Hollaar Report at 2-14, Record Support, v.6 to Consolidated Statement of Facts.
4. To create these false error messages, Microsoft first had to develop code that would detect DR DOS when Windows was running on it. Microsoft knew the DR DOS detection code had to be precise or it would also detect OEM versions of MS-DOS. Exhibit 194. Microsoft also knew that placing a false "error" message in the Windows 3.1 was wrong:

2) The message has to be consistent with our other error messages (caution box etc.) and avoid making us look bad. The message below, in my opinion, leads us open to bad PR‹it surely is the outer boundary of rudeness. It is also fairly extreme compared to others in the product we have seen.

. . . .

I hate this whole thing. I think it¹s totally rude, reinforces the image that users have of us as the evil ones, etc.

Exhibit 194; see also Exhibit 238. Aaron Reynolds wrote and tested the DR DOS detection code, the "AARD Code." Reynolds Dep. at 30-31, Record Support, v.2 to Consolidated Statement of Facts.

5. During this time, Microsoft sought to ensure that its efforts to create the image that DR DOS was incompatible with Windows were effective. For example, Microsoft told beta testers in October 1991 that MS-DOS was "required" to run Windows:

For beta testers that report problems W/DR DOS and 3.1

DR DOS is an untested and therefore unsupported operating system. MS-DOS (or OEM versions of it) is required for Windows. Using DR DOS with Microsoft Windows is at the sole risk of the user. We don¹t support it.

Exhibit 231 (emphasis added). The following month (November 1991), Microsoft made the decision to put the AARD code in the final beta of Windows 3.1. Exhibit 239.

6. There is little doubt that error messages are an effective means of scaring users. Microsoft asserts as an "undisputed fact" that error messages are more effective than written documentation or even electronic documentation provided with the programs. See ¶ 3 of Caldera¹s Response to Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s "Perceived Incompatibilities" Claim, Section II.C., above. Microsoft chose a message that would scare users, without telling them that, in fact, no problem had occurred:

Detection for the absence of MS-DOS will be in the Final Beta Release (AKA beta 3) . . . the message will say: Non-fatal error detected: error # (Please contact Windows 3.1 beta support).

Exhibit 248 (emphasis added). The fact that it was a nonfatal error was at least as disturbing if not more disturbing than a fatal error. See Hollaar Dep. at 133-34 & 147-48, Engel Decl., Ex. 11; Goodman Rebuttal Report at 12, Engel Decl., Ex. 21.

7. There was no error. The AARD code (1) detected that DR DOS was the underlying operating system, and (2) displayed the false error message. Aaron Reynolds, the author of the AARD code, could not have testified more clearly: "There¹s no problem." Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts.
8. Microsoft also introduced an incompatibility earlier in the Windows 3.1 beta cycle that prevented users from installing Windows 3.1 with DR DOS. As part of the Windows 3.1 development process, Microsoft added DPMI support to Windows. In the process of implementing DPMI support, Microsoft created an incompatibility between DR DOS and Windows by failing to include a line of code that would have ensured the Nested Task Flag was set properly when protected mode was initiated. As a result, when users tried to install Windows on DR DOS, they encountered a fatal error‹the program halted and a message appeared stating: "Standard Mode: Fault in MS-DOS Extender." The message did not identify the cause of the problem. The evidence shows that Microsoft knew about the incompatibility, knew the cause of the incompatibility, and knew it could have corrected the error by adding a single line of code. Yet Microsoft did nothing to remedy the problem in the Windows 3.1 production release. Introducing this incompatibility resulted in no technical benefit to Windows. The incompatibility was not required for, or even helpful to, Windows in implementing DPMI or in running setup in Standard Mode‹in fact, it was a hindrance. Moreover, if DRI/Novell had been allowed to participate in the Windows 3.1 beta program, it would have been a relatively simple matter for DRI/Novell to code a work around that would have eliminated the incompatibility. See Hollaar Decl. at ¶ 3; Reynolds FTC Dep. at 70-72, Record Support, v.2 to Consolidated Statement of Facts.
9. In addition, during the Windows 3.1 development cycle, Microsoft added a "version check" to the Windows setup program that specified internal version 2.6 or higher for XMS (the extended memory specification). DR DOS failed to pass this version check, because it reported internal version 2.5. MS-DOS passed the check. Setup made no use of XMS, so the test was unnecessary for the proper operation of setup. Windows modules that used XMS included XMS version checks, but DR DOS passed all of those version checks. See Hollaar Decl. at ¶ 5.

1. Microsoft Intended That False Errors Would Cause OEMs and PC Users Not to Buy DR DOS.

1. Microsoft intended to scare OEMs and users, and thus eliminate DR DOS as a competitive threat. Microsoft¹s intentions were clearly stated by Brad Silverberg. David Cole sent Silverberg an e-mail asking, "what is the guy is supposed to do" when he sees the false error message? Silverberg responded:

What the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR DOS and then go out to buy MS-DOS. Or decide to not take the risk for the other machines he has to buy for in the office.

Exhibit 278.

2. Microsoft took no chances in this respect. The text of the false error messages said, "Non-fatal error detected. . . . Please contact Windows 3.1 beta support." When a beta tester called the Microsoft help desk, Microsoft did not tell users that the messages were caused by secret, encrypted detection code, but rather blamed the "problem" on DR DOS and told the user‹consistent with Mr. Silverberg¹s stated reason for the message‹that the user should buy MS-DOS instead. For example, beta testers asked:

I thought I¹d try RC 1 [Windows beta 3.1] on DR DOS 5.0 . . . a funny message is displayed.

Non fatal error detected: error number 2726

Please contact Windows 3.1 data support.

Press ENTER to cancel, or C to continue.

(Well, I * am * contacting beta support . . .)

If I press C, it works okay. However, this messes up my "automatic" batch test file I have. Is there any way to eliminate this message?

Microsoft responded:

Greg, you should be able to get rid of the message by using MS-DOS instead of DR DOS. You should send in a copy of bootable DR DOS floppy disk, with the error number written on the label. . . .

Exhibit 443 (emphasis added).

3. When a Microsoft beta support group member asked Andy Hill (MS DOS Developer), what Microsoft can tell a customer, "about compatibility or not with DR DOS 6?," Hill replied:

The standard response is: Windows is only tested with MS-DOS operating systems. DR-DOS claims to be 100% compatible with MS-DOS, so if that is true, then the user shouldn¹t have any problems.

There is really nothing we can do.

Exhibit 291 (emphasis added).

4. OEMs who called in were told that "Windows was not supposed to work with DR DOS." Deposition of Stefanie Reichel ("Reichel Dep.") at 61-62, Record Support, v.2 to Consolidated Statement of Facts.
5. Mr. Silverberg made certain beta testers who called in were told they needed MS-DOS, not DR DOS, to run Windows. He directed the Windows 3.1 beta support to say:

windows is designed and tested for ms-dos. not dr dos. it says MS-DOS on the box, not MS-DOS or DR DOS . . . this is what to tell the world (in a nice way). using a system other than ms-dos puts the user at his own risk. it says this very clearly first thing in the readme.

there is another "fix" for them: use ms-dos. that should be mentioned in addition to telling them that digital research is providing them with a new version.

Exhibit 292 (emphasis added); see also Exhibit 263 (Silverberg instructed the Windows 3.1 beta support group to post "a nice SOL [___ out of luck] message. bottom line is that he needs ms dos‹something that is compatible with windows").

6. The campaign was effective. For example, a disgruntled end-user in Canada wrote to Digital Research (by then, a division of Novell) in July 1992:

Exhibit 317 (emphasis added).

1. Microsoft¹s Campaign Succeeded In Scaring OEMs and Users Away From Buying DR DOS.

1. The Windows 3.1 beta containing the AARD code 12,000 to 15,000 sites just prior to Christmas 1991. Deposition of David Cole ("Cole Dep.") at 178, Record Support, v.1 to Consolidated Statement of Facts; Exhibit 290. The Christmas beta was a "preview" beta: "essentially for‹it is a marketing tool to get the product into the hands of people making buying decisions." Barrett Dep. at 77, Engel Decl., Ex. 16. Members of the press also got this beta. Id.; Cole Dep. at 178, Record Support, v.1 to Consolidated Statement of Facts.
2. Microsoft¹s Windows 3.1 Compuserve forum started receiving users¹ concerns about the detected "error" almost immediately. Such postings were, and would remain, available for viewing by all beta sites‹which included significant OEMs, ISVs, influential end-users, and media analysts. The following are examples of postings related to the AARD code:

December 22, 1991:

I was able to install build 61D on my laptop using MS-DOS 5, with no problems. However, when starting this, under DR DOS, I get a non fatal error number 2726 upon startup. I enter C to continue. Everything appears to work properly anyway. I realize that this is most probably due to problems with DR DOS.

December 28, 1991:

While setting up a beta test on DR DOS 6.0 the following was noted:

Non fatal error detected error number 4D53

I will make a report on the correct form after I try to reproduce the problem on another machine with DR DOS 6.0.

January 12, 1992:

I don¹t know about you but I have encountered some problems using DR DOS 6.0 with 3.1. Even with my config.sys and Autoexec.bat stripped down, I still get an error message on startup, but performance was adequate, despite the non fatal error.

Of note is an article I read in a local computer freebie magazine, that accused MS of designing 3.1 to not work with DR DOS 6. I assume (hope) that this is not true.

January 22, 1992:

I am receiving an error: non fatal error 2726 when starting Windows 3.1. Windows then starts correctly, but this error is printed every time Windows is started. The problem goes away if I boot under Compaq DOS 3.1. My regular operating system is DR DOS 6.0. Is there an incompatibility between DR DOS and Windows?

February 14, 1992:

I got some trouble with WIN 31 (final beta) on setup over a previously installed Windows 3.0‹after starting setup (automatic mode) the message‹non fatal error detected number 453‹appeared. . . . I¹m running DR DOS 6.0. . . . What can I do???

Beta Site:

Last I heard DR DOS did not work with Windows 3.1. Since MS is not about to help DR clone DOS, they are not likely to help them (DR) solve their WIN 3.1 incompatibilities. It¹s all up to DR to fix their DOS problems.

Beta Site:

. . . I wanted DR DOS for home because it provides a cheap method of doubling hard disk space + a lot of other utilities my home machine isn¹t budgeted for. Yet if Microsoft is going to make life difficult for DRI guess DR DOS isn¹t an option since I need to run the current betas.

Beta Site 1:

. . . . Has anybody got any confidence that DR will fix its WIN 3.1 problems?

Engel Decl., Ex. 22 (emphasis added).

3. The AARD code directly impacted OEMs¹ decisions to license DR DOS or MS-DOS. Theo Lieven, CEO of Vobis, specifically stated he was "concerned" about the "nonfatal error" message. Reichel Dep. at 58, Record Support, v.2 to Consolidated Statement of Facts.
4. Bruce Fryer, product strategy manager of Zenith Data Systems in 1992, testified his software engineers ran into the AARD code during beta tests of Windows 3.1 on DR DOS. Deposition of Bruce Fryer ("Fryer Dep.") at 59, Record Support, v.3 to Consolidated Statement of Facts. The engineers determined that "this error message in fact didn¹t reflect any operational problems or incompatibilities." Id. at 110. Even so, Zenith abandoned any further consideration of DR DOS 6.0 based on objective fear that "Microsoft might intentionally put code in Windows that would cause problems with DR DOS." Id. at 112.
5. Other OEM deponents testified that a "nonfatal error" would cause "a great deal of concern among the testers." Deposition of Gary Bachelor ("Bachelor Dep.") at 80-81, Record Support, v.5 to Consolidated Statement of Facts. This was "[b]ecause we wanted compatibility in the products," and "those nonfatal error messages could cause just those sorts of concerns. . . ." Id. at 81; see also Frankenberg Dep. at 105, Record Support, v.3 to Consolidated Statement of Facts ("Well, it would be an indication that this software wasn¹t completely bug free, that it had problems of some type in interacting with other software on the system. . . .").
6. Review of the CompuServe forum messages pertaining to the other incompatibilities demonstrates that Microsoft¹s other FUD were equally devastating.
7. Exhibit 22 to Engel Decl. is a subset of the CompuServe forum messages. The messages show: users who complained of problems were told to switch to MS-DOS; numerous users encountered and complained about the problems created by the incompatibilities Microsoft created; Microsoft blamed the problems on DR DOS; users who complained of problems were told they should switch to MS-DOS; users were aware of and concerned about Microsoft¹s decision to blacklist DRI from the beta program; users recognized that DRI did not compete in the Windows market; and even though users recognized that DR DOS was a superior product to MS-DOS, the incompatibilities were forcing them to use MS-DOS instead. A few quotes follow:

1. Microsoft¹s response to the reports of errors:

We don¹t test against DR DOS. You should use MS DOS.

If you¹re using DR-DOS, I wouldn¹t expect it to work. Are you using

DR-DOS?

You should be able to get rid of the message by using MS-DOS instead of DR-DOS.

[Statement to a trade press reporter] Oh, I forgot to say that Windows is designed and tested to work with MS-DOS. We do no testing at all with DR DOS and we do not know first hand whether it¹s compatible with Win 3.1 or not. There is no code in Windows that says, "if DR-DOS then. . . ." We don¹t detect it.

[From a user:] Jeff, I talked with someone from Microsoft after I first reported the problem, and after the article in PC Week, and the claim is that there is a substantive problem with DR DOS, most probably in the memory handler.

Sorry, but Windows is designed and tested for MS-DOS. DRI claims 100% compatibility with msdos. if that were indeed true, then windows would just work.

Here¹s the straight story on this Marty. Windows 3.1 is designed and tested only on MS-DOS and OEM versions of MS-DOS version 3.1 and higher. Running Windows on any other system will result in unpredictable results. We are not working, nor do we plan to work with DRI on this issue.

[From a user:] The official line from MS about DR-DOS is that "Windows has not been tested with DR-DOS." That¹s probably about all you¹ll get out of them.

2. Statements from users and OEMs encountering incompatibilities created by Microsoft:

This is a realy big issue with us. DFM Systems ( the company I work for ) Manufactures a Touch Screen Notebook computer and planned on using Windows for Pen computing. We also "burn" DR DOS into a psudo drive in the BIOS. If Windows won¹t work with DR 6.0 it will be a big mess. I can get windows to come up, but so far it has mucho problems. With EMM386 ( it claims it ( windows ) can¹t load the driver, I can load the network drivers, and login, however, vpipx claims that the driver is not loaded, there are 2 or 3 error numbers that I have to <C>ontinue thru, and I haven¹t yet gotten SuperPCK to run, nor SuperStore. needless to say, performance is not pretty. I upgraded the machine I use day to day with DR 6 and had to resort to my floppy boot disk to continue with my daily work.

I¹m having mega problems getting this beta to install, and I run DR6.

I can¹t get past the second diskette when installing 3.1 beta release 2.

DRDOS 6 flatly refuses to run 3.1, in fact it even causes the new himem.sys to fail.

DRDOS 6 will *not* allow the beta to install. I¹ve left numerous msgs to Andy, none answered yet. Also called the tech line, no answers. Getting rather tired of no answers. Got confirmation from DRI that v6 won¹t work, and M-S and DRI aren¹t talking about it to each other, either.

Precisely why I use MS-DOS 5. Good luck.

Having total failure installing this beta with DR DOS v6. Lots of reports saying beta will not run with DRDOS at all. I can confirm it for you. What¹s the scoop now? Can MS send me a copy of MSDOS 5 as a lender for this testing? Send me a copy to replace DRDOS entirely??? I¹d be glad to give up DRI if they want to send me a copy of MSDOS5.

Build 60 runs great under DRv6 in enhanced mode, but croaks in standard mode.

My build 60 doesn¹t run with DRDOS 6 in any kind of mode. HIMEM.SYS even generates an instruction for me to call Micrososft.

It is true that 3.1 does NOT work with DR-DOS 6.0. I tried it on my ALR and 3.1 just refuses to install. (I had to uninstall DR-DOS to get back to MS-DOS 4.01.)

This confirms my finding that DrDOS v6.0 is NOT compatible with Windows version 3.1.

Thats right Windows 3.1 won¹t work at all (or at least in my trials) with DR-DOS v6.0. I stripped it down (DR-DOS that is), changed memory managers and anything else I could have thought of and nothing!

[In response to compatibility problems] I really must say that the good people of Microsoft have vastly reduced the confusion of which OS to upgrade to from 4.01!

Last I heard Dr DOS did not work with Windows 3.1. Since MS is not about to help DR clone DOS, they are not likely to help them (DR) solve their Win 3.1 incompatabilities. It¹s all up to DR to fix their DOS problems.

Also, I tried DR DOS on a couple of installations‹all had compatibility problems which I traced to DR DOS. We have installed MS-DOS 5 on these computers and the problems went away. We are recommending to our clients to stay away from DR DOS.

Cannot install under DR DOS, i tried both version 5 and 6, Boot under MSDOS 5 and install, still get the errors I mailed to you. I See in info from another Beta source, Smartdrv.exe will not load under DR DOS. Is there anything special I should do? I will try QEMM and 386MAX and try to get a config that will work.

[Microsoft responds:] DR-DOS has not been tested under Windows 3.1.

Has anyone else tried loading Build 61d under DR DOS 6.0? Setup gave several error messages and then Abended. Will try RC1 and advise. Uploaded MSD report and no response yet.

With NO mem mgrs installed at all, Setup for Build 61d & RC1 Abend with "Standard Mode: Fault in MS-DOS Extender" & a register dump.

I recently bought a copy of DR Dos 6.0 to try it out. After I had installed it I tried to load Windows 3.1 RC1. When I ran the setup program, it told me that the XMS manager that was loaded was not compatible with Windows. The DR Dos manuals say that it was compatible with Windows 3.0. Is there any type of update that will fix this problem so that Windows 3.1 will run under DR Dos 6.0? I would appreciate any help anyone could give me on this subject. Thanks.

3. Statements about press coverage of the problems:

Well, basically, the article stated that DRDOS 6 has trouble with Win 3.1 due to differences in memory management techniques, that Microsoft considers it DR¹s problem and isn¹t about to help, and that DR says they have been locked out of the Win beta process. I think that covers the highlights.

It¹s DR.DOS¹s problem is what I have read in the rag¹s I get.<g>

4. Statements asking if users can contact DRI:

Is it permissable to ask Digital Research for assitance in problems with DRDOS6 and Win 3.1 (60) ?

My answer yesterday was a curt, but flat no don¹t you dare!!!!! Remember a thing called NDA???? I¹m strictly adhering to it, but wish MS would talk with DRI.

[Response from Microsoft] Jeff, Don¹t say anything about 3.1 to DRI.

5. Statements recognizing that DR DOS was a better product and that it did not compete with Windows:

1. DR DOS was damaged as a result. For example, DRI lost the Sears account to MS-DOS because Sears demanded that DRI guarantee DR DOS would be compatible with future versions of Windows‹something DRI was reluctant to do in light of Microsoft¹s apparent plan to create intentional incompatibilities. A Microsoft document reports the incident:

DR has since faltered by not agreeing to sign the Sears contract which included a guarantee to run future versions of Windows. With this misstep, Johnk, DebbyRea, and Don Hardwick were able to get Sears to sign up for MS-DOS 5.

Engel Decl., Ex. 23 (emphasis added).

2. Robert Frankenberg, who at the time was Vice President at Hewlett Packard, summarized the view among OEMs that they could not risk licensing DR DOS since Microsoft intended to prevent DR DOS from remaining compatible with Windows:

[T]here was a significant amount of fear, uncertainty, and doubt in the industry surrounding whether [DR DOS] would remain compatible with Windows, and that had a significant impact on whether people believed that it would continue to be a viable platform.

Frankenberg Dep. at 56, Record Support, v.3 to Consolidated Statement of Facts.

3. Even Microsoft recognized that the combined impact of the beta test exclusion, incompatibilities and AARD code had been devastating to DR DOS. In December 1991, Brad Silverberg stated:

Exhibit 256 (emphasis added); see also Exhibit 294 ("It¹s truly a wonderful thing that we¹ve done to DR¹s sales in the last 2 mos. Some of this was due to W31 [Windows 3.1] FUD. . . .").

1. Microsoft Publicly Denied the Truth About the Incompatibilities It Had Created.

1. Microsoft knew it¹s conduct was predatory. Whenever someone confronted a senior Microsoft executive with a question or an accusation about the AARD code and related matters, Microsoft denied the truth. As Cole said in his original e-mail about creating DR DOS/Windows incompatibilities, "the less people know about exactly what gets done the better." Exhibit 206.
2. A beta tester asked Brad Silverberg about exclusion of DRI from the beta program and the AARD code "error" message. Silverberg responded:

That¹s correct‹we have not made DRI a win 3.1 beta. . . .

I forgot to say that Windows is designed and tested to work with MS-DOS. We do no testing at all with DR DOS and we do not know first hand whether it¹s compatible with Win 3.1 or not. There is no code in Windows that says, "if DR-DOS then . . .". We don¹t detect it.

Exhibit 443 (emphasis added).

3. Mr. Silverberg¹s public statement is false in several respects. First, he says, "We do no testing at all with DR DOS and we do not know first hand whether it¹s compatible with Win 3.1 or not." But, as shown previously:

• Microsoft tested DR DOS 5.0 and 6.0 extensively itself, as well as contracting with independent testing laboratories to test DR DOS. Exhibits 116, 123, 210 & 168; Deposition of Tom Lennon ("Lennon Dep.") at 220, Record Support, v.1 to Consolidated Statement of Facts.
• Microsoft¹s tests and those done by independent testing laboratories and software industry reviewers confirmed that DR DOS was fully compatible with Windows 3.0, with the initial beta of Windows 3.1, and that DR DOS would be compatible with Windows 3.1 unless Microsoft purposely engineered incompatibilities into Windows. Exhibits 4, 78, 106, 109, 123 & 116; Deposition of Mark Chestnut ("Chestnut Dep.") at 47 & 54, Record Support, v. 1 to Consolidated Statement of Facts ¶ 210; ¶¶ _____, above.

1. In response to subsequent trade press inquiries about the incompatibilities, Microsoft consistently repeated the same false statement:

Microsoft does not test Windows on anything other than Microsoft¹s MS-DOS. We don¹t have the development or testing resources, nor do we consider it our job to test Windows on other systems.

Engel Decl., Ex. 24 (InfoWorld, November 22, 1993).

2. Silverberg¹s public statement is also false in that he says, "There is no code in Windows that says, ŒIf DR DOS then. . . .¹ We don¹t detect it." Yet, as shown above, the code was carefully designed to detect only DR DOS. See Response to ¶ 12 to Microsoft¹s Undisputed Facts Regarding the AARD Code.
3. Moreover, at one point, the Windows¹ development team proposed that the error message say, "The Windows setup program has detected another operating system on your machine." Exhibit 270. Silverberg responded:

I am wondering if we should change the detection words to say we failed to detect MS-DOS, rather than say we detected an operating system other than MS-DOS. The latter words would make people think we are looking for DR DOS . . . .

Id. (emphasis added).

4. Finally in 1993, sophisticated software developer, Andrew Schulman, succeeded in de-encrypting the AARD Code. He passed along his findings to the FTC, and sent an e-mail to Silverberg.

I have stumbled across a really awful piece of code (with the initials) "AARD"! in four separate programs in Windows. . . . This AARD code is deliberately obfuscated, encrypted with XORs, attempts to disable a debugger. . . . But after much effort by myself and Geoff Chappell, we have found that the purpose of this code (in Windows!!) is to check for genuine MS-DOS by checking several otherwise-irrelevant things in the DOS data segment. In two beta versions of Windows, this code when run on DR DOS produced error messages. . . . Brad, I am extremely pissed at Microsoft. I have been trying to defend you guys against what I thought were stupid allegations, and now I find out that in fact the company has done something really bad. I have passed my findings on to the FTC.

Exhibit 363.

5. Schulman¹s findings were reported in the September 1993 edition of Dr.  Dobb¹s Journal, a software industry publication. Silverberg responded to Schulman. His response was published in Dr. Dobb¹s Journal. As in the past, Silverberg denied the truth about what Microsoft had done:

It has never been the practice of this company to deliberately create incompatibilities between Microsoft system software and the system software of other OS (operating system) publishers. . . . The intended purpose of this disclosure message was to protect the customer and reduce the product support burden from the use of Windows on untested systems.

Exhibit 381 (Letter from Silverberg to Schulman in Dr. Dobb¹s Journal; emphasis added).

6. Silverberg¹s statement in Dr. Dobb¹s Journal stands in stark contrast to the statements he and others made in internal Microsoft e-mail:

what the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is dr dos and then go out to buy ms dos. or decide not to take the risk for the other machines he has to buy for the office.

Exhibits 277 & 278.

7. Schulman was not fooled. He responded to Microsoft:

Exhibit 369 (emphasis added).

1. SUMMARY JUDGMENT STANDARD

Summary judgment is inappropriate unless the record shows there are no issues of material fact and the moving party is entitled to judgment as a matter of law. Fed. R. Civ. P. 56(c). In the context of antitrust cases, courts are reluctant to grant summary judgment on the issue of whether a particular type of conduct is anticompetitive. See, e.g., Ratino v. Medical Service, 718 F.2d 1260, 1268 n.23 (4^th Cir. 1983) ("The question of whether a restraint promotes or suppresses competition is not one that can typically be resolved through summary proceedings. Rather, resolution must await a full-developed trial record.").

2. ARGUMENT

1. Caldera¹s Claims Are Section 2 Claims and Should Be Evaluated Under That Standard.

The antitrust laws permit‹indeed, encourage‹rivals to compete vigorously by producing better, cheaper, and more attractive products. Because of Microsoft¹s dominance, however, its actions must be "examined through a special lens: behavior that might otherwise not be of concern to the antitrust laws‹or that might even be viewed as pro-competitive‹can take on exclusionary connotations when practiced by a monopolist." Eastman Kodak Co. v. Image Technical Services, Inc., 504 U.S. 451, 488 (