From: skb AT xmission DOT com (Scott Brown)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: getdfree fails & long longs interfere with DOS interrupt call
Date: Sun, 28 Jan 2001 02:56:14 GMT
Organization: (none)
Lines: 26
Message-ID: <3a7324b0.284714105@198.60.22.3>
References: <3a71e643 DOT 26318843 AT news DOT xmission DOT com> <7458-Sat27Jan2001102214+0200-eliz AT is DOT elta DOT co DOT il>
NNTP-Posting-Host: slc351.modem.xmission.com
X-Trace: news.xmission.com 980651354 1442 166.70.2.97 (28 Jan 2001 03:09:14 GMT)
X-Complaints-To: abuse AT xmission DOT com
NNTP-Posting-Date: 28 Jan 2001 03:09:14 GMT
X-No-Archive: Yes
X-Newsreader: Forte Free Agent 1.21/32.243
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On Sat, 27 Jan 2001 10:34:39 +0200, "Eli Zaretskii"
<eliz AT is DOT elta DOT co DOT il> wrote:

>This is wrong.  Function 7303h needs the _second_ 16-bit word of the
>buffer to be zeroed out, but you only zero out the first 16-bit word
>of your buffer[] variable.  This leaves the second word at random
>value (whatever was on the stack).
>
>In addition, 7303h needs DS:DX to point to the drive string in the
>transfer buffer, and ES:DI to point to the data buffer in the transfer
>buffer, but your program didn't assign anything to DS and ES.

Thank you.  I spotted the ds/es bug this morning, but not the version
field.

>Note that on some Windows 9X systems, if the DOS box loads a TSR that
>hooks Int 21h, the reported values will never exceed 2GB.  This is a
>Windows misfeature/bug, mentioned in RBIL.

Yes.  I suppose one could write a TSR that loads first to monitor
calls through 0x21 and unhook the interrupt for the duration of the
call.  I'll have to review my knowledge of ioctl calls; perhaps
there's a more robust way to query a device's free space.

Thanks again,
-Scott