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).
QuickPascal was only the first BTW. I remember seeing something similar in NTVDM when playing with MS C 6.0 for example.
Looks like NTVDM used offset 332h for the PSP in the DOS data segment, which is probably why.
@Yuhong: …wait, so it complains about the warranty when it’s running on Microsoft’s own VDM?
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.
@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.
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.
> 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.
Does it trigger if run on MS-DOS 7.x (the versions built into Windows 9x)?
No warning in Windows 98SE, either in the GUI or when booted into command line.
What about atop FreeDOS?
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.
I don’t know. You tell me 🙂
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.
For fun, find the comment in the Word for Windows 1.0 source about the then undocumented ToAscii.
That is pretty funny indeed.
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”.
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.
Also fun is this by Gordon Letwin in 1984: https://groups.google.com/forum/#!search/gordon$20letwin$201984/net.micro.pc/Z3i3OeJBUC8/2dlYALGYBNEJ
I remember QuickBasic Extended 7.1 complaining on Win2K in a similar way.
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.
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.
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.
@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.
@buricco: Note that you may need to use forcedos to see the warning with for example PWB because of the OS/2 subsystem.
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.
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?
That’s a really good question. I think you’re right that the actual warranty, if any, didn’t amount to much.
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.
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.
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 …).
(Sorry for late reply on old post.)
> 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.
Yes, MS-DOS 5 was vaporware for quite a while due to DR-DOS influence and new features (HILOAD?). Quoting Wikipedia:
> Unwilling to lose any portion of the market, Microsoft responded
> by announcing the “pending” release of MS-DOS 5.0 in May 1990.
> This effectively killed most DR DOS sales until the actual release of
> MS-DOS 5.0 in June 1991.
But that didn’t really stop them. AFAIK, Novell bought DR-DOS and first released 7.0 in 1994. Now that was later (mostly) discontinued (and sold off) with the success of Windows 95 (which bundled MS-DOS 7.0). Years later (2001?), Caldera did get a settlement (out of court??) from MS for that. It wasn’t bundled for technical reasons but rather to avoid the competition. Although even MS-DOS advertised (in its cheesy rap video) itself as “the best DOS to run Windows”, so they were clearly aware of and trying to avoid third-party vendors.
DR-DOS 7.03 is still sold online, but it hasn’t been modified since 1999. So it’s a bit outdated (e.g. multitasking requires 386 and its own DPMI and weird hybrid EMM386, but tasks are still limited to 64 MB each). It identifies itself as IBM PC-DOS 6.00 (for compatibility). Oh, and my copy did not have any FAT32 nor LFN nor LBA support.
So yeah, not super modern as far as DOSes go. (Even Datalight ROM-DOS 7, which I’ve never tried but is still sold online, I think?? supports LFNs and FAT32.) Actually, it might make an interesting article comparing such DOS clones! Feel free to do it!
> 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.
AFAIK, DR-DOS 5 was compatible with MS-DOS 3.3 while DR-DOS 6 was compatible with MS-DOS 5. (Very confusing, I know.)
Another major factor in the DR-DOS story is Amstrad’s release of one of the first low cost PC clones in the UK in 1986. Originally Microsoft would not licence them MS-DOS cheap enough, so Amstrad contracted with Digital Research for DR-DOS (v1) which was able to run most ms-dos apps at the time. Microsoft soon offered Amstrad a better deal …
Did the Amstrad connection have anything to do with the fact that DR had a development center (centre?) in the UK at the time?
Maybe/probably.
I worked at the UK DR development centre, but the Amstrad deal had already been done by then, so don’t know the full details. We were working on DR-DOS v2 then (aimed at oems, not that many oems took us up on it?) which later became v3 after I left.
Correction – It was called DOS-Plus at the time. The DR-DOS name only came later with v3
Which Amstrad PC was that? The one that’s more or less the same as Schneider EuroPC?
Amstrad PC1512.
Correction to earlier post – the OS was called DOS Plus (1.0) at the time, and I worked on 1.2. Only later was it called DR-DOS (from v3 onwards?)
Correct #2 – Amstrad PC1512 came with DOS Plus 1.2 (and GEM) and with MS-DOS 3.2
Old DR DOS releases are really hard to come by. There is no DR DOS 3.3x that appears to have survived, and DOS Plus coverage is very spotty. I really hope someone is still sitting on old floppies, and that they’re still readable 🙂
They probably did similar things with MS Quick C. When you run a program inside the IDE of Quick C, you have compiled in Quick C, then the memory is not correctly freed, when then DOS Version is DR-DOS 3.41 or older.
This results in after n steps of running your program, you run out of memory and have to reboot. It might be a glitch of DR-DOS, but this does not happen in MS-DOS.