Evile Empire
M$ Unveiled

What Bill Gates Doesn't Want You to Know
  Sorry, but Bill does NOT know best.

Case Study: Pure Microsoft Evil 
      i.We Are Borg 
      ii.Control the Internet 
     iii.Job 1: Leverage Market Share 
     iv.Internet Explorer Integration 
      v.Bribes 
     vi.Lies, Manipulation, Corporate Fraud 
     vii.Microsoft Brainwashing and Sweatshop Machines 
            MS Exploits Free Job Labor from ClubIE Members 
            MS Exploits Free Job Labor from MVP Program Members 
            Fraud is Used to Brainwash Members Into Serving MS 
            How MS Treats Its Supporters 
            Perma-Temp Case Similarities 



The technical brief used by Caldera
A. Separate Consumer Demand for Two Products: DOS and Windows. *
B. Windows 95 Is Nothing More Than Windows 4.x and MS-DOS 7.x Packaged Together and Sold as a Single Product. *
C. Microsoft's Internal Documents Prove That MS-DOS 7.x and Windows 4.x Are Separate Products and There Was No Technical Reason to Package Them as a Single Product. *
    1. MS-DOS 7.x and Windows 4.x Were Developed as Separate Products. *
    2. Microsoft Packaged Windows and MS-DOS Together to Eliminate DR DOS and Novell
        as Threats to Its Desktop Operating System Monopoly. *
    3. Microsoft's Predatory Acts Caused Novell to Discontinue Development and Marketing of 
         DR DOS. *
 D. Microsoft's Engineers Admit the Falsity of Microsoft's Claim That the Windows 95 package Is an "Integrated" Operating System. *
    E. Consumer Demand Would Have Existed for Separate DOS and Windows 4 Products. *

Dos 5 vapourware campaign
   Microsoft's inglorious history of employing preannouncements in order to destabilise the opposition goes back a lot further than DR-DOS, to Windows 1.0 and beyond, but by 1990 the practice was thoroughly bolted into the company's systems and business practices. In an email to several Microsoft executives on 2nd May 1990 MS-DOS product manager Mark Chestnut said: "On the PR side, we have begun an 'aggressive leak' campaign for MS-DOS 5.0. The goal is to build an anticipation for MS-DOS 5.0 and diffuse potential excitement/momentum from the DR DOS 5.0 announcement. At this point, we are telling the press that a major new release from Microsoft is coming this year which will provide significant memory relief and other important features. This was picked up by the major weeklies in the U.S." 

  In addition, we learn that: " In a performance self-evaluation, Chestnut wrote 'virtually all of our OEMs worldwide were informed about DOS 5, which diffused DRI's ability to capitalise on a window of opportunity with these OEMs.'" At the time, one journalist, Paul Sherer (then with PC Week), interviewed Chestnut, which prompted him to email on 17 October 1990: " I'm afraid that this guy is going to write that we are being open about DOS 5 beta because we are trying to pre-empt DR DOS 5 sales. I tried real hard to present a different point of view, but I don't think he bought it. I'm concerned that this article may make us look bad. Can you guys follow up and see if we need to do some damage control? This was the toughest interview I've ever done, I felt like Richard Nixon giving his 'I am not a crook' speech." ®



How MS played the incompatibility card
   One of the claims by Caldera that Microsoft wanted dismissed concerned intentional incompatibilities between Windows and DR-DOS. David Cole and Phil Barrett exchanged emails on 30 September 1991: " "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," and "The approach we will take is to detect dr 6 and refuse to load. The error message should be something like 'Invalid device driver interface.'" 

  Microsoft had several methods of detecting and sabotaging the use of DR-DOS with Windows, one incorporated into "Bambi", the code name that Microsoft used for its disk cache utility (SMARTDRV) that detected DR-DOS and refused to load it for Windows 3.1.
  The AARD code trickery is well-known, but Caldera is now pursuing four other deliberate incompatibilities. One of them was a version check in XMS in the Windows 3.1 setup program which produced the message: "The XMS driver you have installed is not compatible with Windows. You must remove it before setup can successfully install Windows." Of course there was no reason for this. 

On whether Microsoft should have made a beta of Windows 3.1 available (called "predisclosed" in the jargon) to enable DR-DOS to be tested for compatibility, Judge Benson said that "the question currently before the Court is not whether Microsoft was under a duty to include DRI in beta testing, but rather whether excluding DRI from beta testing, in which it had previously been included, was predatory conduct under the attenuating circumstances" and went on to confirm that "the Court does intend to uphold the basic antitrust principle that a monopolist may not eradicate its competitors through anticompetitive means." 

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 and buy MS-DOS. Or decide to not take the risk for the other machines he has to buy for in the office.

                       February 10, 1992, e-mail from Brad Silverberg to David Cole, see Exhibit 278 to
                       Consolidated Statement of Facts.

Editors Take-
   This to me is a deliberate attempt to spike DR DOS and keep it from being a contender as a Windows base OS.



Win95 - is it just Dos 7 plus Windows 4 after all?
Brad Silverberg, who is now surely rich enough to hire somebody to work his shift key for him, was concerned early on about how to make DR-DOS run badly, or preferably, not run at all. He emailed Barrett on 27 September 1991: "can you tell me specifically what we're going to do to bind ourselves closer to ms dos? ... Let me emphasize the importance; ibm is going to announce the drdos deal at comdex (almost certain)." 

  Barrett replied: "The approach... is to use a vxd to 'extend' dos by patching it. ... We would  not patch unknown OSs and, most likely, would only patch MS DOS 5.x. The big advantage here is that it provides a legitimate performance improvement. However, it wont prevent us from running on foreign OSs (unless we explicitly decide to refuse to run) - they just wont run as fast. Is this the approach you want to take? Or would you prefer a simple check and refuse to run? Thats a lot easier but clearly quite defeatable. I'll come talk to you about it." Silverberg responded, "let's talk." 

  As he later drove development of Chicago, which would become Windows 95, Silverberg had plenty more to talk about, and the claimed illegal tying together of Dos and Windows to form Windows 95 is a key part of Caldera's case. In support of Caldera's standing to bring a technological tying case under sections 1 and 2 of the Sherman Act, and section 3 of the Clayton Act, an internal Microsoft strategy document dated 16 June 1992 admitted that Novell was its biggest threat: "Novell is after the desktop. As you know, they have acquired Digital Research and are now working hard to tightly integrate DR-DOS with NetWare. We should also assume they are working on a Windows clone and/or that they are working on a virtualised DOS environment which will run standard mode Windows as a client. This is perhaps our biggest threat. We must respond in a strong way by making Chicago a complete Windows operating system, from boot-up to shut-down. There will be no place or need on a Chicago machine for DR-DOS (or any DOS)." 

  In 1993, Microsoft's view of Novell was enough to make anybody's blood run cold, and it's a perfect example of the thinking that has propelled Microsoft to its present position. The statement is attributed by Judge Benson to "Microsoft executives" and no doubt in the fullness of time we shall know the identity of the would-be assassins. The message says: "If you're going to kill someone there isn't much reason to get all worked up about it and angry--you just pull the trigger. ... We need to smile at Novell while we pull the trigger." 

  As regards the tying together of MS-DOS and Windows into Win95, in an extremely surprising analysis, Judge Benson rejected the Court of Appeals for the DC Circuit's 1998 interpretation, and put forward the his own conclusion. He accepted that the evidence Caldera presented was sufficient to merit the view that Windows 95 effectively consisted of Windows 4.0 and MS-DOS 7.0, and that the matter could be presented to the jury. The future of this case does not bode well for Microsoft. ® 



EXAMINING THE WINDOWS AARD DETECTION CODE 
   It's significant that the message, which appeared when running on DR DOS (including Novell's "Novell DOS 7" beta), did not appear when running on MS-DOS or PC-DOS. This raises the question then, what causes the error message? As it turns out, finding the answer required substantial system-level sleuthing, an interesting challenge in its own right.
   The crucial and, appropriately, most obfuscated test, however, appears at the end of the AARD test gauntlet. This test, which was unraveled by Geoff Chappell (geoffc@cix.compulink.co.uk) first checks to see whether a network redirector (such as MSCDEX) is running. If a redirector is running, the AARD code checks that DOS's default upper case-map is located in the DOS data segment. If a redirector is not running, the code checks that the pointer to the first simulated-file control block (FCB-SFT) is located on a paragraph boundary; that is, it has a 0 offset.
   In other contexts (such as MSD's need to identify the operating system), it would be perfectly legitimate to walk internal DOS data structures to see that they were the same as would be expected under genuine MS-DOS. However, that WIN.COM and other programs incorporating AARD code don't make any use of the information gained in this way, other than to print the non-fatal error message, suggests a deliberate incompatibility, rather than a legitimate need to know some information about the underlying DOS.
   The very non-fatality of the "error" further underscores the fact that it isn't Windows's legitimate business to care whether it's running on genuine MS-DOS. If the program can continue running despite the detected "error," then how much of an error was it to begin with? It seems that the only "error" is that the user is running Windows on someone else's version of DOS.
   The effect of the AARD code is to create a new and highly artificial test of DOS compatibility. The obfuscations and encryptions make it difficult to even determine what is being tested. An indication that the AARD code's obfuscation is successful is the fact that Novell's most recent version of DR DOS (that  is, Novell DOS 7) fails the test, even though it is otherwise far more compatible with MS-DOS than previous versions.

Why the purely arbitrary test that only MS-DOS would pass, and then why encrypt it, obfuscate it, and attempt to disable a debugger that¹s stepping through it? No, I think the code is very sleazy.

                            July 23, 1993, e-mail from Andrew Schulman, independent software expert, to
                            Microsoft, see Exhibit 369 to Consolidated Statement of Facts.