Mail Archives: djgpp-workers/2001/01/06/08:20:26
> From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
> Date: Sat, 6 Jan 2001 13:44:07 +0100 (MET)
>
> According to Eli Zaretskii:
> > > From: "Norberto Alfredo Bensa" <ceo AT nbensacomputers DOT com>
> > > Date: Fri, 5 Jan 2001 18:40:47 -0300
> > >
> > > I've just tested on Win98 plain DOS mode and 213600 gives:
> > > blocks = 32768, bsize = 4096, resulting in 134,217,728 or 128MB...
> >
> > Expected: 213600 is limited to 128MB, by its very definition.
>
> That is a little surprising as it manages to report drive sizes up to
> ~4GiB in DOZE...
For a CD, it reports the correct cluster size (2K), and this limits it
to 128MB, because the maximum number of clusters on a FAT system is
64K.
> > > Under Windows (DOS box) with 217303, I get:
> > > blocks = 19275, bsize = 32768, resulting in 631,603,200 or ~602.3MB
> >
> > That's a lie: the block size is reported incorrectly (2048 is the
> > right value). This clearly shows that we shouldn't use 217303 for
> > CDs.
>
> I realise that a bsize of 32768 is a lie, however ...
>
> > > Properties for my E: drive gives 631,603,200, that's what 217303 is
> > > reporting.
> >
> > Small wonder: I guess Windows uses 217303 itself.
>
> ... shouldn't we let WINDOZE have it's way. The INT21 AX=0x7303 calls
> do give reasonably accurate values when they succeed and it's what
> WINDOZE itself reports.
You assume that the only value the application is interested in is the
total size. What if it wants to know the cluster size?
I think a small inaccuracy in the total size is worth reporting an
accurate cluster size. (I'm also quite sure the value reported by the
CD-specific calls is also correct, but Windows might add to it
something, like the TOC or whatsnot.)
- Raw text -