Geoff Chappell - Software Analyst
CURRENT WORK ITEM - PREVIEW ONLY
The most extensive list that I know Microsoft ever published, so to speak, of licensed OEM variants of MS-DOS is in the DOSSETUP.INI file on the installation discs for MS-DOS 6.00 and then in upgrade discs for minor versions.
The DOSSETUP.INI files on these discs are not in plain text. They are binaries in a possibly unique file format, almost certainly compiled in some way from a source document that is written in something like plain text. The overall purpose is, of course, to guide the SETUP program’s installation of the new DOS. Among the possibilities is that the new DOS is to replace a possibly very different old DOS. Deleting everything from the old DOS might go too far for an upgrade, but care is needed not to retain anything that might conflict. Within any one version of the old DOS, different OEM variants can have come with different programs and drivers that were thought to add value but which might now be problematic. There are many strategies for clearing the deck. Some old files are deleted, others renamed. Old drivers, even if they’re not deleted, are disabled by removing references to them in CONFIG.SYS. Some programs and drivers are retained for continued use but with a reconfiguration of SETVER.EXE so that they’ll think they’re still being run on the old DOS. To get all this right, SETUP needs to identify whose old DOS is being replaced and to know how to go about it—and the necessary information can only be on the installation discs. It might have been obscured in the code and data of some executable, even in the SETUP program, but it was apparently more convenient to have it lightly obscured in a self-standing database.
The particular DOSSETUP.INI file that I extract details from for this page is dated 10th March 1993. By then, MS-DOS was pretty much settled as a retail product such that the rich variety of OEM releases in early DOS versions was all but history. A catalogue of all OEM variants that ever got released would be unreasonable to expect. For one thing, Microsoft plausibly never had enough control over—nor even interest in knowing—the details of what its many OEMs did to its product. For another, comprehensiveness over either the whole of DOS’s history or the whole range of OEMs is not needed, just of old DOS versions that Microsoft perceived as worth troubling over for safely setting up MS-DOS 6.00. Still, that’s no small goal. Some effort evidently was made to track down OEM variants that were still in circulation, or even might be, for use on computers that the new DOS could possibly be installed on. There is in DOSSETUP.INI very much a sense of tidying up. Its data on old DOS versions would be worth having on the historical record just for Microsoft’s perspective near the end, even if catalogues of OEM variants were not otherwise so rare.
But first, some background to how I come to write about this now, in 2022, after nearly thirty years…
I had long forgotten that I ever looked at this. Setup programs hardly ever have my attention. My interest is in opportunities for novel interaction with running systems, by which time the setting up is done and dusted. That I had given even brief attention to the setting up of MS-DOS 6.00 turned up last year when the AARD code (in a Windows 3.1 beta from December 1991) was brought back to mind and I reviewed email with Andrew Schulman from the early 1990s for background to what I ever knew then of DR DOS from studying Microsoft’s programming—so, really, not what I knew of DR DOS but of what I knew of what Microsoft knew of DR DOS.
It may or may not surprise, depending on perspective, but explicit reference to DR DOS is exceedingly rare in Microsoft’s contemporaneous DOS and Windows programs, at least in the parts that I ever studied. I say this generally as one of the first people anywhere to have studied DOS at scale by disassembly, and I say it specifically as the first person outside Microsoft, as far as I know, to have understood what exactly the AARD code tested. That the AARD code’s target was DR DOS is beyond reasonable doubt—but it is not knowable from the AARD code alone, which merely tests whether what’s executing it is credibly MS-DOS (including PC DOS and other licensed variants).
Something similar is true of other cases that are sometimes cited as dirty tricks directed at DR DOS. On 20th April 1993, Andrew sent me a draft of what would eventually be pages 199 to 204 of Undocumented DOS, Second Edition, ISBN 0-201-63287-X. The topic was what may be Microsoft’s earliest test for MS-DOS, seen then in a “QC.EXE (dated April 6, 1990)” from Quick C but since known in a QP.EXE dated as long ago as 4th May 1989 from Quick Pascal version 1.0. Andrew’s draft had it that the “sole purpose of this code is to make QuickC users think they shouldn’t be running DR DOS”—and as shown pictorially at How to Void Your Valuable Warranty, the test does indeed catch DR DOS version 3.40—but neither the test’s coding nor the text that’s shown if the test for MS-DOS fails makes any explicit reference to DR DOS.
At the time, I was not at all concerned with whether evidence actually did exist that the test was directed at DR DOS. My criticism of the draft was for what I saw as the far greater defect of overlooking the recklessness of some programming in Novell NetWare. Microsoft’s test temporarily changes DOS’s current PSP to 0000h and FFFFh to see if these changes turn up in the MS-DOS kernel’s data exactly where expected. Andrew, as have many others since, took these values as unexpected and even as perverse. My assessment, then and since, is that in an idealised world where all DOS programmers understand the theory of DOS’s limited re-entrancy, and bother to conform to it, Microsoft’s test is safe. Indeed, Microsoft’s programmers had good cause to think that if they must test invasively, then what they devised was optimally small, quick and unobtrusive. In the real world, however, it fouls NetWare’s hook of int 21h function 50h. Looking now in 2022 I notice that the test’s use of int 21h function 50h to set these peculiar values attracted no comment when captured on page 19 of the earlier edition, Undocumented DOS, ISBN 0-201-57064-5, from October 1990. That it got Andrew’s attention in 1993 was because Novell complained of collateral damage. There was a good story to be had from this, certainly, but we differed completely on perspective: he sympathised with Novell and I thought Novell had barely begun to get what their programming deserved.
Still, I evidently did keep in mind Andrew’s interest in DR DOS. As it happened, MS-DOS 6.00 got its commercial release at roughly this time and I bought it a few days later, on 24th April 1993. After a few more days, email to Andrew on 29th April 1993 reported that the SETUP program’s automated identification of the existing DOS installation detects DR DOS specifically:
The funny thing is that given DOS version 3.31, Setup will look in files COMMAND.COM, KEYB.COM and UNDELETE.COM for the string "Digital Research". If any of these are found, the subsequent menu box highlights OTHER as the DOS type. This is the only case where OTHER will be chosen automatically. I was wondering if it is one rare instance of Microsoft code recognising DR-DOS (specifically, as against general defensiveness).
Having long forgotten all this myself, I can’t be surprised if it was never picked up by anyone else, yet the question of what attention Microsoft gave to DR DOS was no small background in court cases over the next decade or two. Roughly speaking, recognition of DR DOS by Microsoft as a competitor to MS-DOS was something that Caldera, who owned DR DOS by then, sought to emphasise and Microsoft to diminish. Make what you want of it from each side’s court filings, but here, in 1993, when Microsoft wanted to help its MS-DOS customers get rid of their DR DOS, it evidently suited Microsoft to recognise DR DOS even to the point of accepting it as some sort of OTHER DOS.
For the presentation that follows of OEM variants as known from DOSSETUP.INI, my aim is to capture what SETUP can list as the DOS Type on the early screen whose main content looks something like the following.
Setup will use the following system settings: ┌───────────────────────────────────────────────────────────┐ │ DOS Type: MS-DOS │ │ MS-DOS Path: C:\DOS │ │ Display Type: VGA │ │ │ │ The settings are correct. │ └───────────────────────────────────────────────────────────┘ If all the settings are correct, press ENTER. To change a setting, press the UP ARROW or DOWN ARROW key until the setting is selected. Then press ENTER to see alternatives.
When SETUP is run on an old DOS, it can know this existing DOS’s version number from what int 21h function 30h returns in al and ah. This function also returns an OEM number in bh, but most OEM variants return either 00h or FFh for this, rather than anything more reliably informative, and SETUP apparently does not use it, even when it is not 00h or FFh. The OEM names that SETUP lists as possible for the installed DOS version are instead learnt from DOSSETUP.INI. There are two parts to this: what can be identified with confidence; what can be listed for the user to choose from.
Automated identification comes from the OEMTABLE section. For each DOS version from 2.11 to 6.00, the OEMTABLE lists files for SETUP to examine. For each file, the table lists sequences of characters whose presence in the file suggests that the installed DOS is a particular OEM variant. The first match for the installed version is what SETUP shows by default for the DOS Type. Importantly, not all the OEM variants that are known to DOSSETUP.INI can be identified automatically.
Separate from the OEMTABLE are sections for each of the known OEM variants, distinguished by the OEM’s name and the DOS version number. These sections are where DOSSETUP.INI tells what to do for cleaning up the old DOS installation. Importantly, DOSETUP.INI has more of these sections than the OEMTABLE section has of OEM variants that can be identified from searching files.
My organisation of the DOSSETUP.INI database of OEM variants tries to synthesise the one representation from these two parts. The table for each DOS version has one row for each OEM variant that SETUP can list as the DOS Type for the user to select from. For those OEM variants that are also in the OEMTABLE itself, the second and third columns show how the variant is identified automatically by searching for text in files. I do not represent anything of the cleaning up, just of what OEM variants are known to the database and of how they are identified.
For some few cases, but for more if I persist with it as an occasional diversion, I link to an abandon-ware site where the information from DOSSETUP.INI can be verified against disk images. Regrettably, most information that circulates about OEM variants of old DOS versions is at the level of very rough folklore. This was entirely understandable in the 1980s and 1990s when obtaining any OEM variant typically came at the cost of obtaining a matching computer, but it is unforgivable now in the 2020s when OEM variants are readily available (lawfully or not) on abandon-ware sites.
DOS version 2.xx exists in OEM variants for computers that are so far from PC compatibility that MS-DOS 6.00 likely could not boot. Such variants arguably should not be expected in DOSSETUP.INI, for surely the SETUP program detects first that there’s no point to proceeding. Even if if it doesn’t, it might be forgiven: since version 2.11 is known from as early as 1983, Microsoft’s giving it any attention at all in a setup program ten years later must count very much to Microsoft’s credit.
As it happens, the attention that version 2.11 was given is not insubstantial. DOSSETUP.INI lists five OEM variants to identify by searching files and one more to list as an option in addition to plain MS-DOS and OTHER:
| OEM | File | Identifier |
|---|---|---|
| MS-DOS | ||
| AT&T | gwbasic.exe | "AT&T" |
| fdisk.com | "Siegmar Schmidt" | |
| ramdisk.dev | "PSQRWV" | |
| OLIVETTI | format.com sys.com hexdump.com |
"Olivetti" |
| TANDY | lpdrvr.sys | "TANDY" |
| UNISYS | command.com | "SPERRY Personal" |
| WYSE | gwbasic.exe format.com |
"WYSE Tech" |
| sys.com fdisk.com |
"Wyse Tech" | |
| ZENITH | ||
| OTHER |
Inasmuch as Microsoft would have listed an IBM variant if one existed, the DOSSETUP.INI list is supporting evidence that there is indeed no PC DOS version 2.11. Instead, a PC DOS 2.10 is known from archive sites. Something similar may apply to COMPAQ, who one might think already had Microsoft’s attention almost as much as did IBM. The suggestion then is that no COMPAQ version 2.11 exists, either. What an archive site presents as a 2.11 [Compaq OEM] answers int 21h function 30h as version 2.10—as does the slightly different IBMDOS.COM from 2.12 [Compaq OEM].
The version 2.11 from OLIVETTI has a non-trivial OEM number, 23h, by which it might better have been identifed. All the others that are known both from DOSSETUP.INI and from an archive site have FFh as the OEM number. This includes ZENITH, though later versions of it are known with the unique OEM number 05h.
The AT&T that I found for inspection does not have the ramdisk.dev file. Unusually, the identifer for this file is not text that suggests the OEM by name. It is instead, in upper case, a series of push instructions, for registers ax, bx, cx, dx, di and si. The TANDY has the expected lpdrvr.sys but the identifier is present only as “Tandy”, i.e., in mixed case, not upper case. My presumably quick notes on SETUP from 1993 do not record whether the identifiers are case-insensitive. The WYSE has a sys.com without “Wyse Tech” in any mix of case, and its fdisk.com has “WYSE Tech” not “Wyse Tech”. The ZENITH has copyright notices for Zenith Data Systems in many of its programs such as FORMAT.COM, so why it has no identifiers in DOSSETUP.INI is some small mystery.
See that tools for low-level disk access, often with the standard names FDISK, FORMAT and SYS, figure prominently among the files that SETUP searches. At least until version 3.20 introduced Generic I/O Control to DOS’s int 21h interface, OEMs had little choice but to write their own tools for such work as formatting DOS volumes. Even after this new support allowed the hardware-dependent aspects to move to IO.SYS or to a driver, some OEMs persisted with their own tools. To the MS-DOS 6.00 SETUP, some of these old tools are programs that are important to delete, e.g., so that an old FDISK.COM does not get executed in preference to the new FDISK.EXE. Because of this attention they may also have seemed natural as candidates for the automated OEM identification.
The user whose version 2.11 is not identified automatically may have wondered how to choose between MS-DOS and OTHER. As far as DOSSETUP.INI specifies, there is no difference. For both, SETUP is to delete fdisk.com and the same selection of kebyxx.com variants.
DOSSETUP.INI knows of version 3.00 only as MS-DOS, IBM PC-DOS and OTHER, with no automated identification at all.
Version 3.00 may be a little like 2.11 in that some OEM variants will have been specific to computers that are too far from PC compatibility for running MS-DOS 6.00. Yet this can’t be the whole explanation for why DOSSETUP.INI has so little data for this version. Notably, archive sites have a version 3.00 from COMPAQ (with OEM number 00h). Not only would COMPAQ not ordinarily be dismissed as insufficiently PC-compatible, but the COMPAQ version 3.00 is a good bit more advanced than the same version of PC DOS, e.g., for handling int 21h function 33h on the caller’s stack and for implementing int 21h function 5D0Ah at all.
Version 3.00 is arguably under-rated in DOS histories. It introduced file sharing and network redirection as optional extensions, and provided that a computer running MS-DOS could be a network server. But development of these features was uneven across OEMs. As with COMPAQ, some OEM releases of version 3.00 have functionality that was not widely established until version 3.10. In-between are a few known releases, notably for Apricot, that answer to int 21h function 30h as version 3.05 (though in Apricot’s case, nearby copyright notices are for “MS-DOS version 3.06”). DOSSETUP.INI does know of Apricot for version 3.30, but it knows nothing of anyone’s version 3.05.
It was version 3.10 that stabilised most of the DOS kernel’s data so that support for file sharing and network redirection as optional extensions could be less version-dependent. Not coincidentally it is the earliest version that Windows/386 and later Windows 3.0 Enhanced Mode ever tolerated. Hardware dependencies, however, lived on.
| OEM | File | Identifier |
|---|---|---|
| MS-DOS | ||
| IBM PC-DOS | ||
| COMPAQ | ||
| HP | ||
| OLIVETTI | enhdisk.sys hexdump.com |
"Olivetti" |
| TANDY | ||
| UNISYS | command.com | "SPERRY Personal" |
| graftbno.com | "MITSUBISHI" | |
| WYSE | sys.com | "WYSE" |
| ZENITH | format.com | "Zenith" |
| OTHER |
Version 3.10 is the earliest for which DOSSETUP.INI knows of COMPAQ. As with IBM PC-DOS, COMPAQ is left for the user to select. Both have OEM number 00h, but even this early COMPAQ already has the same feature that Windows versions since 2.01 in 1987 use to distinguish COMPAQ from IBM: the six letters of “COMPAQ” are at offset 06h in IBMBIO.COM (and in memory at segment 0070h).
The HP that has been found for inspection also has OEM number 00h. For it too, no automated identification is defined, though surely it could have been: its IO.SYS has a copyright notice for Hewlett-Packard (and if for some reason the DOS system files are not to be searched, then a copyright notice in FDISK.COM might have suited).
Though other versions of OLIVETTI have their own OEM number, 23h, the version 3.10 that is known from an archive site has FFh. This version of the ZENITH is the first that has the unique OEM number 05h.
| OEM | File | Identifier |
|---|---|---|
| MS-DOS | ||
| IBM PC-DOS | ||
| AMSTRAD | mouse.com | "AMSTRAD" |
| AST | keybuk.com hdformat.exe astcache.com fastdisk.sys |
"AST" |
| AT&T | fdisk.com | "AT&T Information" |
| graphics.com gwbasic.exe |
"By AT&T" | |
| ramdrive.sys | "AT&T/Microsoft" | |
| instldos.exe | "AT&T" | |
| COMMODORE | ||
| COMPAQ | ||
| EPSON | command.com | "EPSON" |
| HP | pamcode.com | "Hewlett-Packard" |
| LEADING EDGE | basic.com | "LEADING EDGE" |
| NEC | keybuk.exe | "NEC" |
| OLIVETTI | hexdump.com | "Olivetti" |
| TANDON | ||
| TANDY | fdisk.com | "Tandy Corp" |
| graphics.com mode.com |
"Tandy Corp." | |
| basic.exe mlformat.com |
"Tandy Corp" | |
| TOSHIBA | ||
| UNISYS | command.com | "SPERRY Personal" |
| graftbno.com | "MITSUBISHI" | |
| WANG | setspeed.exe | "WANG" |
| WYSE | gwbasic.exe | "Wyse Technology" |
| lcdpanel.sys | "LCDDEV" | |
| ZENITH | asgnpart.com | "Zenith" |
| OTHER |
All the OEM variants that are known to DOSSETUP.INI for version 3.20 and are yet found at an archive site have OEM number FFh, except for:
It’s perhaps as well to observe that even where the OEM’s name is the identifier that SETUP searches for, it is often present in a copyright notice, but is not necessarily. The AMSTRAD that has been found for inspection is an example. It has a mouse.com that contains AMSTRAD, but in an error message. The two copyright notices in the program are for MEJ Electronics Ltd.
For the ATT, the expected “By AT&T” in graphics.com and gwbasic.exe is present only as “by AT&T”.
The archive site I looked at does not have COMPAQ version 3.20, but Microsoft seems to have believed one exists.
An NEC version 3.20 is known, but it has a keybuk.com, not the expected keybuk.exe, and it does not contain the expected identifier. (Its copyright notice is for Phoenix Technologies Ltd.)
The TOSHIBA, if only as found for inspection, has the distinctive names TBIOS.SYS and TDOS.SYS for its system files.
The entry for WYSE in version 3.20 is problematic. It’s in the OEMTABLE section for identification by searching files but DOSETUP.INI has no section for listing WYSE as a DOS Type for version 3.20. It does for 3.21, however. Either way, none has yet been found for inspection.
| OEM | File | Identifier |
|---|---|---|
| MS-DOS | ||
| IBM PC-DOS | ||
| COMMODORE | speed.exe | "Commodore" |
| NEC | lcd.com | "NEC" |
| WYSE | lcdpanel.sys | "LCDDEV" |
| ZENITH | format.com | "Zenith" |
| OTHER |
The archive site I looked at does not have PC DOS version 3.21, but Microsoft seems to have believed one exists.
| OEM | File | Identifier |
|---|---|---|
| MS-DOS | ||
| IBM PC-DOS | ||
| ACER | ||
| APRICOT | ||
| AMSTRAD | mouse.com | "AMSTRAD" |
| AST | hdformat.exe astcache.com fastdisk.sys keyb.com |
"AST" |
| AT&T | ||
| COMMODORE | shipdisk.com | "ShipDisk" |
| DELL | ||
| EPSON | ||
| EVEREX | ||
| HP | ||
| KAYPRO | ||
| LEADING EDGE | color.com | "LEADING EDGE" |
| MITSUBISHI | ||
| NCR | ||
| NEC | turbo.exe | "PowerMate" |
| OLIVETTI | ||
| PHOENIX | ||
| TANDON | ||
| TANDY | mode.com basic.exe graphics.com vdisk.sys |
"Tandy" |
| TOSHIBA | ||
| UNISYS | park.exe xcom.exe |
"Unisys" |
| VENDEX | ||
| VICTOR | ||
| WANG | fdisk.com setspeeed.exe |
"WANG" |
| WYSE | setup.exe | "WYSE" |
| lock.exe | "combination" | |
| ZENITH | ||
| OTHER |
An AMSTRAD version 3.30 has been found for inspection but does not have the expected mouse.com file.
| OEM | File | Identifier |
|---|---|---|
| COMPAQ | ||
| OTHER | command.com keyb.com undelete.exe |
"Digital Research" |
As far as Microsoft is concerned for DOSSETUP.INI, there never was an MS-DOS 3.31 or PC DOS 3.31—at least, not to list as its own DOS Type—and yet an MS-DOS 3.31 (with OEM number FFh) circulates on the Internet. Conversely, COMPAQ (with OEM number 00h) plainly is known for version 3.31, apparently as having skipped 3.21 and 3.30.
Only for version 3.31 is OTHER ever selected automatically. The expected files with the expected identifier are found in DR DOS 6.0. This, famously, is not any sort of OEM variant of MS-DOS, though you might not realise it from Wikipedia’s tendency to list it with MS-DOS or PC DOS in one sentence on equal footing (as in the article on IBMDOS.COM).
| OEM | File | Identifier |
|---|---|---|
| MS-DOS | ||
| IBM PC-DOS | sys.com format.com |
"IBM DOS" |
| AMSTRAD | mouse.com | "AMSTRAD" |
| AST | ||
| COMPAQ | ||
| HP | command.com | "Hewlett" |
| OLIVETTI | ||
| TOSHIBA | ||
| WANG | sys.com | "Wang" |
| format.com | "WANG" | |
| ZENITH | format.com | "Zenith" |
| OTHER |
| OEM | File | Identifier |
|---|---|---|
| MS-DOS | ||
| AST | command.com | "AST RESEARCH" |
| COMPAQ | command.com | "COMPAQ" |
| IBM PC-DOS | command.com | "IBM DOS" |
| TOSHIBA | command.com | "TOSHIBA Personal Computer" |
| ZENITH | rtclock.sys | "Zenith Data Systems" |
| OTHER |
DOSETUP.INI knows of version 6.00 only as MS-DOS and OTHER, with no automated identification.
A DOSSETUP.INI dated 31st May 1994 from installation discs for an MS-DOS 6.22 Upgrade adds a few cases. Version 6.00 is thus known to have a later release by COMPAQ, distinguished by the six-character “COMPAQ” in its mode.com.
Also in this later DOSSETUP.INI is some account of the minor versions that followed 6.00. For these, DOSSETUP.INI records that Microsoft and IBM went their separate ways for the version numbers. Version 6.10 is known only for PC-DOS and OTHER, versions 6.20 and 6.22 for MS-DOS and OTHER, and version 6.30 for PC-DOS and OTHER.