schellingb
No way to disable automatic C mounting
When loading any type of content with dosbox-pure, be it a zip, or a conf, or anything else, it automaticaly mounts the same folder as the content as the C drive. This breaks behavior of autoexec commands in conf files.
I need to use conf files directly the same way I would with other dosbox forks, but with this kind of behavior, it's impossible.
it automaticaly mounts the same folder as the content as the C drive.
This is not random, DB-Pure mounts the folders respecting the original structure of a PC.
It is not a fork like the others. Note that it is deeply tied to the RetroArch interface and all its advanced features.
Almost everything is configured automatically, the .conf is not necessary and some of its commands are not compatible, indeed they generate errors.
Pre-compiled files must be unzipped, the first folder discarded and then re-zipped.
When loading something like a ZIP file with a .conf file inside it, the ZIP file has to be mounted as C:. The [autoexec] section of the .conf can then remount it to something else if it wants. Because loading ZIP files is not something regular DOSBox does, this should not be seen as a difference to regular DOSBox.
Though when loading a .conf file as content directly from the libretro frontend, there is an argument to be made that the directory which the .conf is inside should not be mounted as C:, and any mounting would have to be done by the [autoexec] section (or manually in the command line). I wonder if it would break setups already in use if that were to change now...
This change has now been made with 710120a. In addition c2730d6 and 59a20b1 were made which enables mounting paths relative to the loaded content in the command line. Meaning if you have "GAME.ISO" in the same folder as the .conf you are loading, the conf file can have imgmount D GAME.ISO -t iso in its [autoexec] section and it will find the correct file. This also matches the other DOSBox libretro cores.
Again, this change only affects when loading a .conf as content directly. Other means of loading .conf (for example inside a ZIP or next to the loaded ZIP) will still work as always. It doesn't make sense to only load dosbox.conf out of the ZIP file and then not have the other content of the ZIP available as a mounted drive, right?
This very likely will be a breaking change for people who have relied on the current behavior. But I feel like matching the other DOSBox cores in this regard is more correct. To adapt to the new behavior one will need to add a line with mount C: . at the top of the [autoexec] section of the loaded .conf file.
The changes have now been released in the newest version 1.0-preview1 available here and from the RetroArch online core downloader. There's a small issue which was fixed via #566 when mounting a path that ends with a \ backslash which was failing on Windows. Once that fix is released I think this and #566 can be closed.
Why not make this optional though? So that it doesn't break current behavior, and adds the possibility of the conf file to be compatible with other dosboxes. Just add a simple switch in the core settings.
Commit c571700 added an option to bring back the old behavior by having this part in the .conf file:
[dosbox]
automount=true
I think it's fine to have a non-standard .conf setting like this because the .conf files themselves are not unlikely to be shared with other versions of DOSBox. That is because to automatically start games on other versions of DOSBox the mounting would happen with mount and imgmount commands in the [autoexec] section and then this automounting isn't needed.
If I wanted to load a .zip file but use an external .conf file to do the mounting (and avoid automounting), is there a version of the DBP DLL that I can get or generate?
When loading something like a ZIP file with a .conf file inside it, the ZIP file has to be mounted as C:.
Why can't there be an option to have it loaded as Z:? That's the normal behavior of DOSBox if you're treating the root of the ZIP as a start directory.
If I wanted to load a .zip file but use an external .conf file to do the mounting (and avoid automounting), is there a version of the DBP DLL that I can get or generate?
Maybe I can look into supporting ZIP files with IMGMOUNT. But it would be read-only (just like mounting a CD) because it would be able to mount multiple ZIPs and we can't really make multiple save zip files to support multiple writable ZIP based drives.
Why can't there be an option to have it loaded as Z:? That's the normal behavior of DOSBox if you're treating the root of the ZIP as a start directory.
If you launch normal DOSBox like DOSBOX.EXE g:\games\doom then g:\games\doom will be automatically mounted as the C: drive with no option to get anything else. Regular DOSBox of course has no support for ZIP files, but I think this is somewhat comparable to our ZIP loading.
DOSBox Pure has a remount command to switch a drive letter. So if you run remount c x then C: will become X:. Maybe you can use that?
DOSBox Pure has a
remountcommand to switch a drive letter. So if you runremount c xthen C: will become X:. Maybe you can use that?
Thanks, that may be the only option in combination with subst in order to redirect C:. to a ZIP subfolder.
Is it at least possible to disable the automounting of images inside a ZIP?
If you have a .conf with an [autoexec] section and no mention of automount=true, it shouldn't automount any image.
Thanks, I got it all working. Is it correct that DBP ignores everything outside the [autoexec] section when loading .conf files?
No no, many things outside [autoexec] are supported perfectly fine in DOSBox Pure.
Most things from the documentation of original DOSBox are supported. Unsupported things are just a few, like the entire [sdl] section (we don't use SDL), scaler of [render] (all that is handled better by RetroArch) and the [serial] and [ipx] sections (playing multiplayer in RetroArch with DOSBox Pure sets up all networking automatically).
Edit: Also to clarify, if you for example have memsize=32 of [dosbox] in your .conf, the core option that affects the same setting (System -> Memory Size) will not do anything because the .conf settings take precedence. In the latest version (not yet released) changing a core option that is controlled via .conf will actually show a message "Unable to change setting which was fixed with game configuration". In previous versions there was no message but changing core options controlled by lines of the .conf would just do nothing.