Mail Archives: djgpp-workers/1997/10/20/16:02:50
On 20 Oct 97 at 15:00, Eli Zaretskii wrote:
> We need to think about this in the context of libc functions.
> Suppose some function needs to know whether to issue a
> FAT32-specific call or not. If it will try to call 217305 every
> time, won't that make that function prohibitively slow? If it will,
> we need a faster way.
I was thinking of a once off call that sets a flag indicating the
need for FAT32 calls (that's what I did in my lfn driver, but
reversed)
> What happens if you issue a FAT32 call on a FAT16 drive but under a
> version of DOS/Windows that supports FAT32? Will that work or fail?
I don't know about FILE calls, but I know that the sector calls work
because debug can still read/write floppy drives and I know (from
disassembling debug) that only 217305 is used for sector access.
I'll try out the FAT32 file calls on a floppy, but I honestly can't
imagine them not working on non fat32 drives if they work at all (ie
the calls are either legal or they're not, no dependency on the
drive, just the OS).
I can't prove it, but I wouldn't be supprised if the FAT32 version of
W95 doesn't actually know anything about FAT12 or FAT16 at the
filesystem level (except for directory entries). I found it much
easier to treat all drives as FAT32 and just use 32 bit cluster
numbers, letting the disk driver worry about the details
[complete sideline, how do I get my filesystem level that's not
supposed to know about fat types (ideally cluster numbers are just
magic cookies) handle directory entries cleanly? I've got to cope
with OpenDos as well so I can't assume anything about the spare
fields in a directory entry? Also, my disk driver level knows about
the three fat types but knows nothing about directory entries, so it
can't be used to extract the starting cluster either. Could someone
suggest a clean solution? At the moment the filesystem level peeks at
the fat type in the disk level in a couple of places.]
Bill
--
Leave others their otherness.
- Raw text -