Geoff Chappell - Software Analyst
WORK IN PROGRESS - PREVIEW ONLY
When did the programmers of DR DOS understand what the AARD code tests as its MS-DOS detection, and when did they accommodate it in DR DOS? Late 1993 from most sources but early 1992 if you believe Wikipedia. I survey the public record and argue that Wikipedia is incorrect. But how was there ever any doubt? How is there still?
Very nearly thirty years have passed since December 1991 when the AARD code started greeting Windows 3.1 beta testers with a “Non-fatal error” and the advice to “contact Windows 3.1 beta support”, just for trying to run this pre-release Windows on DR DOS from Digital Research instead of MS-DOS from Microsoft or some licensed adaptation by an Original Equipment Manufacturer (OEM).
After an article in a programming magazine and much of a chapter in a successful book, the AARD code (thus named in the article) eventually got a prominent role in one court case and walk-on parts in more. It still generates occasional discussion on the Internet, for what that’s ever worth, including recently an entertaining video, Windows’ Hidden Self Destruct Code, which was the immediate prompt of this revisit that you’re now reading.
You might think the AARD code has been picked over pretty thoroughly by now, but it hasn’t been and it likely never will be. It was always too divisive for that. Even opinion that aimed at being well-informed and carefully considered rarely questioned one or another preconception.
Microsoft argued from the start that having Windows check that it’s being run on MS-DOS is nothing but self-evidently reasonable support of its Windows customers because this particular MS-DOS program named Windows has special knowledge of MS-DOS and might not run properly on an inadequate imitation of MS-DOS. Which indeed it might not! But this reasonableness for quality control (or even for safety) then depends on plainly anti-competitive support for a specially favoured product in a pre-existing market of Graphical User Interface (GUI) programs for MS-DOS. That Microsoft can create a low-level system as a platform for a competitive market of higher-level software and later exempt Microsoft’s own higher-level software from competition by redefining it as part of the system was thoroughly dissolved into the corporate Kool-Aid even by the early 1990s.
As deeply absorbed into the other side’s drinking was that DR DOS was a better DOS than MS-DOS for running MS-DOS programs. In this view, DR DOS and MS-DOS did not compete as PC-compatible operating systems each with its own ecology of programs written to run on it. DR DOS instead competed with MS-DOS as if the two were variants of some generic DOS, not exactly as if DR DOS merely added to PC DOS and other OEM adaptations of MS-DOS, but enough alike that MS-DOS programs were written de facto to some sort of DOS standard. Whether programmers knew they were writing for a standard rather than for MS-DOS specifically is irrelevant. That Microsoft never signed up for any such standard is also irrelevant. That Windows in particular, for being a DOS program sold separately from MS-DOS, must run on DR DOS too is self-evidently a reasonable expectation of DOS users who choose DR DOS over MS-DOS, even to the extent that problems with running Windows on DR DOS suggest dirty tricks by Microsoft to protect MS-DOS from fair competition.
There’s no reconciling these camps and I don’t mean to try. Neither do I mean to summarise three decades of debate, let alone to imagine that my attempt could be free of my own ignorance and prejudice. No, my purpose for the preceding paragraphs is to sketch just enough of the AARD code’s background to remind you that very little of this topic counts as any sort of ground. The whole topic is a swamp. Within this mire, this page’s particular bit of the topic ought to be firm ground for being straightforwardly a matter of fact, but it’s just more of the bog: when did the programmers of DR DOS understand what the AARD code tests as its MS-DOS detection, and when did they accommodate it in DR DOS?
Somehow—which won’t be straightforwardly a matter of fact—this seemingly simple line of questions has no well-verified answer even in 2021, three decades after the AARD code had its first effect.
Broadly speaking, the public record breaks two ways.
Several sources that are not entirely independent of one another but which include court filings by an even later owner of DR DOS support an indirect inference that programmers at Digital Research and Novell (which had recently bought Digital Research) had not yet understood the AARD code before Andrew Schulman in 1993, notably for his article Examining the Windows AARD Detection Code in the programming magazine Dr. Dobb’s Journal. These sources are mostly from the 1990s. Some have among their recurring themes that studying the code was delayed because of one or another difficulty.
A second dating is given by Wikipedia in its articles on the AARD code and on DR-DOS (today, 14th August 2021). According to both, a “business update” of DR DOS passed the AARD code’s tests in 1992. Editing this chronology into these articles is relatively recent: 2009 in one and 2005 in the other but with the strongest assertion in 2010. As for difficulty, the record here is almost the opposite of the other: working around the AARD code was quick and simple.
These two sets of sources can’t both be correct with their dating: the second half of 1993, else the first of 1992. The later date looks to be a rough upper bound on when the programmers of DR DOS understood the AARD code: if they hadn’t yet by their own efforts, they soon would from reading Andrew’s article. The earlier date supplants the later (and my own Record of AARD Research on 17th April 1992) if there exists even one verifiable record.
The obvious primary source that could be on the public record is that a programmer of DR DOS at Digital Research or Novell went through some such steps as: recognised what is tested by the AARD code and why the contemporaneous DR DOS fails; deduced changes so that an updated DR DOS passes; and wrote it up either for publication then or somewhere that has become public since. But nothing even nearly so definitive seems ever to have turned up. In its absence, all that’s left is indirect inference from secondary sources, both positive and negative.
For positive inference, look to DR DOS itself. Though the binary files are the one and only primary source about what these files do when executed as software, they are only a secondary source for what the programmer understood (let alone for what the programmer thought was understood, which is different again from what the programmer intended, but these are distinctions for another time). If a programmer of DR DOS understood the AARD tests and built this understanding into DR DOS so that it passes the AARD tests, then even if the programmer left no record of this work for history to accept as a primary source for what the programmer knew when, the DR DOS binary’s passing of the tests stands as a secondary source.
Caution is required, though, on several counts.
Strictly speaking, existence of a DR DOS that passes the AARD tests does not prove that any programmer understood the tests and then used this understanding to get DR DOS to pass them. A change that suffices might instead have been found by a well-educated guess, or a series of them in trial-and-error, or even by fluke. But it would be extraordinary. Andrew in his article and since would have it that the two of the tests that are encrypted are “highly artificial” and even “100 percent artificial”. I, for the record, have long thought of them as “nicely targeted”. (This phrase is from email to Andrew on 20th July 1993.) Either way, the point to the AARD code is that these tests were designed to be highly non-obvious—and highly non-obvious to the programmers of DR DOS, if not to all analysts at the time, is credibly what they were. Find a DR DOS that passes the AARD tests, and you have a strong inference that the tests were understood.
Even with this allowance, it can be that the programmers understood the code and knew what to do but then took their time to build this understanding into the binary. A DR DOS that passes the AARD tests gives only an upper bound on the interval during which the programmers were yet to understand the code, but a DR DOS that does not pass the AARD tests does not give a lower bound. These ordinary points of logic matter especially for the AARD code because the “Non-fatal error” shows only in the beta releases of Windows 3.1. Once the code was known to present no problem for users of the formally released Windows 3.1, building an understanding of the code into an update of DR DOS 6.0 or into a pre-release Novell DOS 7.0 just so its users could run a Windows 3.1 beta might not have seemed like urgent work.
Inferring from binaries anyway has the practical problem that they must first be found for inspection. How easy it would have been to find intermediate releases, let alone internal builds, of DR DOS 6.0 and Novell DOS 7.0 even in their heyday, I don’t know. I never looked at any version back then, nor indeed until 2021 for writing this page. What I see now as surviving on the Internet as abandon-ware is not nearly as extensive as for the contemporaneous versions of MS-DOS. What I have (yet) found for this page’s examination of the public record are what appear to be for the years in question all the formally released editions and updates that contain the two system files IBMBIO.COM and IBMDOS.COM:
| Version | Date on System Files | AARD Tests |
|---|---|---|
| 6.0 | 6th December 1991 | fail |
| 6.0 | 7th April 1992 | fail |
| 6.0 | 19th March 1993 | fail |
| 7.0 | 26th January 1994 | pass |
Of these builds, the DR DOS 6.0 from April 1992 looks to be the same “business update” that is cited in the Wikipedia articles. Certainly it contains a README file that has been updated since the earlier DR DOS 6.0 to declare that “DR DOS 6.0 is fully compatible with Microsoft Windows 3.1.” Yet it cannot pass the AARD tests. The Novell DOS 7.0 is the earliest version 7.0 at the particular abandon-ware site I visited, but for being dated 1994 it is perhaps not the first formal release. It plainly has been reworked to pass the AARD tests.
Details of what changes between DR DOS 6.0 and Novell DOS 7.0 for passing the AARD tests are taken up below (after this survey, under the heading AARD Circumvention). What matters now, while attending to what’s available as the public record, is that finding anything useful from DR DOS binaries will require more DR DOS binaries. Other update releases of DR DOS 6.0 are available, but none that I have yet found contain the kernel (which surely would need to change if DR DOS is to pass the AARD tests). Pre-release builds of Novell DOS 7.0 will be out there too. A pass by some build of either version can bring forward the date by which the tests were understood, but passes by any number of pre-release builds of version 7.0 can tell nothing of whether any DR DOS 6.0 was ever updated to pass the tests.
Some inference about the DR DOS binaries from the years in question may be available even if the binaries themselves are not. It turns out that there is source code on the public record.
What’s available as source code is the Caldera OpenDOS Machine Readable Source Kit (M.R.S) 7.01. This is the name in the README.TXT from the top directory of the linked zip file. The original site for the download looks to be long gone, but the Wayback Machine has archived from it a press release Caldera Announces Open Source Code Mode For DOS, dated 10th September 1996. It reads like a statement of intention that was not acted on immediately. Source files in the package look to have been finalised on 17th April 1997, with the README.TXT completed on 18th April and the zip file put together on 1st May.
The relevance of a source-code package from 1997 is that Caldera had on 23rd July 1996 bought from Novell the operating system products that had been known as DR DOS and Novell DOS, and this OpenDOS 7.01 looks to be a development of Novell DOS 7.0. Importantly, its system files have the same code that allows Novell DOS 7.0 to pass the AARD tests. The hope then is that although these source files are dated 1997, they retain comments that help date the change to 1992 or 1993.
Don’t get too excited, though. It’s not as if the code for accommodating the AARD tests is commented to say so, whether by mentioning the AARD signature or by explaining that the change had anything to do with an error from pre-release Windows 3.1. Indeed, none of the relevant code is commented at all. This likely won’t be news to any programmer (or to anyone who has ever managed one), but I can’t help wondering what comments might have been left and whether any negative inference can reasonably be drawn from their absence.
What each source file does have as possibly helpful commenting is an apparently systematic log of changes. This is near the start of each file and typically goes back to 1993 and sometimes even to 1987. The pickings are thin—each entry in these logs is just a date and a few words which might then be matched more or less credibly to code that worked around the AARD tests—but they are the closest that the public record has to a primary source for what the programmers thought they understood and did.
Not quite from the programmers’ mouths but plausibly with similar authority is a history of builds, both formally released and not, from 1986 to 1999, which was assembled as 25 Years of DR DOS History by Matthias Paul no later than 18th September 2000. (The 25 years of the title reach back to DR DOS ancestors such as CP/M.) The text itself does not explain why this history exists or where its information comes from, but whatever this history’s origin or pupose it’s easily the most substantial and credible that I’ve yet found on the Internet. Importantly for this history’s contribution to the public record of what the programmers of DR DOS or Novell DOS knew of the AARD code, it’s not just a list of versions and dates but has multi-line footnotes, two of which mention the AARD code specifically.
This history is cited by the Wikipedia articles (see below) from as long ago as 2nd July 2008, initially to date the AARD workarounds to 1994 but looks also to be the source of the later dating of these workarounds to 1992. Three of the history’s footnotes are nowadays extracted into the Wikipedia articles’ footnotes. I reproduce each in full for later reference:
About DR DOS 6.0 "Windows 3.1 update, April 1992" (03/1992, 1992-04-07):
[19] This public DR DOS 6.0 update only includes patches addressing
full Windows 3.1 compatiblity. There should have been a full
"business update" for registered users, shipping a little bit later.
About Novell DOS 7 "Panther/Smirnoff" BETA 3 (09/1993):
[27] Novell DOS 7 "Panther/Smirnoff" BETA 3: This issue does not have
workarounds for Windows 3.1 "AARD" code.
About Novell DOS 7 German release (1994-02-22):
[29] Novell DOS 7 German release: This issue is known to have workarounds for
Windows 3.1 "AARD" code. This should also apply to the earlier English
issue.
The same author, Matthias Paul, had written extensively about Novell DOS 7 and OpenDOS 7.01 in German. From a zipped collection of text files that’s still available at an archive site, one with a section specifically on the AARD code is available in an HTML conversion as NWDOSTIP, apparently with Matthias’s blessing. Either way, it dates its creation to May 1994 and its last update to 13th May 1997. Its citation by Wikipedia, for only the DR-DOS article and not in connection with the AARD code, was added by Matthias on 3rd April 2015. Still, the cited document does deal with the AARD code. Under a heading for presenting the AARD code as an embarrassing story (“peinliche 'Historie'”) are several paragraphs, the last of which begins:
Wenige Tage nach dem Erscheinen von MS Windows 3.1 hatte Digital Research
allerdings ein 'Business' Update für DR DOS 6.0 herausgegeben, daß neben
verschiedenen anderen Anpassungen und Bugfixes auch diese Überprüfung
umging.
From a dictionary and distant memories of schoolboy German, I interpret this as:
A few days after the arrival of MS Windows 3.1 Digital Research had however published a ‘Business’ Update for DR DOS 6.0, which along with various other adjustments and bug-fixes had also gone round this check.
In its context near the end of a section on the AARD code, this check (“diese Überprüfung”) looks like it can only be the AARD code. If so, then this sentence is the earliest public record that I know as suggesting that the “business update” of DR DOS 6.0 in April 1992 had got round the AARD code.
Some DR DOS history, if only of builds that had a public release, is attested by notices in the press. Some are enlightening for recording something of what the manufacturer wanted to be known, if only at the time. Specially remarkable while focused on the “business update” that was built on 7th April 1992 is DR DOS 6.0 Does Windows 3.1 from the News pages of ComputerWorld, Vol. 26, No. 16, dated 20th April 1992, for its hint of how Digital Research was able to resolve compatibility problems with a Windows that it had only limited access to:
Despite being banned from Microsoft Corp.’s Windows 3.1 beta-test program, Digital Research, Inc. last week announced a Windows 3.1-compatible “business update” of DR DOS 6.0. The updates offer fine-tuning of existing features. DRI spokesmen said the firm got around the ban by working with DR DOS users who were Windows 3.1 beta-test users. Anxious users can download the update off the DR Forum on CompuServe.
That the AARD code has this name is from Andrew’s article which brought to wide attention the programmatic cause of the “Non-fatal error” and stoked speculation about Microsoft’s intentions. The article is essential background for both the technical detail and subsequent controversy. So too, or perhaps alternatively, is Chapter One of Undocumented DOS, Second Edition. Andrew co-authored this book, which was published by Addison-Wesley (ISBN 0-201-63287-X) with a copyright date of 1994 but a first printing in November 1993. The article notes at its start that portions are excerpted from the book.
For the public record of when the programmers of DR DOS understood the AARD tests, however, the article and book have only indirect bearing. As noted above, their availability roughly ends the interval in which the programmers did not yet understand the tests (though it tells nothing of how long the programmers took to build this understanding into their code). The cover date is September 1993, but the article was circulating well ahead of this. For instance, InfoWorld Volume 15 Issue 28, dated 12th July 1993, not only cites it but quotes from it briefly for the column Notes From The FIeld by Robert X. Cringely. I’m surely not giving away anything private if I report that email from Andrew on 25th July confirms that Microsoft had by then seen the article in print. Email the next day has Andrew also with a print copy. I did not get mine until 30th August—but that was from a newsagent in faraway London. In whatever passes for newsagents in America, print copies must have been available through much of August, if not in late July. Circulation of Dr. Dobb’s Journal among professional programmers was high enough that it’s all but unthinkable that the programmers of DR DOS had not read the article by the end of August 1993.
The only other help from the article or book, for dating, is a negative inference. Both present a program that roughly simulates the AARD tests and both say the tests are failed by a range of DR DOS versions, including “beta Novell DOS 7” in the article and “a beta of an upcoming version, now named Novell DOS 7.0” in the book. Though the book was published later, the experiments plausibly were not redone. The most that seems safe to infer is that if the programmers of Novell DOS understood anything of the AARD code in early 1993, let alone 1992, it was not yet showing in whatever builds Andrew had of DR DOS 6.0 and Novell DOS 7.0 when writing his article in mid-1993.
Indirectly, Andrew’s article helps with dating because its existence raises the question of why it was that Andrew, or anyone, got concerned in mid-1993 about “Non-fatal error” messages in pre-release software from more than a year before.
What’s on the public record about this is a newspaper report from 10th May 1993. From FTC MOVES TO FOCUS MICROSOFT ANTITRUST CASE by Wendy Goldman Rohm for the Chicago Tribune, it looks reasonable to infer a triangle of communication earlier in May between Andrew, the Federal Trade Commission (FTC) and Novell. This report is arguably remarkable just for its survival: it is a rare bit of the public record that is credibly still on the Internet in something like its original form at its original host. More interesting for the history is that it’s the first report that I know to have been published of the AARD code having affected DR DOS.
The FTC’s investigation of Microsoft in the late 1980s and early 1990s is a story all by itself, but what’s relevant to the AARD code is that Digital Research and Novell had been in touch with the FTC for years—see, for instance, Microsoft’s Tactics Questioned by Rivals in the New York Times from 15th March 1991—so how can it be that Digital Research and Novell suffered the effects of the AARD code as long ago as December 1991 and no public record exists of their having raised it with the FTC until mid-1993? There is either more to find for the public record or some sort of inference to draw from absence.
Also on the public record as informing Andrew, and possibly Novell through him, is me. My telling Andrew on 17th April 1992 about the AARD code in HIMEM.SYS version 3.03 didn’t get Andrew’s attention at the time and can’t have been known at all to the programmers at Digital Research or Novell, but it’s relevant to dating their knowledge because revision for WIN.COM from the formally released Windows 3.1 led to the First Public AARD Details on 8th June 1992 and the programmers at Digital Research can have seen this. The publication was on a conferencing system named CIX that was similar to Compuserve but local to Britain. The programming of DR DOS 6.0 is known to have been done mostly at Hungerford in Britain. How much of this work moved away after Digital Research was bought by Novell, I don’t know, but I recall that at least one CIX subscriber had been a programmer of DR DOS at Digital Research. Even if someone at Digital Research had seen this description in public, they might not have connected it with DR DOS: though my description of what the AARD code tests as its MS-DOS detection was complete, I wrote only that it will have affected some “non-DOS”, not DR DOS specifically.
The weightiest of negative inferences about what the programmers of DR DOS knew of the AARD code comes from a later owner of DR DOS. The operating systems that Novell had acquired from its purchase of Digital Research were sold to Caldera on 23rd July 1996. On this same day, Caldera sued Microsoft “for damages and injunctive relief under the antitrust laws of the United States”. The suit worked its way slowly towards a trial, passing first through numerous motions for summary judgment, and then it never did get to trial.
For some time, the complaint and an amendment, motions by the defendant, responses by the plaintiff and a few opinions by the judge were published openly at websites.
WRITING IN PROGRESS
While this chronology of what Digital Research knew of the AARD code has no primary source, Wikipedia can at best be an interpreted collection of citations of secondary sources. Yet despite Wikipedia’s potential for degenerating into a muddle of opinions and hearsay, especially on topics that are controversial and obscure, the AARD code and DR-DOS articles cannot simply be dismissed. Even when reduced to a tertiary source, Wikipedia is widely reproduced, with and without attribution, and is even more widely read and believed. Fortunately, Wikipedia does seem to mean it when saying that although its contents may not be reliable they are at least verifiable, even if verification is avoided for a decade, and so Wikipedia keeps a public history.
Of the two articles in question, the one titled AARD code has the simpler assertion and the simpler history. That the AARD code was accommodated into DR DOS as early as 1992 first appears on 20th October 2009, when the article changed from
Novell released a patch to enable the AARD tests to pass on DR-DOS and Novell DOS in 1994.[citation]
to
Digital Research released a patch to enable the AARD tests to pass on DR DOS in 1992.[citation]
The change of date looks to have come from reinterpreting the one cited source. The citation is the 25 Years of DR DOS History and the change is specifically to prefer this source’s footnote #19 to #29. The latter refers to a release in 1994 which is said explicitly to have workarounds for the AARD code. The former is for an update from April 1992 which “only includes patches addressing full Windows 3.1 compatibility.” Perhaps the article’s editor in 2009 followed the citation to the source and interpreted it as meaning the 1992 update for Windows 3.1 must also have worked around the AARD code. If it is a misinterpretation, then it’s plausibly an honest one and at least it left a trail for verification.
This support from the public record was edited on 26th September 2013 and again on 6th October 2013 by Matthias Paul, the author of the cited DR DOS History. The first edit added a reference to Caldera’s Consolidated Statement of Facts.. It directs the reader to nowhere specific in the large document, but the only part that looks relevant is at paragraph 222. This starts with the attested history that “Novell quickly shipped an update to allow DR DOS 6.0 to run under Windows 3.1” but it continues with “When coupled with the AARD code” as if to distinguish the update from the AARD code, which then is taken up as its own new section.
Matthias’s second edit is of the pre-existing footnote. Instead of referring to his history’s footnote by number, it now quotes. Recall that #19, for the update from April 1992, does not speak explicitly of the AARD code in any version, but that #27 and #29 plainly have it that workarounds for the AARD code were introduced to Novell DOS 7.0 after September 1993 but before February 1994.
Whatever was intended by this fresh attention to the citations, one effect is to suggest that the dating in the text is not unambiguously supported by the public record. Yet the dating to 1992 was left to stand in the text, perhaps with what sports fans refer to as an asterisk. Matthias edited it again on 22nd July 2019 to name the April 1992 patch specifically as a “business update”.
My own view of the 1992 dating in the AARD code article is that it came about from possibly eager misreadings of the cited sources, and nobody has been bothered to verify either the cited secondary sources or Wikipedia’s tertiary interpretations by checking the binary.
Right from the DR-DOS article’s creation on 30th July 2002, it grumbled about Microsoft “inserting code into Windows 3.0 to abort if DR-DOS was detected.” Whatever the author had in mind as this “code”, an editor changed it on 9th September 2002 to “inserting code into Windows 3.0 to throw up a confusing non-fatal error message if it detected a non-Microsoft DOS.” Despite having the wrong Windows version, notes for this editing make clear that what the editor had in mind was the AARD code. That the inserted code was in “the beta version of Windows 3.1” had to wait until 5th September 2005.
Meanwhile, an edit on 1st January 2003 introduced a separate series of issues for Windows 3.1:
In the fall of 1991 Microsoft announced Windows 3.1, complete with modifications to ensure that it would not run on the then-new DR-DOS 6.0. (They had also refused to allow DR access to the beta of 3.1.) It was a simple matter for Digital Research to patch DR-DOS to circumvent the modifications and the patched version was on the streets within six weeks of the release of Windows 3.1.
No editors were yet bothering to support the text with references to the public record, but “the patched version” is surely the April 1992 update whose purpose, as attested independently of Wikipedia, was to deal with Windows 3.1 incompatibilities. A second edit on 5th September 2005 brought the two strands together, possibly aiming for nothing more than economy in the writing, and thus introduced to Wikipedia the assertion that the April 1992 update worked around the AARD code:
It was a simple matter for Digital Research to patch DR-DOS to circumvent the ‘authenticity check’ in Windows 3.1 beta, and the patched version was on the streets within six weeks of the release of Windows 3.1.
As with the AARD code article, this association of the April 1992 update with the AARD code may have been made by editors who misinterpreted other sources and did not (or could not) check what the binary actually does. Willingness to excuse this—remember, it was done without citations—surely goes away with an edit on 5th June 2010 which not only spells out that the “authenticity check” is the AARD code but sketches how the patch works:
It was a simple matter for Digital Research to patch DR DOS 6.0 to circumvent the AARD ‘authenticity check’ in Windows 3.1 beta by rearranging the order to two internal tables in memory (with no changes to functionality), and the patched version was on the streets within six weeks of the release of Windows 3.1.
Intriguingly, the contributor of this edit is known to Wikipedia only by an IP address and never worked on the article before or after this day and the next in 2010 (at least, not with the same IP address). Whoever this anonymous contributor may have been, they introduced to Wikipedia this very specific information that the AARD code was worked around simply by rearranging two tables, but where this information came from in the public record is nothing that any Wikipedia editor has ever added as a citation.
Indeed, the DR-DOS article’s coverage of the AARD code didn’t have any citation at all until 12th February 2019, when Matthias Paul added three. On 22nd July 2019, he added a fourth and elaborated that the patched version was named “business update”. After a relocation and some corrections of grammar on 18th January 2020, what the article has now (14th August 2021) for what Digital Research did about the AARD code is:
It was a simple matter for Digital Research to patch DR DOS 6.0 to circumvent the AARD code ‘authenticity check’ in the Windows 3.1 beta by rearranging the order of two internal tables in memory (with no changes to functionality), and the patched version, named “business update”, was on the streets within six weeks of the release of Windows 3.1.[four citations]
To be clear: even still (today, 14th August 2021), no text in any of the four cited references goes anywhere near to explaining what changed in the code, let alone to say it was specifically just a reordering of tables. Indeed, none says explicitly that the circumvention was done for the 1992 business update.
To understand what changed in DR DOS so that later versions pass the AARD tests, we’ll need some review of what those tests are and of how they’re failed by DR DOS 6.0 from the time of the Windows 3.1 beta. It is not my purpose in this review to evaluate the tests or to comment on the rights or wrongs of intentions or effects. For better or worse, the AARD tests were developed and were deployed. For reasons good or bad, something particular to the DR DOS 6.0 implementation meant that DR DOS 6.0 failed the tests. All that matters here is to know what had to change.
The AARD tests that matter are the one or two that are encrypted. These are well-known from Andrew’s article. Here I rephrase and I reorder to put the typical case first. Given the condition on the left in the table below, the test on the right must be true to pass as MS-DOS and avoid the “Non-fatal error”:
| Condition | Test |
|---|---|
| no network redirector running or code is in HIMEM.SYS |
the offset part of the DOS kernel’s 16:16 address for the System File Table (SFT) for the old File Control Block (FCB) interface must be zero |
| a network redirector is running | the segment part of the DOS kernel’s 16:16 address for the case-mapping routine in country information for the United States (or, if this is somehow not available, for the default case-mapping routine) must be the DOS kernel’s data segment |
Two brief reminders of the MS-DOS implementation, and thus of how MS-DOS passes the tests, seem unavoidable.
First, MS-DOS can have a chain of file tables for file I/O done through file handles and it can have one table for file I/O done through FCBs. The kernel starts with a minimal table for file handles and none for FCBs. System initialisation may add a table for file handles and always creates one for FCBs. The counts of entries in each set of tables are configured separately through files and fcbs in CONFIG.SYS, but can be changed later by software, including by network redirectors and similar programs. The table that is created for FCBs during system configuration is paragraph-aligned and the address that the kernel is given for it is canonical (by which I mean that its segment part is chosen so that the offset part is less than 0x0010).
Second, MS-DOS in version 5.00 and higher divides its kernel into separately addressed segments. One, which is small and contains mostly data, is kept in low memory. The other, which is much bigger and contains code and mostly read-only data, can be moved to the High Memory Area (HMA), where it is less in the way of programs and of users’ attention. For reasons that don’t matter for this quick review, MS-DOS has a rule that when the kernel is in the HMA, addresses in the code segment cannot be exposed outside the kernel. Entry points to the code segment are hidden behind stubs in the data segment. From outside the kernel, the entry point is the stub. In some few cases, the code that must be hidden behind a stub is small enough that space for a stub is as well avoided by placing the whole code in the data segment. The case-mapping routine is one such, well, case.
DR DOS 6.0, if not other versions, supports the two flle I/O interfaces through just the one chain of tables. All that matters of files and fcbs from CONFIG.SYS is their sum. For a table that would otherwise be for FCBs, DR DOS 6.0 has a single-entry dummy that is hard-coded in the kernel’s data and looks to be completely unused. In the builds listed above from 1991 and 1992, this dummy is roughly half way into the data, not far beyond what’s widely known as the Swappable Data Area. Its particular offset, 0x0A82, likely had no planning. Indeed, it moves to offset 0x0A9C for the build from March 1993. Even if it happened to be paragraph-aligned in some build, there’s no code to canonicalise the 16:16 address that the kernel keeps for it. In no case, then, can the offset part be zero, and so the applicable AARD test fails.
The kernel for DR DOS 6.0 has separate addressing of its code and data segments so that the code can be moved to the HMA, but no builds yet found for inspection, even the update from March 1993, have low-memory stubs in the data segment to serve as entry points to code in the HMA. The case-mapping routine is in the code segment, not the data segment, and so the applicable AARD test fails.
Put aside that what changed for the “business update” from April 1992 does not pass the AARD tests, no matter what Wikipedia says to the contrary. See instead that “rearranging the order of two internal tables”, if taken literally, cannot possibly suffice. If the objective is just to pass the tests, then what looks to be required at a minimum is three changes:
All three are attended to for Novell DOS 7.0 but are not in any of the builds presented above as having yet been found of DR DOS 6.0.
To go without an SFT for FCBs would defeat whatever reason ever existed for DR DOS to keep a dummy. In practice, then, the necessary change is to ensure that the dummy is paragraph-aligned. Novell DOS 7.0 moves it to offset 0x11F0, very nearly at the end of the kernel’s data, with 16-byte alignment looking very deliberate.
Novell DOS 7.0 moves the case-mapping routine to the data segment and slightly recodes it. Where the routine looks up a table in the data segment, it used to call a subroutine to get the data segment’s address. Now that the routine is itself in the data segment, it executes with the data segment’s address already in cs and therefore does not need the subroutine.
With or without these relocations, the SFT and the case-mapping routine are addressed through far pointers whose segment parts are not known when the kernel is built. They are instead set by code. Though the relocation of the SFT is just within the kernel’s data segment, the kernel’s one pointer to it needs not just to have its segment part set but to have the whole pointer be canonicalised. This pointer is in the structure whose address is returned by int 21h function 52h. This structure is prepared during system initialisation by code in IBMBIO.COM, which in Novell DOS 7.0 has new code to do the canonicalisation. Moving the case-mapping routine to a different segment requires several small changes but all in the kernel. For instance, where a subroutine sets into a structure a far pointer to the case-mapping routine, the code changes ever so slightly to get the segment part of the pointer from ss instead of cs.
A generous interpretation is that Wikipedia merely recounts a programmer’s recollection of what was done to pass the AARD tests. Two things moved in the kernel. One is a table. It’s easy to imagine the story getting a little corrupted over time, whether in the programmer’s memory or by the story’s recirculation as corporate folklore. Thus, perhaps, did the change become a rearrangement of two tables, with the need for new code or changed code here and there neglected as merely incidental. Less generous is that Wikipedia has been ill-served by the anonymous contributor who inserted the hearsay and then by any number of editors who let it stand without attribution for a decade.
WRITING IN PROGRESS