Wengier
commented
2 years ago This is certainly not a bad suggestion, but it does require quite some work to implement since it requires changes not only to the main config file parsing code, but also to e.g. the CONFIG command, the Configuration Tool, the Windows installer, and so on. For example, when you used layered config files and made some changes and want to write back to the configuration via CONFIG command or Configuration Tool, will they write to a single config file, or also layered ones? If they write to a single config file, then the layered structure will no longer exists; on the other hand, if you want them to also write to layered config files, then how to determine which config file each config option will be written to? Apparently, some important decisions have to be made before any attempts to implement such a structure.
For the environment variables, the %BLASTER% variable is a standard environment variable in DOS with a Sound Blaster card. On the other hand, I don't think %CPU% variable is a standard DOS environment variable. However, you can manually set environment variables in [config] or [autoexec] section, which will then be seen inside the DOS emulation.
As for the Z drive, you can currently add your own files by putting them in the drivez directory of the DOSBox-X program folder.
joncampbell123
runarorested
Code of Conduct & Contributing Guidelines
Have you checked that no other similar feature request(s) already exists?
Is your feature request related to a problem? Please describe.
I like to execute old games and programs (old dos programming enviroments, old custom applications, etc), usually creating icons pointing to self contained folders with the matching config of said machine, in a similar way to the ones that GOG installer creates.
Specially in games because of the hardware support, sometimes I've multiple config files, depending of launching a basic vga+pc speaker setup, a "retro" ega/cga version, or an more advanced "supervga+soundcard" version. That ends being quite bothersome with lots of base set-ups duplicated many times, in every program, and lots of problems when updating dosbox(-x) itself.
What you want
I would like to request a way to use an include macro to call other config files. That would help splitting/reusing the config files a lot easier. While I do understand that keeping monolithic config files is good for debugging purposes, merely adding a command to dump/export/log the full file, includes already applied and duplicated/overwroten variables removed would generate an equivalent file to submit reports.
The idea would be to create a 3/4 layer config files. When launching dosbox with a targeted config file, said config file would:
1st layer: Hardware set up
2nd layer: Base emulation set up
A common emulated machines config files.
A common scriptlets config files to modify/add certain features, depending of the program, in a generic way:
3rd layer: Custom emulation set up
4th layer: Drivers redistributable files
This would simplify per-machine config files from a 20kb full config file to something similar to this:
`$include "%commonconfs%/system.conf" # System config.Sets the output to your second monitor in full screen with the right scalers. # Elvira, Mistress of the dark $include "%commonconfs%/clone286.conf" # Basic machine # scriptlets for required hardware support $include "%commonconfs%/vga-pure.conf" $include "%commonconfs%/mouse-ps2.conf" $include "%commonconfs%/mt-32.conf" $include "%commonconfs%/gog_drive.conf" $include "%commonconfs%/gog_cloud_saves.conf"
[autoexec] mount c %gog_drive% cd elvira1 elvira.exe Z:\DOS\shutdown.exe `
`$include "%commonconfs%/system.conf" # System config.Sets the output to your second monitor in full screen with the right scalers. # Wordperfect 6.0 $include "%commonconfs%/clone286.conf" # Basic machine # scriptlets for required hardware support $include "%commonconfs%/svga-vesa12.conf" $include "%commonconfs%/text-ttf.conf" $include "%commonconfs%/mouse-ps2.conf" $include "%commonconfs%/lpt1_passthru.conf"
[ttf] font=./font/retro-ega.ttf fontbold=./font/retro-ega-bold.ttf
[autoexec] mount c ".\wordperfect-6.0\installation" share.exe c: cls ver `
`$include "%commonconfs%/system.conf" # System config.Sets the output to your second monitor in full screen with the right scalers. # Flight simulator 5 $include "%commonconfs%/clone486.conf" # Basic machine # scriptlets for required hardware support $include "%commonconfs%/svga-vesa12.conf" $include "%commonconfs%/mouse-ps2.conf"
[autoexec] mount c ".\msfs\5" c: fs.exe `
`$include "%commonconfs%/system.conf" # System config.Sets the output to your second monitor in full screen with the right scalers. # Doom2 $include "%commonconfs%/clone486.conf" # Basic machine # scriptlets for required hardware support $include "%commonconfs%/svga-vesa2.conf" $include "%commonconfs%/mouse-ps2.conf" $include "%commonconfs%/soundblaster-pro.conf"
[autoexec] mount c ".\doom" c: cd doom1 doom.exe ` As you can see, far shorter and easier to understand.
Describe alternatives you've considered
I've already been using a handmade script that would concatenate several text files to generate a dosbox.conf before launching it, but it is not ideal. And while solutions with custom launchers exist, to be really useful, it should be usable without extra software.
Additional context
As a complement it would be nice to be able to set enviroment variables inside the emulated machine from the config file, so batch files inside could use them to enable features depending of having emulated hardware support set-up. Like the %Blaster% variable is set up if sound-blaster emulation is enabled, but for other things: %CPU%=protected if running with protected mode memory managers are set up or not (so i can load tp.exe or tpx.exe in turbo-pascal depending of it), %GUS%=C:\ULTRASOUND\ if Gravis ultrasound is enabled.