Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

BD-R with UDF filesystem - FS redirector with 64-bit sizes (Miscellaneous)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 22.12.2020, 19:03

> It is possible for a file system redirector (like for ISO 9660, UDF, exFAT,
> NTFS, or dosemu's host FS) to support 64-bit file sizes and seeks in a
> manner compatible to the FAT+ support of Enhanced DR-DOS. That means
> expanding the SFTs with extension fields (can be stored in file handle
> tables of the redirector), hooking the new-style interrupt 21h service
> 7142h for large seeking, and service 42h to make old-style seeking somewhat
> aware of the large size support. I did this
> for dosemu2's mfs.
> Technologically it works, but it was rejected on other grounds.
Indeed, with a redirector it is possible to do almost anything. That's how MSCDEX (and its clones) are able to let DOS versions with only 512-byte sector support work with CD's that have 2048 byte sectors, or allow access to network drives on servers that DOS has no idea how to access directly. That is certainly one approach, but also has limitations and issues.

The approach I'd like to use is to mount the disks at a low level (like INT 13h or via a "standard" device driver) and let DOS handle the file system itself, which it already knows how to do. I'm using a similar approach with my USB drivers and GPT disks. I have a test USB flash drive I've formatted with several partitions, some DOS-compatible and others not. I'm able to mount the DOS-compatible partitions (formatted with some version of FAT) and DOS can read and write to them with no problem. I simply don't mount the non-compatible partitions. Also note that this has nothing to do with booting from a GPT disk, only accessing data from it after DOS has already booted.

Right now the way things like MSCDEX work is not the way I think things should work. MSCDEX accesses the CD/DVD hardware directly (with hardware-specific code) and provides a redirector interface that DOS can understand. I'd like to see this as a two-step process where the ISO9660 driver is a shim rather than being hardware-specific. The side of the shim that points towards DOS could be a redirector, but the side that points towards the hardware is not hardware-specific but rather a more general purpose standard (maybe something like SCSI or INT 13h). That would allow lots of different types of hardware (like USB, SATA, IDE, etc.) to indirectly interface with DOS since DOS itself would be "extended" with the shim and could understand ISO9660 (or UDF or exFAT or ext or whatever) and not need a hardware-specific driver.

Again, maybe just some food for thought but ultimately a really bad idea.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 263 users online (0 registered, 263 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum