Geoff Chappell - Software Analyst
The first public description that I know of the AARD code, by anyone, is an exchange of messages in June 1992 on a conferencing system called Compulink Information eXchange (CIX) that was hosted in the United Kingdom and was open to public subscription. In having a membership fee for access to forums, CIX was very much like Compuserve. For being a local system in the U.K., CIX was very much smaller than Compuserve. In those days, however, Compuserve was relatively expensive and difficult to access in the U.K. and so CIX was much more important to the British computer industry than might be thought just from size. Curiously, Compuserve’s forums are long gone, yet CIX’s are still active (though, sadly, its archives look to be incomplete).
By description I mean an explanation of what the code does, specifically of what it seeks from its tests and how it reacts if its tests fail. The error message it presents would surely have been seen, and maybe even talked about in public, by possibly many DR DOS users before I ever knew of it. A Consolidated Statement of Facts for a court filing in April 1999 recites, from Exhibit 443, six such instances in a Compuserve forum for Windows 3.1 beta testers between 22nd December 1991 and 4th March 1992. Leave aside that posts to this forum were arguably not public since participation required a Non-Disclosure Agreement (NDA) with Microsoft, the talk was anyway just of observation and significance, not of what code caused the error message, let alone of how or why. I know of no explanation by anyone in public that is earlier than the exchange I reproduce on this page. This description of the AARD code’s tests was published on 8th June 1992.
For the earlier date of a description in private, again by me, see my Record of AARD Research as inferred from email with Andrew Schulman on 17th April 1992.
Other email with Andrew Schulman shows why the AARD code was again on my mind in June after a full examination in April. It seems I had only recently got a formally released Windows 3.1 to inspect. On 5th June 1992, I wrote that I would be examining WIN.COM because (among other things)
… it (like my beta HIMEM.SYS) contains a section of encrypted code and an error message recommending the user to contact beta support. Something funny is going on here! The tests involved look awefully like MS are guarding against execution in another OS's emulation box.
The last few words look to be the best confirmation I have that DR DOS was truly not on my radar as the intended target of these tests. Some sense of this is also visible in the extract from CIX below, where I wrote of a “non-DOS” and could be no more bold about the non-encrypted part of the AARD tests (numbered 1 in the extract) than to write of some “vague understanding” that it would be failed by the “OS/2 compatibility box”. Evidently I would have liked to know what was intended as the target of these tests, but the best I could do was dredge up some memory of having once read something somewhere about the OS/2 compatibility box. Even this was too much for the encrypted AARD tests (numbered 2a and 2b), about which I ventured only that both “are normally true for MS-DOS.” The email confirms—for me, anyway—that I was not just cautiously omitting to specify DR DOS in public as the AARD code’s target: I had no thought for DR DOS even in private.
What’s relevant about this for background is that some think the AARD code came to light only because Digital Research and the users of its product, DR DOS, were injured. I can’t speak for how or why others came to look at the AARD code in 1993—and as I say on the introductory page, I really do mean not to comment here on the rights and wrongs of the AARD code’s existence—but I do say here that my study in 1992 was done without the slightest interest in DR DOS or concern for its users—and, indeed, without knowing that the code had yet been a real-world problem for anyone.
This is not to say anything one way or another about the code’s consequences for DR DOS, or that later analysis by Andrew in 1993 was not substantial. What I say here is just that if you seek the first publication of a full explanation of what the AARD code tests as its detection of MS-DOS, then the date to beat is 8th June 1992 and DR DOS had absolutely nothing to do with either the research or the publication.
There follows a thread from CIX’s conference on Windows development in early June 1992. The CIX forums are nowadays accessible through web browsers for a free sign-up. Though many messages from the early 1990s are accessible this way, I have not (today, 28th August 2021) found any from the windows/development conference. I extract messages 4237, 4241, 4243, 4247 and 4248 from a small archive that I saved in July 1993. The first is the earliest I can find of my talking in public about the AARD code (not that anyone had yet named it this). Each of the others is the one reply to the message that precedes it in the thread. The third, i.e., my second in the thread, has the full detail of what the AARD code tests.
The only editing in the extract that follows is that the AARD details are emphasised in bold for easy location by readers who aren’t interested in the context. I present the exchange with no further comment, except to direct attention again to the date: the AARD code’s workings were fully explained in public on 8th June 1992.
>>>windows/development 4237 geoffc(1212)7jun92 15:32 c4202* > but to stop the competition from getting their >hands on the programs & disassembling the code. Are you saying that you have a copy protection scheme that prevents a PC from actually reading the distribution disks? There is a persistent belief that disassembly means running the code under a debugger to see what it does. The relevance of this to a Windows conference is the discovery that my copy of WIN.COM (and presumably every one else's) contains some 2KB of code and space designed to trap attempts to run Windows under a non-DOS. The code is real gobbledy-gook with lots of redundant instructions to make it seem confusing and a crucial part is encrypted. Most significantly, it installs handlers for the debugger interrupts (and NMI just in case you're using a sophisticated debugger) that are guaranteed to cause the unexpected should anyone attempt to step through the code. As far as I know, this is Microsoft's first stoop to the practice. Does it indicate defensiveness on their part or mere curiosity? My WIN.CNF (that SETUP copies to the SYSTEM subdirectory) is 16,112 bytes long - stamped 10/03/92 at 3:10. Would anyone with a different file please let me know. -- Geoff --
>>>windows/development 4241 djewell(223)8jun92 11:36 c4237* Geoff :- this sounds very interesting ! When you say > designed to trap attempts to run Windows under a non-DOS do you mean: > designed to trap attempts to run Windows under a non-MS DOS Dave (intruiged.....)
>>>windows/development 4243 geoffc(3013)8jun92 17:04 c4241*
I don't know what I mean, but I reckon that every now and then I turn up
something of reasonable interest. The story goes like this:
The copy of WIN.COM that I have inspected is very interesting on a number
of counts. Towards the end of the WIN.CNF component is some disguised
code that checks to see that a standard MS-DOS is running
1. In the internal variable table (address obtained by int 21h
function 52h), far pointers to the Handle-based SFTs, the standard
input device, the standard clock device, the BUFFERS descriptor,
the CDSs and the first device driver after NUL must all be non-zero.
This would be the case for MS-DOS, but it is my vague understanding
that it has not always been true for the OS/2 compatibility box.
2a. If a redirector is running (int 2Fh with AX = 1100h returns al = FFh),
then the upper case mapping routine (sought, curiously enough, only
for country = US) must lie in the DOS kernel data segment (value
returned in ds by int 2Fh with AX = 1203h)
OR
2b. Without a redirector, the offset address of the FCB-based SFTs must
be zero.
Again, both these are normally true for MS-DOS.
The checks in 2a and 2b are encrypted (just a bitwise XOR) - the relevant
section is bounded by "AARD" on both sides (and we all know which MS
employee this suggests).
For the whole test, interrupt vectors 01h, 02h, 03h are directed to a
stub containing either int 21h or int 2Fh (depending on when) followed by
an IRET, so single-stepping through this code or setting a break point or
whatever will have curious effects (calling DOS functions when registers
can't be known).
The code is littered with red herrings - long and convoluted operations
whose results are discarded - the whole style seems deliberately perverse.
In the WIN.COM copy I've inspected, the code is executed but not acted
upon (the message "non-fatal error #2761, contact Windows 3.1 beta support"
or similar, with a press ENTER to exit, "c" to continue) unless a
particular variable is non-zero. Static allocation has this variable as
zero and it is not referenced anywhere else in the file.
Two things. First, this copy of Windows is on a machine to which I have
access but I do not know its provenance. It is hard to see where they
could have got a beta version from, though. If the thing were for beta
release only, it would have been stripped from the file rather than let
it depend on a variable at run-time, surely? My guess (perhaps a little
suspicious) is that Windows Setup patches the file in some circumstances.
Second, I don't believe the whole thing to be a red herring, because I
have seen a beta copy of HIMEM.SYS in which the code was active (and to
prove it, I have a device driver that sets a temporary FCB-SFT with
non-zero offset address to trigger the effect).
The whole thing is very odd!
May I refer you to the digest topic for a word or two on what must be the
worst example of MS programming I have ever seen?
-- Geoff --
>>>windows/development 4247 thines(218)9jun92 15:09 c4243* What you describe is in the current release copy of Win 3.1 that I've got here, including the "Please contact Windows 3.1 beta support" message! (The error number in my copy is #2726) Verrry interesting :-) | Tim |
>>>windows/development 4248 geoffc(305)9jun92 15:36 c4247 Thank you for the confirmation. I would really like to know how to proceed with this morsel, for I too find it interesting and am sure that one or two industry watchers would also. Most of the DOS bugs I know are going into my book but it's a little difficult to stretch this to Windows. -- Geoff --