Mounting a folder as the D: drive within Windows 98 is possible but it has issues

[PoloniumRain]

A long time ago i discovered that if i create a RetoArch playlist file and point it to a folder (instead of a game) DOSBox-Pure will mount everything inside that folder as the D: drive within Windows 98 SE. So for example, i have a playlist file that looks like this:

    {
      "path": "E:\\Emulators\\ROMs\\Windows 9x",
      "label": "Windows 98 Second Edition",
      "core_path": "E:\\Emulators\\RetroArch\\cores\\dosbox_pure_libretro.dll",
      "core_name": "DOS (DOSBox-Pure)",
      "crc32": "0|crc",
      "db_name": "Windows.lpl"
    },

You can see that the path points to a 'Windows 9x' folder, which contains many games, software, tools and so on. It's roughly 61GB, so once this folder is mounted it basically becomes the D: drive within Windows 98, but with an extra 8GB of free space (because i've set the D: drive to 8GB inside Core Options). So currently i have a D: drive that's a total of 69GB (nice). This way of doing things makes it way more easy to transfer files around because i can just place them inside the folder. Games and software can also be installed inside this folder, so i don't even need to install most stuff inside Windows 98. It also gets around the 8GB D: drive limit and will no longer require a large C: drive.

This is the most convenient way i've found of doings things (which many people are having trouble with - #297 #460).

But the problems with this method are:

1. DBP will create a new save file if a single file is changed inside the 'Windows 9x' folder on the physical PC. So a save might be called Windows 9x-DAAD2458.sav but if i make any modifications to the folder, a different save file will then be created. Obviously this means that any changes to the D: drive inside Windows 98 will be lost, being as modifications to D: are saved in these .SAV files.

Possible solution: Instead of this hacky way of doing things, maybe you could implement a feature inside Core Options that lets us choose a folder to mount as the D: drive? (which also doesn't create new saves if anything is changed).

2. On the Start Menu, if i run a second Windows installation, DBP will treat it as the same "game" because i've run the same "game" from the playlist. So it will use the same save file for the D: drive as the other Windows installation, and this also causes crashes. Not always but about 1 in 5 times it will completely lock up Windows 98 once it reaches the Desktop, or sometimes crash RetroArch. So instead i've tried creating separate playlist items for each OS, but because the path within the playlist points to the same 'Windows 9x' folder they will still use the same .SAV file. A fix would be to create duplicates of this folder but with different names, but being as it's a 61GB folder this isn't practical.

Possible solution: Create saves based on each individual OS .IMG file instead of what the path points to in the playlist.

BTW i'll compile and test changes regarding this issue if it helps!

[Renkoto]

This is what I've been looking for too, it's a must-have feature that should have been there a long time ago, is there a way to disable that saving feature?

[PoloniumRain]

is there a way to disable that saving feature?

Hmm i'm pretty sure there isn't. You can do it for the C: drive with Core Options > System > OS Disk Modifications > Discard so we need something like that for D:. Although i'd still prefer saving to work properly with this method.

[schellingb]

Disable saving on D: would be possible but would it make much sense? I couldn't think of a scenario so I haven't made it possible. Saving needs to be enabled on one drive at least, right?

Regarding the original question in this issue I need to explain how the saving of a mounted ZIP or folder works in DOSBox and in a booted OS like Windows 98: When mounting a directory in DOS and making changes to it, DOSBox is in charge of the file handling. So it can easily just read and write from the hosts file system and no separate save file is needed. Now when booting into an OS like Windows 98, the OS is in charge of file handling. It doesn't tell DOSBox it wants to read or write to a file, it just says "I want to read/write sector X of the physical hard drive". So what I've done for DOSBox Pure is, when having ZIP or directory mounted while booting the OS, it will generate the layout of a harddrive with a FAT file system with everything in the drive.

Basically the layout of the faked hard drive looks like this:

• A fake partition table with 1 partition at sector 0
• A fake boot sector of the partition at sector 32
• A fake FAT directory starting at sector 33 (or 64 if generating a FAT32 file system), the length of it depends on the emulated hard disk size
• Fake FAT directory records in the sectors follows the FAT directory
• The actual file data follows the directory records
• Last after the file data are faked empty sectors depending on the "Free Space on D:" core option

As a simple example, with 3 files A, B and C the files might end up like this:

• File A with size 60000 bytes at sectors 200 ~ 327
• File B with size 20 bytes at sectors 328 ~ 391
• File C with size 1 MB at sectors 392 ~ 2439

Now after this fake drive is generated, Windows is free to change any sector of it. Any changed sector is written to the save. Now keep in mind DOSBox does not know really what changed on the file system, it only knows raw sectors at this point. File operations done by Windows 98 can be very complex. It can reorder any part of the layout at any time. The OS is even free to defrag the drive or format it with a new file system. So the save file for the D: drive contains changed hard disk sectors, not modified files (which is very different from the *.pure.zip saves made on DOS file systems).

So if anything where to change on the source of what gets emulated as the D: drive (a file added or removed, or the size of a file changed) it will not result in the same fake hard drive layout anymore. Therefore the changes done by the OS to sectors stored into the .sav file will not apply anymore.

DBP will create a new save file if a single file is changed inside the 'Windows 9x' folder on the physical PC. So a save might be called Windows 9x-DAAD2458.sav but if i make any modifications to the folder, a different save file will then be created. Obviously this means that any changes to the D: drive inside Windows 98 will be lost, being as modifications to D: are saved in these .SAV files.

So with the explanation above, I hope it's more clear that this is not a "fixable issue" but instead a necessity for a writable D: drive based on a mounted DOS file system to work at all in the first place.

Regarding the second point I'm not sure why you experience issues using the same D: drive with the same sav file in multiple OSes. It really should just work and I'm pretty sure I tried this a few times. I think if there is an issue with the drive emulation this should be fixed instead of making a separate .sav file per OS.

[PoloniumRain]

Thanks for explaining all that. It's interesting and i appreciate how you usually do this when most people don't bother to explain anything.

So looks like it can't ever be "fixed" then :/

Disable saving on D: would be possible but would it make much sense? I couldn't think of a scenario so I haven't made it possible. Saving needs to be enabled on one drive at least, right?

Yeah, so i still have saving enabled for C: drive. But with saving enabled for the D: drive this is currently what happens for a single Windows 98 installation:

And that's just from a couple of days. These save files constantly keep increasing as i'm making changes to the mounted folder. Before i figured out what was going on i had 40+ save files taking up almost 10GB of space. So for this type of use case it would be very useful to have an option to disable D: drive saves, because right now i'm always having to go in to the RetroArch 'saves' directory to delete these.

I still think that the best option would be to have each OS .IMG use its own separate D: drive save file, which also didn't create another save file when modifications were made to the mounted folder. Because then there wouldn't be much reason for an option to disable saves for the D: drive. But if this isn't possible to do, then having an option to disable D: drive saves would definitely help.

It really should just work and I'm pretty sure I tried this a few times. I think if there is an issue with the drive emulation this should be fixed instead of making a separate .sav file per OS.

It's always been a weird problem and can some times take up to 10 or so boots before it locks up/crashes. I'm sure i mentioned it ages ago and you couldn't replicate the issue then either. Wish i could find a reliable way to replicate it... Deleting the .SAV files always fixes it though.

[schellingb]

Yeah accumulating these .sav "orphans" isn't great. The core just sees the current file layout and calculates the hash of it which results in the letters and numbers before the . in "Windows 9x-****.sav". It doesn't even realize there are old variants.

In theory an overall different system might be possible where DOSBox reads modifications made to the emulated FAT filesystem and smartly figures out what has been changed. Then we could have a save format that is the same as in DOS (a ZIP file with changed files). This would work as long as the OS doesn't format the hard disk with a non-FAT filesystem, which isn't really possible on Windows 9x anyway so not really something we should be concerned with (in theory some simple/old Linux might work in DOSBox but that's not really a use-case we target). But... it's a lot of work, I briefly thought about it but it didn't seem feasible when I originally added the "OS Booting" feature. Maybe some day :-)

In the meantime we could add a second set of choices to the "Free Space on D:" option which would not write any changes to disk.

[Renkoto]

In the meantime we could add a second set of choices to the "Free Space on D:" option which would not write any changes to disk.

I would say that the simplest option is to let the OS (Windows 9x) take care of that, I say this because those save files can not only contain the modifications made to the folders but also the game save files themselves that have been run in that mounted folder. I say this because I tried to delete these save files and the saves of a game I played there disappeared. One of the reasons this would be desirable is to not only avoid filling up the space reserved for the OS img, but also to avoid creating excessively large images that consume the host's disk space, this is important to me and most people who have storage drives with modest amounts of space (less than 500 GB).

However, I don't know if there will be some limitation that prevents this, since Retroarch nor the core cannot mount folders directly and has to be done by manually writing the playlist file.

There are other forks of DOSBox that are standalone and therefore don't have this issue, such as X, but DOSBox-X is slower and more cumbersome to set up.

[PoloniumRain]

But... it's a lot of work

@schellingb Lol it sounds good though and i hope you can find the time some day :) But yeah, for now i'll be happy with an option to disable saves!

I would say that the simplest option is to let the OS (Windows 9x) take care of that, I say this because those save files can not only contain the modifications made to the folders but also the game save files themselves that have been run in that mounted folder. I say this because I tried to delete these save files and the saves of a game I played there disappeared.

@Renkoto What you can do is install each new game to the C: drive, play through it and create game saves, then open the Windows 98 .IMG file in UltraISO and copy over the game folder to the folder that gets mounted as the D: drive. The game save files as usually located in the games folder as well, and if you set up the games graphics/control settings before copying the folder then all of these settings are copied over too. If you do this after completing each game then the C: drive doesn't need to be large. It's a pain to do but you'll never have to do it again, and all the games can simply be run from the D: drive with all your settings/saves without needing to install these games again on other Windows installations. So far this has worked with every game i've tried (but i bet there's some where it wont work).