DosBox Pure no longer loads selected games via *.conf files (instead of .bat, .exe, .m3u etc.)

[Ric-82]

trafficstars

Hi,

I know ther's a similar issue recently closed , but the temporary fix is not working for me.

I used to select a .conf file from the frontend to automatically load that entire folder as the C:\ drive and then select the game's executable via the DosBox Pure start menu, with any auto start options.

The latest version of DosBox Pure, however, no longer allows me to do this because if I select a .conf file, I don't see the start menu but the classic DosBox interface with the command prompt and the Z:\ drive. If I try to access the C:\ drive, it does not exist because it has not been automatically mounted, as it used to be.

In the aforementioned closed issue, I ran the same tests that the user angomania did, but with different results.

For him, the working versions were:

dosbox_pure_libretro_win64_dll_git_710120a.zip dosbox_pure_libretro_win64_dll_git_b347f1a.zip dosbox_pure_libretro_win64_dll_git_c2730d6.zip

The last two (b347f1a.zip and c2730d6) are fine for me too, but:

dosbox_pure_libretro_win64_dll_git_710120a.zip dosbox_pure_libretro_win64_dll_git_edc2d78.zip

are reported by Windows Defender as TrojanScriptWacatac.B!ml

I tried dosbox_pure_libretro_win64_dll_git_be4fb69.zip and dosbox_pure_libretro_win64_dll_git_59a20b1 as well, but both result in a black screen.

Finally, the version you published as a temporary fix (dosbox_pure_libretro_win64_dll_git_ea5d52d.zip) in my case works exactly like the current version of DosBox Pure, i.e. the .conf file does not automatically load the folder in which it is contained as a C drive, the start menu does not appear and basically it is not possible to start any content.

What can it be?

I am using DosBox Pure on Windows 11 Pro 24H2 and I have experienced this malfunction both on the stand alone version of RetroArch and on the one downloaded from Steam.

[schellingb]

Yes, as part of a fix made for #557 which was included in the last version, the behavior of loading .conf file was made to match that of the other DOSBox cores and actual original DOSBox. So what you describe is intended and not a malfunction. Originally, DOSBox Pure was envisioned to be used without .conf files, this only later got added upon requests to be compatible with other DOSBox variants and setups that have been made for these. So just like regular DOSBox, when loading a .conf it will run the commands in the [autoexec] section (and nothing else). People use that to start games directly as opposed to the DOSBox Pure start menu.

If you want something similar to the old behavior back, you can add these commands to the end of your [autoexec] section:

mount C: .
C:
puremenu

(that last line is what starts the DOSBox Pure Start Menu)

Although if you have any CDs you want to mount, you need to also add the respective imgmount commands after the mount command, for example:

imgmount D GAME.ISO -t iso

Alternative of course is to not use a .conf file. You can launch a .EXE or .BAT file as content and it will do the behavior you want of it mounting the folder as C: and presenting the start menu. Also since RetroArch 1.20 you can load a directory directly as content with DOSBox Pure. That will mount it as C: and open the start menu.

[Ric-82]

Okay, thanks for the advice on how to replicate the previous behavior. I'll Try.

As for the fact that RetroArch now allows you to load the entire folder to launch a game, I was aware of that but the purpose of using a .conf file is to launch the game through a unique file, whose name matches that of the databases/scrapers used by frontend like LaunchBox.

Unfortunately, it is not possible to set the frontend in such a way as to induce it to consider an entire folder as if it were a single Rom.

I could certainly zip the game folders in .dosz format, turning them into "roms", but I noticed that some games that don't run natively in DOS but need a Windows environment don't work properly if they are launched this way (it happened to me for example with "Star Trek Voyager: Elite Force". The game starts regularly if I launch it from an unzipped folder, but if I launch it from a zipped folder it can't find all the game files, for some strange reason).

Could you consider implementing the use of a file (with an extension other than .conf to avoid confusion with DosBox) that acts as a placeholder for the frontends, which works similarly to how .conf files have worked so far?

It would be very useful for creating playlists, scraping images and metadata, and of course launching the games themselves.

Also, I recommend that you update the github page of the project, because there is still mentioned the possibility of using a .conf file to automatically mount the related folder as a C drive.

[schellingb]

Could you consider implementing the use of a file (with an extension other than .conf to avoid confusion with DosBox) that acts as a placeholder for the frontends, which works similarly to how .conf files have worked so far?

So are your .conf files that you have used until now just empty? You can almost get that behavior with an empty .BAT file. I was maybe hoping that either that or a .BAT file that just says "puremenu" would get you there but it really wants to show the "Press any key to return to the start menu" message.

As for a custom file type I'm not really sure what kind of extension this could be. No one will be able to guess the usage of such a custom type so I think it might as well be a special .BAT or even a .CONF file that says something special inside of it... Like... automount=true or something. And then that would be documented in the github readme.

it happened to me for example with "Star Trek Voyager: Elite Force". The game starts regularly if I launch it from an unzipped folder, but if I launch it from a zipped folder it can't find all the game files, for some strange reason

This sounds like something we should fix :-) I have tried the Star Trek: Voyager - Elite Force Demo in Windows 98 in DOSBox Pure before without major issues, so I'm not sure what problem you have encountered.

Also, I recommend that you update the github page of the project, because there is still mentioned the possibility of using a .conf file to automatically mount the related folder as a C drive.

Good catch, thanks for reminding me, I completely forgot about that chapter of the readme...

[Ric-82]

So are your .conf files that you have used until now just empty? You can almost get that behavior with an empty .BAT file. I was maybe hoping that either that or a .BAT file that just says "puremenu" would get you there but it really wants to show the "Press any key to return to the start menu" message.

Not exactly.

Basically, I use .conf files with all the relevant instructions when it comes to launching GOG-purchased games via DosBox Pure (because I assume that the settings contained in those configuration files have been calibrated specifically for those games).

Games launched with those .conf files obviously still work with the new version of the core, but now I must explicitly specify the parameters for mounting C and D drives.

Then, for games not purchased on GOG, I use a .conf file with no parameters in it (I assume that the core uses its own settings, in this case) but which contains the launch command.

For example:

[autoexec]
# Lines in this section will be run at startup.
@echo off
c:
alleycat.com
cls
exit

Now this no longer works, because it is no longer implied that the C drive is mounted automatically. So here too I would have to add the MOUNT command to each configuration file.

And finally, for games that require Windows, I use a .conf file with parameters inside it to boost things like RAM and CPU cycles. Any other specific changes for the game I want to launch I make directly from within the operating system, having first activated the 'Save Difference Per Content' option. This way my Windows installation is always the same, but then each game has its own file with every changes made to the registry.

For example:

[dosbox]
# language: Select another language file.
#  machine: The type of machine DOSBox tries to emulate.
#           Possible values: hercules, cga, tandy, pcjr, ega, vgaonly, svga_s3, svga_et3000, svga_et4000, svga_paradise, vesa_nolfb, vesa_oldvbe.
# captures: Directory where things like wave, midi, screenshot get captured.
#  memsize: Amount of memory DOSBox has in megabytes.
#             This value is best left at its default to avoid problems with some games,
#             though few games might require a higher value.
#             There is generally no speed advantage when raising this value.

language=
machine=svga_s3
vmemsize=2
vmemsizekb=12288
memsize=2048
memsizekb=2048

[cpu]
#      core: CPU Core used in emulation. auto will switch to dynamic if available and
#            appropriate.
#            Possible values: auto, dynamic, normal, simple.
#   cputype: CPU Type used in emulation. auto is the fastest choice.
#            Possible values: auto, 386, 386_slow, 486_slow, pentium_slow, 386_prefetch.
#    cycles: Amount of instructions DOSBox tries to emulate each millisecond.
#            Setting this value too high results in sound dropouts and lags.
#            Cycles can be set in 3 ways:
#              'auto'          tries to guess what a game needs.
#                              It usually works, but can fail for certain games.
#              'fixed #number' will set a fixed amount of cycles. This is what you usually
#                              need if 'auto' fails. (Example: fixed 4000).
#              'max'           will allocate as much cycles as your computer is able to
#                              handle.
#            Possible values: auto, fixed, max.
#   cycleup: Amount of cycles to decrease/increase with keycombos.(CTRL-F11/CTRL-F12)
# cycledown: Setting it lower than 100 will be a percentage.

core=auto
cputype=auto
cycles=max

Alas, this last configuration is now useless, because if I have to launch the operating system, I can't mount the folder containing the configuration file as drive C. My Windows image is contained inside the Retroarch "system" folder. Somewhere completely different from the ROM folder.

As for a custom file type I'm not really sure what kind of extension this could be. No one will be able to guess the usage of such a custom type so I think it might as well be a special .BAT or even a .CONF file that says something special inside of it... Like... automount=true or something. And then that would be documented in the github readme.

I've already experienced with a .bat file, even an empty one, and yes: you get more or less the same effect as the old behavior.

And yet there are two problems:

1. I don't know if I can set parameters like machine, vmemsize, core etc. from within the .bat file

2. Even if I renamed .bat files created for this purpose, with names like "Alley Cat (1984).bat" or "Road Rash (1996).bat", if I set RetroArch or Launchbox to scan all files with .bat extension inside a folder, surely - in addition to the files that really interest me for metadata and image scraping - I would find myself with the frontend full of other useless files with the same extension that I would then have to delete from the playlist one by one.

For this reason, I think the ideal would be to have a special extension just for this purpose (like the brilliant .dosz extension, but for uncompressed folders this time).

Or a .conf file with a special command inside of it, as you suggested.

This sounds like something we should fix :-) I have tried the Star Trek: Voyager - Elite Force Demo in Windows 98 in DOSBox Pure before without major issues, so I'm not sure what problem you have encountered.

I should try again to create that strange behavior. If I have time to do so, I will keep you informed.

Another reason why I prefer to keep the game folders uncompressed is because this way, in some cases, I can take advantage of the same installation to launch the game both via RetroArch and via Winlator.

Otherwise, I would have to keep a zipped file for RetroArch and an uncompressed folder for Winlator and the phone's memory would be halved.

I realize, however, that this is such a specific and bizarre usage scenario that it probably only affects me :-D so I understand that it's not worth wasting time ;-)

Good catch, thanks for reminding me, I completely forgot about that chapter of the readme...

You're welcome ;-)

[schellingb]

So commit c571700 added the option to bring back the old behavior if you have the following part in your .conf file:

[dosbox]
automount=true

Can you download the core for your platform from https://github.com/schellingb/dosbox-pure/actions/runs/13790179406 and give it a shot?

[Ric-82]

Hi,

I tested some games with the "Dosbox_pure_win64" version and I have not encountered any issues, so far. The "automount=true" command works perfectly in all the scenarios that I have tested, including games that need a Windows environment and those that require an ISO image. The core behavior appears identical to the previous version. Awesome!

Soon I will test the same games on Android too and I let you know.

In the meantime, thank you very much for everything you do.

EDIT

Ok, I can confirm that having done the same tests on Android with the "dosbox_pure_android_arm64" core, automount works in all scenarios.

Great!

[schellingb]

Great, this is now released in 1.0-preview2 so I'm closing this issue.