> Unless of course DOS refuses to use (old?) drivers which do not
> advertise these functions. Someone knows ?

I find that a minimalistic approach almost always leads to problems and 
compatibility issues.  Even if you think a function/feature/API may not be 
needed, it's still better to put it in.

>> IOW, you should still check the max sector size in the DOS List of
>> Lists before you install yourself to make sure it's 512 bytes, and
>> should refuse to install yourself if it's already 4096.
> Uh, here I'm confused, not following any more, please elaborate your
> point. Assuming we've loaded  USBASPI.SYS [which provides ector
> access to the external disk using "SCSI" commands], my hypothetical
> driver wishes to support one or more FAT partitions on that external
> disk.

It depends on exactly what your driver does.  It sounds like you're intending 
to essentially make a replacement for DI1000DD.SYS.  If so, you're going to 
need to "coordinate" your installation with DD1000DD.SYS, in case the user 
tries to install both at the same time.  Whether you abort your installation or 
not depends on whether DI1000DD.SYS is already installed, whether it supports 
4k sectors or not (I have no idea), whether there are any disks with 4k sectors 
actually plugged in or not, and whether or not the DOS kernel natively supports 
4k sectors.  You don't want to install if DI1000D.SYS is already installed and 
can already "handle" everything.  I (and you, apparently) are assuming that 
USBASPI.SYS supports 4k sectors, but I would actually verify that before I went 
very far.

If, however, you're going to do what Christian (and maybe Eric?) was thinking 
and essentially install a "shim" between DI1000DD.SYS and the kernel, things 
are a little different.  Such a shim could work even on non-ASPI disks (such as 
those provided by Georg's or my USB drivers), but should abort installation if 
the kernel natively supports 4k sectors.  In this scenario, there's also the 
potential issue of hot-pluggable disks (which are supported by my USB drivers, 
but I don't think are supported by USBASPI or Georg).

> Do you mean to say "non-IBM" ? UIAM again, the "IBM" (should be
> called "MS") formats are the usual FAT disks. IOW "non-IBM" is when
> attribute bit 13 = 1.

No, it's the other way around.  If bit 13 is set, it means "IBM Format", but 
that doesn't equate to "MS".  Here's a quote from an old book I have, "DOS 
Programmer's Reference", 2nd Edition, by Que, which gives the practical 
explanation of what the bit means, specifically regarding function 2, "Build 

"A one sector buffer is passed to this routine.  If the non-IBM format bit in 
the device attribute word is set to zero, the buffer contains the first sector 
of the FAT and should not be changed.  If the bit is set, the buffer can be 
used as a scratch area in which to build the BPB."

It doesn't have anything to do with non-FAT.

Bottom line for safety in the driver: ignore the setting of the bit, assume you 
can't change the buffer, and assume the buffer does not contain the first 
sector of the FAT.

Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
Freedos-user mailing list

Reply via email to