Hi, El jue, 23 feb 2023, 0:19, Bret Johnson <bretj...@juno.com> escribió:
> > 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. > Well, I think it's hard to know which were the extra features of IFS over the already existing network redirector. This feature (I would include it as hot plug'n play) could be one, because it's probably IFS which increased a lot the conventional memory consumption of MS-DOS 4 over 3.x. However I find it unlikely. My bet is that IFS included the minimum necessary to mount HPFS in DOS. In one of the aforementioned articles, there's a funny comparison between MS-DOS 4/5 and Windows Vista/7. The former being undeservedly guilty of horrible memory consumption and the latter seen as a leaner savior. I can't know the story from my own experience, because I jumped from MS-DOS 3.30 to 6.00 (yeah I lived DOUBLESPACE and not DRIVESPACE). But being MS-DOS 5.0 published when it was, after the quarrel with IBM, I can just speculate that if MS-DOS 5.0 needed more conventional memory, IFS would have been one of the first things to go. Which is a pity, because from those articles one can infer that it tried to make mounting file systems less reliant on MS-DOS internal structures. A good idea for which your 16-bit PC has not enough memory :) > *** > > 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 >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
