Repository navigation
os=win31 is not working for windows 3.11 dosz #129
Description
A simple zip renamed dosz with windows 3.11 files and a conf file named the same as the game.dosz on loading the game.dosz in retroarch
Something very very strange happens in this situation
- The default rust-dos drive c is mounted not the windows 3.11 dosz
It attempts to change to d and gives no error (but stays in c)
Conf file:
[rust-dos]
os=w31_64k
[autoexec]
call c:\windows.bat d:\INDYDESK\DESKADV.EXE
exit
What happens:
This works for windows 95 btw, just have to use "boot -l c" instead of calling that bat.
Activity
i30817 commentedon Oct 16, 2026
If I comment the autoexec lines I get this:
It seems some kind of weird timing problem?
i30817 commentedon Oct 16, 2026
Removing "call " also does the same.
I'm surprised exit wasn't obeyed, but I have a hypothesis that for some reason that bat file is failing in rust-dos and it fallbacks to the "end of the autoexecx section (after ignoring exit) and unmounts the drives, I'll have to test with a empty or missing autoexec section
Edi: what happens is that rust-dos copies the autoexec section, minus any exit, to its own conf file for the dosz, and doesnt override some sections. I did have some problems that prevented windows from booting like not being on c before calling the bat, but the main one is the graphics card being overriden without the possibility to force it in the original game.conf files see below
i30817 commentedon Oct 16, 2026
Trying to run windows.bat alone without a autoexec gave me a windows error about not being able to run it because of a device conflict, which is well enough since I have a s3 and a voodoo 2 turned on in dosconfig.
However that error then unmounts the drive on exit.
I think what's happening is that on a error exit from a windows boot or windows 311 run, rust-dos is unmounting the drives.
So its not exactly a bug maybe, just confusing. I'll try it with a working windows 3.11 or mess around with the graphics and will return if it works then.
i30817 commentedon Oct 16, 2026
Yep. Changing to S3 Virge ran the OS then.
Mmm I think this is a user problem maybe
i30817 commentedon Oct 17, 2026
I think there is a real bug here.
If I setup the .conf file corresponding to the game .dosz like this:
The file (not existing at the start)
/storage/emulated/0/RetroArch/saves/rust-dos/rust-dos/games/indiana-jones-and-his-desktop-ad.conf
Gets created with these contents:
Notice the wrong vga card for this version of windows 3.11 being forced?
If I try to cheat the system by adding to the .conf file corresponding to the game .dos the entry
/storage/emulated/0/RetroArch/saves/rust-dos/rust-dos/games/indiana-jones-and-his-desktop-ad.conf
Still gets created with the wrong graphics card in [emulator] section.
i30817 commentedon Oct 17, 2026
/storage/emulated/0/RetroArch/saves/rust-dos/rust-dos/games/indiana-jones-and-his-desktop-ad.conf
Also the repeated rust-dos in that path is a common error of claude when attempting to use libretro paths. It doesnt understand libretro hands the paths with the core name directory in the leaf already.
dividebysandwich commentedon Oct 17, 2026
To be fair it's not only claude that didn't know this ;)
EDIT: Looks like multiple bugs to me. You not being able to override the machine config is a bug and not user error, and of course the libretro path issue is a bug too.
The unmounting is by design, your game was finished and so everything is reset to its original state, so you can launch a different game (which loads the associated machine setup, drive mounts, etc), or work with the plain emulator in its default configuration state.
Trio+Voodoo2 might be a bug, will give this one a try here in a minute. In theory they should be able to coexist since their address windows don't overlap.
Keep DOSBox's S3 for a Windows of files and honor [rust-dos] machine= (…
Don't nest rust-dos in a libretro save folder already sorted by core (#…
Say at the prompt that a game has ended and its drives are back (#129)
i30817 commentedon Oct 17, 2026
They do work windows 95 even shows both. Not sure its ideal for speed though.
I'd also like to exit after running a game but I understand mounts have to be unmounted etc.
i30817 commentedon Oct 18, 2026
Doesnt the fix sound a bit fragile? This is one of the settings changed, what about others.
dividebysandwich commentedon Oct 18, 2026
You're right. Working on a more generic solution.
Take all of rust-dos's own settings in a DOSBox configuration over th…
i30817 commentedon Oct 18, 2026
That commit message implies the opposite of what i s needed.
"Take all of rust-dos's own settings in a DOSBox configuration over the import's (#129)"
I'm trying to make the companion .conf file to the opened dosz game settings have priority (or just ignore, at least the ones not required for the disk overlays and mounts) the settings on /storage/emulated/0/RetroArch/saves/rust-dos/rust-dos/games
The message implies they always win over the conf file I loaded/expected to rin
Unless "import" isnt the game.conf file.
i30817 commentedon Oct 18, 2026
I need to test the build before commenting more, please wait a bit
i30817 commentedon Oct 18, 2026
Nope it works. I dont really understand the commit message but it seems ok
One thing still not working right. The exit command after the windows.bat
I understand it was removed because of the drive overlays close but it should in essence be moved "after".
When booting a windows 95/98 with boot -l c any commands after are ignored because it keeps on that "you can shut down now" windows screen (except if you have that patch to auto shutdown, which I hope that if you take up, also works with drives overlay close) but for windows 3.11 returning to the shell I expect not to be stuck on the shell after if I use exit.
I haven't tested how the shutdown in both windows 95 and windows 3.11 saves modifications yet.
i30817 commentedon Oct 18, 2026
There is also another problem now. With a empty autoexec in the game.conf file so you can see its not the windows load the problem (the windows w31_64k.dosz os mount does not have doskey on it, I searched)
It shows this doskey error
I think rust-dos is expecting to have a environment to run some commands it doesnt have in this kind of boot? I believe this is the shell history command
i30817 commentedon Oct 18, 2026
I also think the automatic d: it does is unexpected by users. I know it probably did it because the game was relocated to d from c so the is could go to c. I dont think it should happen.
Maybe we can do something else to make it predictable which mount the game ends up in when autobooted?
Something like
[rust-dos]
os=w31_64k
dosz_drive=d
And if the game/dosz drive is c it is overlaid on the os drive and modifications are saved in the same overlay. Missing dosz_drive default could be c for the most useful case for users that dont already have a collection of installed in d games like me.
I'm not sure how this should work with automount dir in dosz. I think like a drive of the same "name" as the os in a automount replaces the os drive, dosz_drive should be replaced by a d (in this case) drive in the automount dir.
If you have a better name than dosz_drive, please use it. It should ideally indicate the file it refers to is the booted dosz with the same name as the conf, a bit of a inversion of control, since booting conf files usually mounts c as the location the conf file is in.
i30817 commentedon Oct 18, 2026
Btw another bug. If a added a different conf file settings like
The "imported" file had
Which is the same error again.
Edit: removed the speculation about vmemsize. Turns out, rust-dos doesnt use this at all according to copilot
i30817 commentedon Oct 19, 2026
Copilot also told me I had to use
[emulator]
voodoo=true
voodoo_model=voodoo2
voodoo_memory=12
voodoo_renderer=opengl
Instead of "[voodoo]" and "glide=false" that google ai hallucinated.
Disregarding the svga_s3 not sticking problem (that I have to edit in the conf files in retroarch/saves/rust-dos), that fixed win95 overlays (I had installed the OS with both S3 and a voodoo 2 emulated card from the GUI settings so I had to recreate the config from the game conf after deleting the GUI settings for testing).
I also like now that os= overlays even without a dosz/zip boot with a overlay always unless you edit those files. Its faster.
I noticed adding a overlay to a 1gb+ game in a dosz takes a long time. I wonder, why, if there is a checksum being calculated, because zip has a inbuilt crc32 that can be used for it (I noticed a md5 I think in the game.dosz boots with os= game.conf file save dir conf mirrors.)
i30817 commentedon Oct 19, 2026
That is to say, the bug still exists, I believe. I got the release from here https://github.com/dividebysandwich/rust-dos/releases/tag/v1.7.5
And svga_s3 was still being turned into svga with a game.conf like this:
Doesnt matter if you boot the game.conf or the game.dosz (first gets put into imported folder, second gets put into the games folder, but both are broken this way).
For example, this is the game.dosz version
Note the svga.
i30817 commentedon Oct 19, 2026
If there was a fast way to calculate a internal checksum for a vhd file, dynamic or not it would be nice if booting one with the game.conf file available also did the copy-on-write if the os= setting was there. I already suggested using the zip crc32 for dosz, not sure if vhd or hdi has something like that.
i30817 commentedon Oct 20, 2026
I can avoid this bug by moving the "machine=svga_s3" line to a "[emulator]" section in all cases it appears. I shouldnt have to, but its possible.