passthrough for FAT-emulated drives to the backend linux directory

[cowarlydragon]

I am on Linux

I just encountered this and it is a bit unexpected in terms of user experience. I was trying to mount games from folders, but of course discovered that when I installed in the guest OS win9x and shut down the "install" disappeared. Also, savefiles won't work either.

Of course I'll use the x+250MB img files for now.

but FAT filesystems are "relatively" well known from many/most host OSes at this point. There are also things like SMB/Samba, which I'm also going to try for now to get the desired behavior. But possibly a MOUNT command could have a samba/smb interface. There's probably a lot of FAT16/32 code in the wine codebase that could be adapted for actual FAT16 --> whatever linux FS exists, and you'd think windows could be mapped to NTFS.

Is there a starting point to look at things like this, particularly linux and wine codebases, and how it might be accomplished? I assume the disk writes are all dosbox-x intercepts at the dos / bios layer, and there is a basic interface/implementation/api/plugin aspect to it in the dosbox-x codebase.

Or is this an issue that the host OS uses syscalls that bypass the emulated DOS layer, and if you get beyond that you are basically in WINE territory?

Perhaps a stopgap would be a simple synchronizer thread that reads from the emulated FAT drive and syncs the files. If you already have an image-write option, just automate it every n seconds? An append-only strategy with compaction could also be used,hm that would require intercepting all writes to the virtual drive, that probably won't work.

The host OSs should have I/O to spare, but the virtual drive is size+250MB which is still pretty substantial. In-memory comparisons could probably alleviate a lot of excess I/O and an append+compact strategy implemented there.

[cowarlydragon]

Also, where are the emulated fat files, on linux at least. Are they completely in-memory? I'm assuming you write them to memory-mapped files and the "write to img" is just copying that file to someplace else?

[joncampbell123]

As I understand it, the "fat" filesystem is a temporary FAT structure built around local files, and changes to it do not persist on shutdown.

[joncampbell123]

If you intend to install anything, you'll need to make a disk image and IMGMOUNT it and then use that for persistent data.

[jelabarre59]

I had just experimented with this as well. I found the switches to skip checking disksppace, not writing to MBR, etc. but I saw that nothing was being written to the directory hosting drive C:. Win98 was happily humming along in it's install, but I presume it was just writing to temporary memory.

I had been trying to create a setup like I had many years ago with "Win4Lin" (probably 25 or more years ago). That utility was able to simulate a HDD for the Win9x install, but it was actually installing the files to a directory under $HOME. It did, however, require a custom kernel to support the application.

So I expect there's a way to present a directory as a "disk" to Win9x, it's just a question of how they did it.