> 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 BPB": "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. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
