> Also I found references on IFSFUNC: in 2Fh (AH=11h), IFSFUNC > functions seem to be entangled with the network redirector > functions: > > http://www.ctyme.com/intr/int-2f.htm > > Apparently, these functions would be made available by IFSFUNC.EXE > (curiously not provided by kernel itself). >... > My conclusion would be that it looks like an alternative > functionality update to the network redirector itself (and not > something entirely unrelated), that tried to solve some of the > previous problems and/or tried to be more abstract and less tied to > internal DOS structures, that was implemented only in DOS 4.0, > probably to try and make HPFS available for DOS, but that was later > abandoned (due probably to high memory requirements) in favour of > maintaining the old redirector).
That's kind of an interesting take, but it's ultimately not what I would like to see. I would like things to be "embedded" as a kernel extension so additional drives can simply be "plugged in". That's how my USBDRIVE program currently works. What I do with USBDRIVE is "inject" the USB drive information into the various DOS tables (like the CDS & DPB structures) and the device driver chain as needed. DOS itself already knows how to process FAT12/FAT16 and (in some cases) FAT32 partitions/disks. I leverage that capability so that the USB driver doesn't need to handle it. The USB driver basically just gives DOS access to the sectors and DOS processes the data that's in the sectors. As USB disks get plugged and unplugged the various DOS tables get updated but DOS already knows how to handle that (DOS can handle removable disks with different sizes that all use the same drive letter). I would like to see a similar setup for additional drive formats (like exFAT or HPFS or NTFS or UDF or whatever). Something where the driver has "slots" that different disks can be "plugged" into in real time and the software automatically adjusts itself to the disk that's currently installed. I've not studied the network director to know if something like that is even possible, but is what' I'd _like_ to see for future flexibility and compatibility. *** As an aside, I'm wondering if anybody has a "fool-proof" test for FAT32 capability in the kernel. In USBDRIVE what I currently do is go through all the drive letters and see if any of them responds correctly to INT 21.7302h (Get Extended BPB). This test works if there is at least one existing FAT32 drive letter, but will fail if there are no actual FAT32 partitions even if the kernel supports FAT32. I don't know of a direct or fool-proof way to detect FAT32 support, but maybe somebody else has come up with something. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
