> 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
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
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