> actually BLOCK drivers are only suitable for making > FAT partitions on non-BIOS drives (e.g. USB) usable > by DOS. For other filesystems, you would use other > interfaces: CDEX / network redirector API, as used > for ISO9660 CD/DVD and for VMWare in VMSMOUNT :-)
Not necessarily. Whatever the non-native file system is (exFAT, ext?, NTFS, or whatever, including FAT32 in the case of older versions of DOS) there are two ways to do it in DOS -- a device driver or via the network redirector (I'll refer to the network redirector ans an Installable File System or IFS here, even though it isn't technically correct). A device driver has the advantage of being able to leverage the code already built into the kernel which already understands where the metadata is and what it means (the FAT table(s)), and also where the user data is and how to access and modify it. A device driver also has the advantage of basic inherent compatibility with common DOS utilities and processes like INT 25h/26h, caching (at least DOS caches like SMARTDRV, not necessarily disk caches like LBACACHE), DEFRAG, CHKDSK, and others (FORMAT and especially FDISK are a little different and can't be leveraged as easily). An IFS has the advantage of allowing access to file systems that don't resemble FAT at all. In CD's and DVD's, for example, the media is linear (a single track) and the metadata and user data are interleaved instead of being logically and physically separated. A major exception to this is DVD-RAM media, which can and often is formatted with a FAT file system (FAT32), though the sector sizes are 2k instead of 512 so are incompatible with FreeDOS as it stands today (but can work with MS-DOS and some others). The disadvantage to IFS is that there is nothing to leverage, either in the DOS kernel or the existing utilities. If you are satisfied to use utilities in other OS's for the necessary leverage (like CHKDSKing), and don't care about caching, than an IFS is OK. If not, then in addition to making the driver itself you'll need to write/modify all of the other disk management utilities too. In the case of something like exFAT or ext?, the differences between them and FAT12/16/32 are so stark that there's no way to _directly_ leverage the existing DOS code and utilities. So, whether device driver or IFS, the driver itself must totally understand how the foreign file system works, what data DOS needs (and doesn't need or needs to simulate/virtualize), and how to "translate" between the two sides. The first part, understanding the foreign file system, is the same for the device driver and IFS. The difference between the two is how the foreign data is virtualized and presented to DOS. I don't know enough detail about how any of the file systems work (even the basic FAT ones) to know for sure, but the different file systems may be similar enough that it's possible to virtualize them through a device driver and make them appear to be a FAT(32?) partition to DOS even though they really aren't. For sure it would take some fiddling with the metadata -- some of it would need to be "hidden" or made inaccessible with sector translations or "fake" directory entries or something, but the user data itself I don't think would be a problem. And, of course, read-only access is much easier to do than read/write access. An advantage to IFS is that it isn't constrained to the limitations of the underlying (virtualized) FAT file system as it is in the case of the device driver. The major limitations that are a concern, and one reason people want to expand past FAT32, are maximum file size and maximum partition size. I don't think there's a way to "virtualize" those things out of existence though a device driver (though I don't know enough to say for sure) -- those limitations would be easier to obscure/ignore in an IFS implementation. Besides the size limitations, the other major driver for wanting to extend outside of the existing FATs is for compatibility with other OS's (being able to transfer data between systems). When people start talking about adding support for other _non-mainstream_ file systems (like LEAN) to DOS, I don't think it makes a lot of sense. You really need to keep what you support mainstream (aka whatever M$ is doing). The fact that it's proprietary or that you don't like M$ is irrelevant to the fact that they are still the big gorilla and you kind of need to follow their lead even when you don't really want to. ____________________________________________________________ Meet the Graviteers: Veronica Fuog I'm Veronica and I could live on omelets. I love breakfast! http://thirdpartyoffers.juno.com/TGL3141/56128a5645ab9a560f33st02vuc ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
