Date: Mon, 20 Oct 1997 10:53:51 +1100
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: Detecting fat32 drives.
In-reply-to: <Pine.SUN.3.91.971019171415.27221Q-100000@is>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com,
        ralf AT pobox DOT com
Message-id: <199710192150.KAA06994@teleng1.tait.co.nz gatekeeper.tait.co.nz>
Organization: Tait Electronics Limited
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <199710162127 DOT KAA25018 AT teleng1 DOT tait DOT co DOT nz gatekeeper.tait.co.nz>
Comments: Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>
Precedence: bulk

On 19 Oct 97 at 17:14, Eli Zaretskii wrote:

> On Fri, 17 Oct 1997, Bill Currie wrote:
> 
> > I don't know how reliable this is, but I just found out how to detect 
> > fat32 drives: attempt to read sector 0 (or any other, I imagine) 
> > using int 25,cx=0xffff. This will return with carry set and ax==1 
> > (invalid function) if the drive/partition is fat32.  This function 
> > works as normal for non-fat32 drives (floppies, anyway).
> 
> To make sure it is indeed robust enough to be included in the
> library (if we need it), you will have to try it on other types of
> drives as well.  CD-ROM, networked drives, NT drives, and DOSEmu
> environment are the things that come to mind.  We need to know how
> these react to Int 25h.

Hmm, good point, forgot about those.

> 
> > It seems W95 (IFSMGR?) remaps int 25/26 to 
> > int 21/7305 when accessing floppy drives (or non-fat32 drives??) or 
> > does the access itself
> 
> Doesn't this defeat the above test?  If Windows does such remapping,
> the call will succeed even on FAT32 drives, when you issue it from
> the DOS box, no?

Actually, I think I found a better method: use int 21 ax=7305 
cx=ffff and if it's not supported (al=0,nc), fat32 is 
not supported and so the fat32 calls need not be made, otherwise it 
doesn't hurt.

Yes, I KNOW the return values of int 21/7305 on Opendos and ms-dos 
6.20 from implementing a general sector read/write interface. On 
ms-dos 7.10 (fat32) ax is preserved, but OpenDos and ms-dos 6.2 
(<6.20, 6.22 and 7.x other than 7.10 ared untested) return 0x7300 in 
ax.
Bill
--
Leave others their otherness.