Hi, actually there are TWO bugs:
> This appears to be due to the following code in FreeCOM's
> dir.c, function dir_print_free....
> r.r_ax = 0x7303;
> ...
> intr(0x21, &r);
> if(!(r.r_flags & 1)) {
> ...
This test is wrong, as RBIL D-217303 states:
Notes: on DOS versions which do not support the FAT32 calls, this function
returns CF clear/AL=00h (which is the DOS v1+ method for reporting
unimplemented functions)
So basically on all FAT32-unaware kernels (FreeDOS kernels behave as if
they are FAT32 aware even if they are compiled without FAT32 support!)
FreeCOM will try to use the FAT32 size info anyway, which is bound to fail.
So you would do "if al!=0 AND carryflag==0 then use FAT32 info".
> convert(FAT32_Free_Space.free_clusters /
> ((1024l*1024) / clustersize), buffer);
> ...
> Specifically, the disk is reporting 64 sectors per cluster and
> 32768 bytes per sector. This makes ((1024l*1024)/clustersize)
> evaluate to 0!
I do not think so. It should evaluate to 32... Still you get less
danger of overflows by doing e.g.
FAT32_Free_Space.free_clusters / (2048UL / (clustersize/512))
Eric
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
