Xref: utzoo comp.sys.ibm.pc:29989 comp.binaries.ibm.pc.d:3387
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!nbires!maa
From: maa@nbires.nbi.com (Mark Armbrust)
Newsgroups: comp.sys.ibm.pc,comp.binaries.ibm.pc.d
Subject: Re: MS-DOS 3.30 Absolute Disk I/O bug
Summary: more info
Keywords: DOS 3.30 bug
Message-ID: <411@nbires.nbi.com>
Date: 9 Jun 89 22:20:02 GMT
References: <410@nbires.nbi.com>
Reply-To: maa@nbires.UUCP (Mark Armbrust)
Organization: NBI Inc, Boulder CO
Lines: 45

In article <410@nbires.nbi.com> maa@nbires.nbi.com (Mark Armbrust) writes:
>
>There is a bug in MS-DOS 3.30 that causes the INTR 25/26 Absolute Disk I/O
>functions to trash memory if they are issued for invalid drive numbers.
>I have not checked any other version of DOS to see if they also have the
>bug.
>
>What happens is that if the drive number in AL refers to an invalid drive,
>MS-DOS writes a word of 0FFFFh at ES:[BP+1Eh].

I did a bit of looking at various version of DOS that we have around here
and the bug seems to have been introduced in MS/PC-DOS 3.1; it has been fixed
in MS-DOS 4.0 (I didn't check PC-DOS 4.0).

It seems that the easiest way to deal with this problem is to set ES to 0F000h.
This makes DOS do the erroneous write into the ROM.

For example, from DF.C where I first found the problem:


        int DriveReady (int drive, char *buffer)
        {
        union REGS regs;
    +   struct SREGS sregs;

    +       segread (&sregs);
    +       sregs.es = 0xF000;
            regs.h.al = (unsigned char) drive;
            regs.x.bx = (int) buffer;
            regs.x.cx = 1;
            regs.x.dx = 0;
    -       int86 (0x25, &regs, &regs);
    +       int86x (0x25, &regs, &regs, &sregs);
            return ! (regs.x.cflag);
            }


>This is the entry print for INTR 25H
		   ^^^^^
		   POINT!  My fingers sometimes have a life of their own.  8-(
-- 

Mark Armbrust
maa@nbires.nbi.com
maa@nbires.UUCP