How to Void Your Valuable Warranty

Try installing Quick Pascal 1.0 on DR DOS 3.40:

No valuable warranty for you!

What is going on there? It’s a long story…

In 1988, Microsoft became increasingly worried by a new upstart OS from an old rival, DR DOS. Over the years, Digital Research (DRI) had added DOS compatibility to its CP/M-86 based operating systems. Eventually DRI came up with the idea of ditching the CP/M functionality and offering a DOS compatible operating system.

Ordinarily DRI would not stand any chance, but in 1988, the DOS business was not business as usual. IBM took over the development of DOS in 1986 and produced DOS 3.3 and DOS 4.0. Microsoft’s systems group heavily focused on OS/2 and to a lesser extent, Windows 2.x. Microsoft was still licensing MS-DOS to OEMs as before, but there was just a skeleton crew maintaining DOS at Microsoft.

DOS 3.0 was released in 1984, which means that in late 1988, MS-DOS 3.x was getting a little long in the tooth. At the same time DOS 4.0 was not selling well and IBM was slow to fix problems which did not affect IBM hardware. Microsoft had trouble convincing OEMs to license MS-DOS 4.01, and even raised prices of MS-DOS 3.3 to convince OEMs to upgrade.

That created an opening for DR DOS 3.31, released in June 1988 as an OEM-only product. Before the end of the year, this was soon followed by DR DOS 3.32, 3.33, 3.34, and 3.35. In January 1989, DR DOS 3.40 was released.

Microsoft found some OEMs resistant to licensing MS-DOS, a problem that never existed before. DRI was offering ROMable DOS, something Microsoft did not offer at the time. Microsoft could not directly respond but heavily depended on revenue from DOS to finance other projects. Highest echelons of Microsoft’s management were worried:

From:    billg
To:      pascalm; russw; tomle
Cc:      philba
Subject: Dr dos
Date:    Thursday, September 22, 1988 12:41 PM

You never sent me a response on the question of what things an app
would do that would make it run on MSDOS and not run with DR-DOS.
Is there any version check or api that they fail to have? Is there
a feature they have that might get in our way? I am not looking
for something they cant get around. I am looking for something
that their current binary fails on.

This is a fairly urgent question for me and I have received
nothing.

Aaron Reynolds, a DOS expert and and one of the authors of DOS 3.0, had already examined DR DOS and found that DRI faithfully replicated all documented DOS functionality, and some undocumented too.

About two hours later, Bill Gates got the answer he was looking for, including the following comment:

The bottom line is that, given Aaron's current findings,
an application can identify DR DOS. However, most apps usually
have no business making the calls that will let them
decide which DOS (MS or DR) they are running on.

Do you think differently?

Bill Gates certainly did. Russ Werner’s (russw) Status Report for April, 1989 (sent on May 22, 1989) contained the following section:

DRI Competitive Response
------------------------

The first MS product with the non-tested DOS warning code, Quick
Pascal, was released. Tom Reeve and Cindy Kasin have committed to
implementing it in all new MS application and language releases
from this point forward, including international.

And that is why the bogus “valuable warranty” message shows up when running Quick Pascal 1.0 setup on DR DOS 3.40.

Analysis

How does the Genuine DOS detection code work? It relies on a lot of undocumented information which has absolutely no bearing on the operation of Quick Pascal, or indeed any standard user application.

A commented disassembly of the detection routine may be found here. The way it works is as follows:

  • Query the DOS version. If it is less than 3.30, consider everything OK, otherwise probe further.
  • Execute undocumented INT 21h/52h to get the DOS “list of lists” in ES:BX.
  • Use the undocumented fact that ES now points to the DOS data segment.
  • Look at the word at offset 4 in the DOS data segment, which indicates the version of the data format.
  • If DOS data segment version is greater than 1, consider everything OK. That handles newer, unknown DOS versions, although in reality the DOS data segment version did not change in DOS 5/6/7.
  • Otherwise load SI with 2DEh for DOS data segment version 0 (DOS 3.3) and 330h for version 1 (DOS 4). This is the offset of the current PSP in the DOS data segment.
  • Execute undocumented INT 21h/51h to get the current PSP.
  • Execute undocumented INT 21h/50h to set the current PSP to 0.
  • Check if the word at offset 2DEh/330h in the DOS data segment is now zero. If not, restore the original PSP and fail.
  • Execute undocumented INT 21h/50h to set the current PSP to 0FFFFh (in case the word just happened to be zero).
  • Check if the word at offset 2DEh/330h in the DOS data segment is now 0FFFFh. If not, restore the original PSP and fail.
  • If detection got this far, restore the original PSP and declare the OS a genuine MS-DOS or PC DOS.

Note that the code is run with interrupts enabled. That is problematic because some TSR or background task might gain control and try to use the current PSP. That would likely cause problems when the PSP is deliberately set to an invalid value.

The code obviously has no useful purpose per se, it simply checks whether certain completely undocumented aspects irrelevant to Quick Pascal match MS-DOS 3.3 or 4.0. Et voilà, FUD is successfully spread! At least for a while—DR DOS 3.41 released in July 1989 successfully passes the Quick Pascal check and the vaguely threatening message no longer appears.

Several years later Microsoft used the same tactic (with different code, the infamous AARD check) in Windows 3.1. That fact was well publicized and used against Microsoft in later anti-trust trials.

PS: Looking for images of DR DOS 3.3x disks. Their existence is well documented, but survivors appear to be surprisingly rare (unlike DR DOS 3.4x and later releases).

This entry was posted in Digital Research, DOS, Microsoft. Bookmark the permalink.

30 Responses to How to Void Your Valuable Warranty

  1. Yuhong Bao says:

    QuickPascal was only the first BTW. I remember seeing something similar in NTVDM when playing with MS C 6.0 for example.

  2. Yuhong Bao says:

    Looks like NTVDM used offset 332h for the PSP in the DOS data segment, which is probably why.

  3. @Yuhong: …wait, so it complains about the warranty when it’s running on Microsoft’s own VDM?

  4. Richard Wells says:

    It complains about running on an unknown VDM which appeared about 5 years after the check was written. Based on the less than ideal compatibility of early DOS emulation, that was one of the few cases checking made sense. Function 50h was a great choice for checking since it was one of the functions missed by most DOS compatibles prior to DR-DOS being introduced.

    IIRC, it was possible to trigger the warning on later versions of MS-DOS*. The mechanism of detection was not robust. Backfired fairly spectacularly since it convinced people that such warnings were always incorrect leading to widespread adoption of tools like MARK30 to force Windows 1.x programs to run in protected mode.

    * Possibly requiring the use of SETVER before installing. Been such a long time that I don’t remember the details.

  5. @Richard Wells: Yeah, I get why it does that, I just think it’s ironic that Microsoft software complains that a Microsoft platform might not be genuine.

  6. Michal Necasek says:

    Yes, the undocumented functionality checking would make sense if those apps actually used it. But the historical record clearly shows that the only actual purpose of those checks was to make DR DOS look bad. The check is specific enough that the only “applications” that might care would probably be network redirectors and Windows/386. Which is exactly why the check might easily fail in NTVDM — that kind of software not only wouldn’t but probably even shouldn’t run in NTVDM.

    I’d be really interested to know which later DOS versions might fail the check. I did a quick test with PC DOS 5.02, 6.3, and 2000, and MS-DOS 6.2/V and 6.22, as well as Windows 3.11 for Workgroups on top of MS-DOS 6.22. The Quick Pascal 1.0 warning did not trigger. It also didn’t trigger in OS/2 (tried 2.0 LA from Dec 1991 and MCP2 from 2002). It is plausible that some 3rd party software (QEMM?) might break it but I could not quickly find anything that would.

    I can confirm that the warning pops up in NT 3.50, 3.51 and XP, although interestingly not in NT 3.1 RTM or NT 3.1 SP3! That’s a bit unexpected.

  7. > I can confirm that the warning pops up in NT 3.50, 3.51 and XP, although interestingly not in NT 3.1 RTM or NT 3.1 SP3! That’s a bit unexpected.

    Maybe the NT 3.1 VDM uses an older DOS version than the NT 3.5 and later VDM? Just a wild guess, mind.

  8. Does it trigger if run on MS-DOS 7.x (the versions built into Windows 9x)?

  9. Michal Necasek says:

    No warning in Windows 98SE, either in the GUI or when booted into command line.

  10. Rugxulo says:

    What about atop FreeDOS?

  11. dosfan says:

    In 1991 Microsoft officially documented INT 21h functions 50h and 51h along with a few other formerly undocumented functions. Of course they were never going to document INT 21h function 52h and the SYSVARS table.

  12. Michal Necasek says:

    I don’t know. You tell me 🙂

  13. Michal Necasek says:

    True, for DOS 5 a number of previously undocumented APIs were documented. But not SYSVARS, not the DOS data segment, not the versioning in it. That was still secret sauce only known to Windows and redirectors.

    This is actually another example of that nonexistent “Chinese wall” between Microsoft OS and application developers — the app developers should not have even had this information. They certainly did not need it in order to implement the application.

  14. Yuhong Bao says:

    For fun, find the comment in the Word for Windows 1.0 source about the then undocumented ToAscii.

  15. Michal Necasek says:

    That is pretty funny indeed.

  16. dosfan says:

    There are worse comments in MS code. Look at PRIDEFS.INC (PRINT) in the DOS 3.21 or 3.30 OAK (look for “Aaron’s rambling” and shortly after “WARNING DANGER”). Of course this is the same guy who went on to write the infamous AARD code which is the epitome of bogus checks to crush the competition.

    Also one of the DOS function include files indicated which functions weren’t documented (it wasn’t even updated for DOS 5) and undocumented data structures were marked with ” CAVEAT PROGRAMMER”.

  17. Yuhong Bao says:

    Yea, you probably already noticed Multitasking DOS 4.0 did not support INT 28h or InDOS, so most likely two versions would have to be written.

  18. buricco says:

    I remember QuickBasic Extended 7.1 complaining on Win2K in a similar way.

  19. Richard Wells says:

    DR DOS (and Concurrent and the related OSes) used the reserved bytes in directory entries for the various permission functions. Obviously, adding MS-DOS functions that used those bytes would have adversely impacted DRI. Okay, extended attributes on FAT made use of some of those bytes but otherwise MS left it alone until development of LFN and FAT32.

    It was counter productive for MS to try the FUD game. DOS Plus had major problems running MS-DOS 2.x programs. John Elliott has a web page describing why. Concurrent DOS XM (with claimed support equivalent to MS-DOS 3.1) had its own array of difficulties. While the inability to run MS Word 3’s spell checker under Concurrent DOS might be attributed to MS nefariousness, I doubt that applies to the problems with Word Perfect on Concurrent DOS on some hardware. If MS had left it alone, it might have taken years before DR-DOS was trusted for use instead of being little more than the equivalent of the Amdahl coffee cup as a negotiating ploy for a lower payment. MS being scared gave DRI credibility.

  20. Michal Necasek says:

    Everything he said was true. He just left out the other important bit: 5) Microsoft’s programmers will learn of the flag, start using it in their own products, and then the DOS group will be forced to support the undocumented functionality for ever and ever.

  21. Michal Necasek says:

    MS being scared may have given DR DOS credibility, but it was also the (beginning of the) end of DR DOS. With various shady OEM licensing deals and FUD, Microsoft was quite successful at squeezing DRI out of the market. But we can probably thank DRI for MS-DOS 5.x/6.x being what it was.

    As far as I can tell, DRI was essentially a non-entity in the DOS world until DR DOS 5.0. That’s when they got really noticed, because they put out a product that was in various aspects ahead of Microsoft’s. I must admit that I had not even heard of DOS Plus until fairly recently, and Concurrent DOS was always a very niche thing.

  22. Yuhong Bao says:

    @Michal Necasek: In the case of InDOS and INT 28h, MS eventually documented it but only after the multitasking DOS 4.0 project was cancelled.

  23. Yuhong Bao says:

    @buricco: Note that you may need to use forcedos to see the warning with for example PWB because of the OS/2 subsystem.

  24. Michal Necasek says:

    Sure, that is step 6) document the previously secret, undocumented, and purely internal feature because now that everyone is using it and knows about it, keeping it undocumented will only cause trouble by making people use it wrong.

  25. Kogias Ilias says:

    I was wondering about the actual warranty to be voided… What kind of warranty can a compiler possibly have? Only think I can imagine is the floppies. Otherwise, any programmer (which is the only buyer of a Pascal compiler) would just stare at the message and ROFL to death, or call Microsoft and ask for a hardcopy of the warranty about to be voided. I know I would.
    … Especially because, as a kid, I had found a book guide for C language and, consequently, managed to lay my hands on a C compiler (not easy on the time, the place and my resources), which happened to be Microsoft C. I actually gave up programming. Where was the warranty then?

  26. Michal Necasek says:

    That’s a really good question. I think you’re right that the actual warranty, if any, didn’t amount to much.

  27. God says:

    Grasping at straws here, but could this “warranty” be somehow linked to the “reliability” (whatever that could mean) of the code it generates?

    We are talking the late 80s – it could predate “absolutely no warranty, absolutely no responsibility, even if it kills millions of people by causing a meltdown in a nuclear reactor” being absolutely predicated and enshrined in software-related law.

  28. Richard Wells says:

    I can’t find any pre-1990 MS Languages licensing agreement to verify but I think the disclaimers as to fitness for purpose were there even back then. MS did offer support as part of the license. The MS warning in Quick Pascal probably means that anyone with problems would have the buck passed to DRI to prove their OS was not the cause of the problems.

  29. R O says:

    Re warranty concerns, if programs are to be used in a “validated” environment such as for pharmaceutical development and manufacturing, then that carries a lot of weight with the likes of the FDA’s approval process – not a joke to them (even if it is mindless bureaucratic BS at work …).

Leave a Reply

Your email address will not be published. Required fields are marked *