Date:	Thu, 20 Mar 1997 18:10:42 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Dan Hirschberg <dan AT verity DOT ICS DOT UCI DOT EDU>
cc:	djgpp AT delorie DOT com, dan AT verity DOT ICS DOT UCI DOT EDU
Subject:	Re: novice errors? dpmi, info, groff, df
In-Reply-To:	<9703191609.aa00925@paris.ics.uci.edu>
Message-ID:	<Pine.SUN.3.91.970320181013.24420J-100000@is>
MIME-Version:	1.0

On Wed, 19 Mar 1997, Dan Hirschberg wrote:

> I put in a printf statement in statfs.c and it reported
> (when checking c:) that regs.x.cx = 512 and regs.x.ax = 64
> 
>  > Btw, what does "CHKDSK C:" report on that DOS box?  It should print the
>  > values of BSIZE, FILES and BFREE as above (it does for me on MSDOS machine
>  > with a 1GB disk).  And df works for me on Windows 3.11 for a 1.9GB
>  > NFS-mounted disk. 
> 
> chkdsk c:    results in
> 
> Type of file system is NTFS
> Warning!  F parameter not specified
> 
> 2096450 kilobytes total disk space
>  692377 kilobytes in 14321 user files
>    4330 kilobytes in 1516 indexes
>   26410 kilobytes in use by the system
>    4096 kilobytes occupied by the logfile
> 1373332 kilobytes available on disk
> 
>   512 bytes in each allocation unit
> 4192901 total allocation units on disk
> 2746665 allocation units available on disk
>
> I note that regs.x.ax etc. are declared as unsigned short
> and it is possible that there is an integer overflow.
> Does regs.x.bx_hi have any meaning?  It has value 11826.
>
> Similarly, regs.x.ax_hi =  8224
>            regs.x.cx_hi = 30049
>            regs.x.dx_hi = 28524

Seems like a definite bug in the NT DOS box when dealing with an NTFS
drive: they should have returned something like DX = 65514 and
BX = 42916, so there's no way these would overflow a 16-bit unsigned
int.  Adding low and high words of each register gives some
approximation:

		DX_low + DX_high = 31249 + 28524 = 59773
		BX_low + BX_high = 31249 + 11826 = 43075

so, using these, the total disk space is 32768 * 59773 = 1.96GB and the
free space is 32768 * 43075 = 1.41GB.  But this might be pure
coincidence, I would like to see some confirmation in other cases, or
from somebody who knows NT, before using it to fix `statfs'.

> I did not see getmnent in djlsr201.zip -- I must have my eyes checked.
> Please send me the source and suggest an appropriate calling sequence.

Your eyes are okay, the source is on src/libc/compat/mntent/mntent.c
(it also includes a few auxiliary functions).  There's a test program
at the end of the file; compile it with -DTEST and run under debugger
to see what goes wrong inside `getmntent'.  Thanks.

- Raw text -