11-19-2016, 10:46 PM
Doing it that way for anything other than standard MS-DOS disks would require writing a Windows filesystem driver for every single disk format. Just off the top of my head, differences such as file attributes, character encoding, maximum file sizes, file "types", and so on, would make that impractical. And as a drive letter, you are not just talking about reading and writing, but also allowing applications to keep files open for manipulation which could have some interesting semantic differences.
I guess that could also be done taking an approach to make it look like sort of a network drive rather than using an actual Windows filesystem driver, but there would still be similar complexities.
Another thing to keep in mind is that even with the built in Windows drivers, it doesn't technically know how to read and write FAT - Since 95 it technically reads and writes VFAT. That is mostly backwards compatible with DOS 6.x FAT, but writes all kinds of garbage such as last-accessed file dates and hidden LFNs to disks. Some systems and disk utilities will choke on VFAT, and there is no real option to filter that stuff out.
Honestly, I am somewhat surprised Microsoft hasn't dropped support for VFAT and made everyone use NTFS or one of their later FAT variates.
I'd think a more flexible solution would be just an application that integrates with the SCP and presents the contents of disks as a Windows Explorer-like drag and drop interface with optional batch tools. It could also manage things like formatting, checking, and coping with any non-automatically detectable file system variations. For some types of media an application like that could limit reading and writing to just the changed sectors or tracks. But where needed (or not implemented for simplicity) it could fall back to reading and writing the entire disk at once.
As it is right now, with a SCP or similar, one would have to prepare a disk image in a tool like WinImage, convert it with HxC and then write that image with the provided tools. (I guess HxC can do some file level stuff, but it is not friendly) Even if it is not accessible as a drive letter, a friendly well integrated tool could make accessing files much faster and easier.
I guess that could also be done taking an approach to make it look like sort of a network drive rather than using an actual Windows filesystem driver, but there would still be similar complexities.
Another thing to keep in mind is that even with the built in Windows drivers, it doesn't technically know how to read and write FAT - Since 95 it technically reads and writes VFAT. That is mostly backwards compatible with DOS 6.x FAT, but writes all kinds of garbage such as last-accessed file dates and hidden LFNs to disks. Some systems and disk utilities will choke on VFAT, and there is no real option to filter that stuff out.
Honestly, I am somewhat surprised Microsoft hasn't dropped support for VFAT and made everyone use NTFS or one of their later FAT variates.
I'd think a more flexible solution would be just an application that integrates with the SCP and presents the contents of disks as a Windows Explorer-like drag and drop interface with optional batch tools. It could also manage things like formatting, checking, and coping with any non-automatically detectable file system variations. For some types of media an application like that could limit reading and writing to just the changed sectors or tracks. But where needed (or not implemented for simplicity) it could fall back to reading and writing the entire disk at once.
As it is right now, with a SCP or similar, one would have to prepare a disk image in a tool like WinImage, convert it with HxC and then write that image with the provided tools. (I guess HxC can do some file level stuff, but it is not friendly) Even if it is not accessible as a drive letter, a friendly well integrated tool could make accessing files much faster and easier.