AARD compatibility

Aitor has posted a bit of technical information about the AARD code in MS-DOS, which might be helpful in adding compatibility to FreeDOS:


I have discovered in the technical literature something that seems to be the result of some researches on the AARD code, which as you know, is the M$-DOS "purity" detection of Windows3.1, and will be perhaps one of the pieces needed so that FreeDOS can run Win3.1.

Don't be afraid for legal matters, as I have found in one book (a legal book) which is quite worried about legal things. I will try and reproduce the crucial part of the code (which is written in pseudocode), as well as a couple of notes. And I hope that this serves to kernel developers to do something about it.

I remind you that in my tests I got the 'MCB chain corrupted' error, and not the AARD-specific error ('#2726'). This says that fixing the MCB error (or adding Steffen's patch) is crucial for Win3.1 to run. But as you will see, the redirector can also be a crucial part of this, as well as the NLS part (!!).

I reproduce what the book says, in pseudocode (there is also a program in C, I can check the disk and send it to you). The program reproduces the AARD, and behaves exactly as the AARD. If you are further interested on this, I will read carefully the rest of the section. However, I found this rather clarifying: (the author says: successful for M$-DOS and PC-DOS, fails for DR-DOS):

There are other parts of the AARD which are reasonable, and DOS-independent. However, this is the crucial section of the AART to legitimate the DOS.

IF   redirector-in-use (2Fh, AX=1100h)  THEN
       IF  default-capital-letters-map (21h, AH=38h)  is in
DOS-data-segment (2Fh, AX=1203h)
             THEN  DOS is genuinely M$-DOS
             ELSE  fail
        END IF
ELSE  {no redirector}
       IF   first-FCB-system-header (SysVars[1Ah]) has offset == 0
             THEN  DOS is genuinely M$-DOS
             ELSE  fail
       END IF
END IF

As you can see, and the author says, this is believed to be it: why does Win31 matter of the capital letters map or the FCB, if it is not using them? The authors say that this section was hardly encrypted using XOR-encriptation and there where some traps to avoid being disassembled.

The book includes a full section on the AARD. The book is the translation to Spanish of 'undocumented DOS', by Schulman, R.Brown and others.

-Aitor


Arkady also re-posts this information from 1998:

From: Tony Gordon
Subject: FreeDOS and Windows, EMM386, and V86 mode
Date: Sun, 15 Nov 1998 10:14:21 -0500

Microsoft developed AARD code in MS Windows to detect whether it was running on Microsoft's MS-DOS (or approved OEM versions of MS-DOS) or on untested (therefore unverifiable) operating systems such as DR-DOS (Novell DOS or Caldera DOS, whichever you prefer).

According to Undocumented DOS, Microsoft hides this code using an XOR encryption as to not make available thru DEBUGging or other means. The basic flow (as copied from the book) is as follows:

move (and fixup) code from 2D19h to 4E0h
call code at 4E0h
        call AARD code at 3982h:
            -- see below
        IF (AX doesn't match 2000h)
            AND IF (control_byte is non-zero)        ;; added in retail version
                    THEN overwrite BYTE at 4E0h to a RET instruction
;...
IF (byte at 4E0h is a RET instruction)
    THEN issue non-fatal error message

call AARD code at 39B2h:
        point INT 1, INT 2, INT 3 at invalid code to confuse debuggers
        call undocumented INT 21h AH=52h to get SysVars ("List of Lists")
        copy first 30 bytes of SysVars to stack
        copy first 4 bytes (DPB ptr) of copy of SysVars to stack
	    IF DOS version >= 10.0 (i.e. OS/2)
            THEN don't set [bp+196h], so eventually OR AX, 2000h fails
        ELSE
            check fields in SysVars to ensure non-zero:
                SysVars[0] -- Disk Parameter Block (DPB)
                SysVars[4] -- System File Table (SFT)
                SysVars[8] -- Clock device (CLOCK$)
                SysVars[12h] -- Buffers header
                SysVars[16h] -- Current directory structure (CDS)
                SysVars[0Ch] -- CON device
                SysVars[22h] -- Device driver chain (NUL device next ptr)
        IF no SysVars fields are zero (MS-DOS, or WIN.COM in DR DOS)
            THEN set [bp+196h], so eventually OR AX, 2000h succeeds
        ELSE some are zero (e.g. HIMEM.SYS in DR DOS)
            THEN don't set [bp+196h], so eventually OR AX, 2000h fails
        copy code
        jump to copied code
        copy and XOR code
        jump to copied and XORed code
        ;; the following crucial part was figured out by Geoff Chappell:
        IF a redirector is running (INT 2Fh AX=1100h)
            AND IF default upper-case map (INT 21h AH=38h) in DOS data segment (undocumented INT 2Fh
AX=1023h)
        OR IF no redirector
            AND IF first System FCB header (SysVars [1Ah]) offset == 0
        THEN DOS is considered okay
        ELSE (e.g., WIN.COM, SMARTDRV.EXE, etc. in DR DOS)
             THEN clear part of [bp+196h] so eventually OR AX, 2000h fails
        restore previous INT 1, 2, 3
        jump back to saved return address

I also have source code from Undocumented DOS to test this, I have included it in this e-mail. I am violating copyright laws, however, since this book is no longer available, I am hoping that this code will help in further debugging and testing of FreeDOS to make it viable. There is more code to look at, as some Microsoft applications have warranties which are voided if ran on non Microsoft operating systems. One of which being (the now defunct) QuickC compiler (and Programmers WorkBench). I didn't include that code, but I can in the next message.

It's worth noting that in the draft standard for EMS, Compaq wrote EMM386. It is a DOS program attached to a VxD.

I used a program included in Undocumented DOS after reading everybody's suggestion (or those who suggested it more accurately) that showed me that DOS applications ran SLOWER in V86 mode. Why? Well, since DOS is a real mode OS, running in protected mode causes more processor instructions to be run to convert from selector based memory management as done to segmented memory management. As we all know, certain register values mean different things in protected mode and/or V86 mode, so that requires some thunking and mode switches which can be time consuming. In order to successfully implement a good protected mode aware operating system, we'd have to move the kernel into 32-bits, so then we'd have to write FreeDOS and FreeDOS32, hmmm....interesting concept. The basic point of this whole dissertation is that program speed suffers (not noticeable on Pentium class machines) when the processor must switch modes. Software that is needing to call a lot of DOS functions should do so in REAL mode, not PROTECTED or V86 mode.

-Tony

Tony had also sent an archive with .C source: MSDETECT.C, by Andrew Schulman, May 1993, From "Undocumented DOS", 2nd edition (Addison-Wesley, 1993). See also Dr. Dobb's Journal, September 1993.