wierd_w wrote on 2024-03-28, 15:20:

At least with DA5, it (the launcher) does not close. It remains in memory as a TSR, and initiates programs with a private shell. This allows it to 100% catch program termination, as the program returns to shell, which it traps, and then cleans up for.

The amount of memory is very small, just a few (like, 2 to 5. I'd have to check) kilobytes. Just enough to close the shell, and restart the menu system.

Then the disadvantage lies in the latter. 2 to 5 KiB may be too much. I once had a game that I could barely get to run with all the necessary drivers, including a SCSI driver and MS-DOS 6.2. I had already used tricks like using a different, smaller mouse driver. It may be that I don't even have the driver for a local keyboard layout loaded anymore.

I don't remember exactly which game that was. But it required over 62? Kib free conventional memory. Maybe it was F-15 Strike Eagle 3, but that's just a guess. It was a late game, just before all the games started using DOS extenders like DOS4G/W.

By the way, the suggestion to increase the permitted size of the environment variables so that the PATH variable can be longer becomes quite ugly if you then want to edit the PATH variable in the AUTOEXEC.BAT with EDIT from MS-DOS 6.x to add about 60 game folders.
Although EDIT allows you to read and display files with lines longer than 256 characters, you cannot increase the length of the line in EDIT. Default length is set to 256 characters, thus you can't write and save longer lines. There also doesn't seem to be a line break to be able to pass longer lines to a variable. This is not like C. So if you wanted to attach 60 game folders to a PATH variable, you would have to create a short variable for each game folder and then append it to the PATH variable in order to avoid the problem by substitution. In addition, such a long PATH variable would require about a little less than 2 KiB in size.

Theoretically, you could use another editor without a length limit, but it wouldn't be included by default. Ultimately, it would be very ugly to have such long lines in your AUTOEXEC.BAT anyway, which is why you can't do without substitution anyway.
At best, you could write a text file in which there is a game folder in each line. And a BATCH script then reads this text file line by line and adds each entry to the PATH variable individually. Not only does this take a lot of time when booting, but it still requires the use of a BATCH file or you would have to write a program that does the same task.

Conclusion:
You can increase the length of the PATH variable, but the subsequent difficulties and the additional memory requirements make this a ridiculous idea.

Exploit wrote on 2024-03-28, 14:24:

analog_programmer is now on my ignore list.

You think someone cares? 😀

This thread is literally pointless after chinny22's comment. Learn how to use simple DOS-menu based batch files, all other "solutions" are waste of disk and RAM space.

Exploit wrote on 2024-03-28, 17:15:

By the way, the suggestion to increase the permitted size of the environment variables so that the PATH variable can be longer becomes quite ugly if you then want to edit the PATH variable in the AUTOEXEC.BAT with EDIT from MS-DOS 6.x to add about 60 game folders.
Although EDIT allows you to read and display files with lines longer than 256 characters, you cannot increase the length of the line in EDIT. Default length is set to 256 characters, thus you can't write and save longer lines. There also doesn't seem to be a line break to be able to pass longer lines to a variable. This is not like C. So if you wanted to attach 60 game folders to a PATH variable, you would have to create a short variable for each game folder and then append it to the PATH variable in order to avoid the problem by substitution. In addition, such a long PATH variable would require about a little less than 2 KiB in size.

Theoretically, you could use another editor without a length limit, but it wouldn't be included by default. Ultimately, it would be very ugly to have such long lines in your AUTOEXEC.BAT anyway, which is why you can't do without substitution anyway.

One could do this:

set PATH=c:\dos
set PATH=%PATH%;c:\bin
set PATH=%PATH%;c:\windows

This works in MS-DOS 5 at least. You can't execute set commands that expand a variable like that at the prompt though, it only works in batch files (thanks to whoever pointed this out in a post somewhere).

If you do put just one directory on each line like that example, I think it's more readable than the normal way we write it all on one line.

Still, as pointed out, that could use up a lot of memory!

Also, for what it's worth, I sometimes have a bunch of batch files like this on a machine and that's what I did back in the '80s and '90s, but lately I've also used DougMenu a bit (do a Google search "site:cd.textfiles.com dmenu" if you want to find it). I think it's licensed pretty liberally - freeware I think - and at one point the source code was released, but it's not really open source because the license didn't permit distributing your changes.

If we are intent on using a batch file, I am more apt to have a structured single batch, with some variables used and populated.

Take for instance, something along the lines of

SET CommonDrive=C
SET CommonPath=Games

then having game specific variables get populated and used, based on what the user picks. For example, if the user has selected warcraft 2, then do something like this:

:Warcraft2:
SET ExecPath=Warcraft2
SET ExecFile=War2.exe

then call a universal execution function

:DO_EXECUTE:
%CommonDrive%:
CD %CommonPath%
CD %ExecPath%
%ExecFile%

This would facilitate very easy correction in the case of moving the common installed location to just 2 lines, and keep general path/variable needs minimal.

The PROBLEM, is that some games/programs break batch execution, as stated, and wont do any cleanup routines you might specify, such as unmounting .iso files, or flushing drive caches.

wierd_w wrote on 2024-03-29, 08:53:

then having game specific variables get populated and used, based on what the user picks.

How does the picking part work? Using the CHOICE command, which was only introduced in MS-DOS 6? Accepting a command-line parameter, which means you have to type more? Or something nicer? Sorry if I missed something earlier in the thread.

The way I had stuff set up in under MS-DOS 5 was I had a menu file that was TYPEd - initially plain text, later it had ANSI codes - which would say things like:

1. F-19 Stealth Fighter
2. DOOM

and then batch files called 1.BAT, 2.BAT, etc., so not much typing was required.

The PROBLEM, is that some games/programs break batch execution, as stated, and wont do any cleanup routines you might specify, such as unmounting .iso files, or flushing drive caches.

I'm not sure I've ever noticed anything like that, but I probably didn't have cleanup to do. I'd be interested to learn what games do that and how/why! Recently I ran across an IBM terminal emulation program that let you "switch" to a DOS session while it was running which actually caused it to TSR, and at that point the batch file you used to start the program would resume execution seemingly inside the program it started, but I can't imagine games doing anything that weird. I certainly remember some games that seemed to clobber some of COMMAND.COM's memory and when you exited the system would hang, so maybe if you were lucky they'd clobber its memory in a way that you could still get a prompt but it wouldn't resume running your batch file?

Set /P SomeVariable=any input

As discussed here.

https://www.dostips.com/forum/viewtopic.php?t=2160

doshea wrote on 2024-03-29, 07:48:

One could do this: set PATH=c:\dos set PATH=%PATH%;c:\bin set PATH=%PATH%;c:\windows This works in MS-DOS 5 at least. You can […]
Show full quote

One could do this:

set PATH=c:\dos
set PATH=%PATH%;c:\bin
set PATH=%PATH%;c:\windows

This works in MS-DOS 5 at least. You can't execute set commands that expand a variable like that at the prompt though, it only works in batch files (thanks to whoever pointed this out in a post somewhere).

That's what i meant with:

Exploit wrote on 2024-03-28, 17:15:

So if you wanted to attach 60 game folders to a PATH variable, you would have to create a short variable for each game folder and then append it to the PATH variable in order to avoid the problem by substitution.

doshea wrote on 2024-03-29, 07:48:

If you do put just one directory on each line like that example, I think it's more readable than the normal way we write it all on one line.

Still, as pointed out, that could use up a lot of memory!

Yes, and that's the problem.

doshea wrote on 2024-03-29, 11:08:

wierd_w wrote on 2024-03-29, 08:53:

then having game specific variables get populated and used, based on what the user picks.

How does the picking part work? Using the CHOICE command, which was only introduced in MS-DOS 6? Accepting a command-line parameter, which means you have to type more? Or something nicer? Sorry if I missed something earlier in the thread.

You could use GOTO as workaround and thus something like the folloing. The GOTO workaround also works in very early DOS Versions, like 3.3.

1@ECHO BEGIN
2IF %1==wc2 GOTO wc2
3IF %1==war2 GOTO warcraft2
4GOTO ENDB
5
6:wc2
7REM Commands to start wc2
8...
9GOTO ENDB
10
11:warcraft2
12REM Commands to start warcraft2 
13....
14GOTO ENDB
15
16:ENDB

I didn't find a solution for if %1 is empty. I tried

1IF %1== GOTO ENDB
2REM and
3IF %1=="" GOTO ENDB
4REM and
5IF NOT %1 GOTO ENDB

But somehow i got syntax errors in all variants.

BTW, if you need to check for the existence of an executable you can use:

1IF EXIST C:\GAME\WC2\WC2.EXE GOTO SOMEWHERE
2GOTO ENDB
3:SOMEWHERE
4
5:ENDB

I use the IF EXIST command to check for the type of DOS system.
For example DR-DOS does have different executables than MS-DOS so you can use something like the following. This solution does also work for very early DR-DOS and MS-DOS versions. For example DR-DOS 3.41. The BATCH interpreter of early DOS versions is not very powerful.

1@ECHO OFF
2C:
3REM SID86.EXE is DR-DOS's Debugger. Later versions call it only SID.EXE. And Novel DOS changed it to DEBUG.EXE, so you need adapt it for your version. You can also check for  another command like XDEL.COM for example to achieve the same.
4IF EXIST C:\DRDOS\SID86.EXE GOTO DRDOS
5IF EXIST C:\FREEDOS\VERSION.FDI GOTO FREEDOS
6IF EXIST C:\DOS\MORE.COM GOTO MSDOS
7GOTO ENDB
8
9:DRDOS
10CD C:\DRDOS
11GOTO ENDB
12
13:FREEDOS
14CD C:\FREEDOS\BIN
15GOTO ENDB
16
17:MSDOS
18CD C:\DOS
19
20:ENDB

If you need a more powerful BATCH system, you could of course write your own IF evaluation program, name it different and then call it with parameters in the BATCH file.
For example, sth. like this:

1C:\bin\MYIF.EXE  %value1%  %operator%  %value2%

You can also use BATCH files to use your favorite EDITOR. The %1 %2 etc. variables can be used to run your editor with the parameters you want. For example, the text file you want to open.

1@ECHO OFF
2IF EXIST C:\APPS\FED\FED.EXE GOTO FED
3GOTO ENDB
4
5:FED
6C:
7C:\APPS\FED\FED.EXE %1 %2 %3
8GOTO ENDB
9
10:ENDB

If you save it as MYED.BAT you could call it with something like this from anywhere:

1myed.bat textfile.txt

And then it will run your EDITOR and open the file textfile.txt

The PROBLEM, is that some games/programs break batch execution, as stated, and wont do any cleanup routines you might specify, such as unmounting .iso files, or flushing drive caches.

I'm not sure I've ever noticed anything like that, but I probably didn't have cleanup to do. I'd be interested to learn what games do that and how/why!

I agree on that.

Any issue is some game need specific memory manager loaded, or some don't work with them at all.

It might make sense to have several variations of config.sys and autoexec.bat, and your launching of a game would overwrite the config.sys and autoexec.bat, as well as copying a custom game.bat or whatever you call it out of the game's path and force a reboot.

The correct environment could then be loaded without additional prompting, along with replacing config.sys and autoexec.bat with the original menu versions before launching the game.

Something along these lines was used in the MiSTer AO486 game packs, there was a C: drive mountable image, with different D: drive images with the games. MiSTer had a custom executable that could flip various hardware settings like CPU speed and caches beyond what is possible on real hardware. So the game.bat files would auto configure the hardware to what was needed.

This has gone away with the latest packs which have individual HDD images you'd load instead per game that have all the configuration there. So you select games to play from a system menu, rather than a DOS menu.

I can look in my archives of dos games for examples I suppose...

It would have to wait for after the weekend though. I just know I have encountered them, and been angered.

I remember being angry, not what specific program caused the anger.

wierd_w wrote on 2024-03-29, 11:35:

Set /P SomeVariable=any input

Does DOS actually support this, or just Win32 CMD.EXE?

I tried running "HELP SET" under MS-DOS 6.22, but on this particular VM I have 4DOS installed so learned that the /P parameter to SET means "pause" in 4DOS, like the /P parameter to DIR 😁

Okay, let's try that properly:

"C:\DOS\HELP SET" reveals that COMMAND.COM doesn't have a /P flag. I tried anyway and "SET /P FOO=BAR" creates a variable whose name is "/P FOO"!

I tried booting Windows 98 SE into "Command prompt only" from the start menu and got the same behaviour.

I wish there was a reference online to all these commands from DOS which indicated when the command itself and various parameters were introduced, I often find myself having to look this stuff up!

Exploit wrote on 2024-03-29, 16:26:

You could use GOTO as workaround and thus something like the folloing. The GOTO workaround also works in very early DOS Versions, like 3.3.

I'm not a fan of this, since as I said it's more typing to run this - instead of just "WC2" you need to type "GO WC2" or something - but yes, it does have the benefit that all the code is in one place!

Now I think of it, back when I had all those 1.BAT, 2.BAT, etc. files I didn't know how to touch type, and now I do and don't mind having to type long commands 😁

I didn't find a solution for if %1 is empty. I tried […]
Show full quote

I didn't find a solution for if %1 is empty. I tried

Copy code to clipboard

1IF %1== GOTO ENDB
2REM and
3IF %1=="" GOTO ENDB
4REM and
5IF NOT %1 GOTO ENDB

But somehow i got syntax errors in all variants.

My recollection is that you need to put quotes on both sides of the equality operator, e.g.:

1IF "%1"=="" GOTO ENDB

and maybe this works too:

1IF (%1)==() GOTO ENDB

I think the problem is that COMMAND.COM isn't doing the kind of multiple pass parsing including word splitting that a modern shell would, so if %1 is empty and you don't have quotes around it on the left-hand side of the equality operator (==), in your code it ends up with nothing on the left hand side of the equality operator and it doesn't like that. I think the reason what I have provided above works is that it prevents there ever being nothing at all on either side of the equality operator, and if %1 is empty, what you get on the left hand side is just two double quotes, which is exactly what is on the right-hand side. Much dumber than a modern shell which uses quotes to delimit words/parameters!

If you need a more powerful BATCH system, you could of course write your own IF evaluation program, name it different and then call it with parameters in the BATCH file.

I think there are probably a lot of programs like that out there. I think Norton Utilities's "Batch Enhancer" might be one, PC Magazine's DOS Power Tools book probably had at least one, and I imagine there would be lots of shareware ones.

Edit: something else I remembered: I think if you do have a lot of directories in your PATH, then whenever you run a command which is in the last directory, DOS has to scan every directory before it for the command first, which can be slow. I seem to remember there being advice in magazines against long PATHs for that reason - everyone had slow hard drives and probably not much RAM for a disk cache - if they even had a cache - and that scan could take a relatively long time. Modern *nix shells cache the results of scanning the PATH but I doubt that COMMAND.COM would have ever done something like that due to the possible need for unbounded amounts of RAM. Just another reason to not put too many things on your PATH!

SScorpio wrote on 2024-03-29, 16:47:

Any issue is some game need specific memory manager loaded, or some don't work with them at all.

Things like this need to be solved with a boot menu. I had a boot menu with about 5-6 entries where I could cover all cases (with and without XMS, EMS, CD-ROM, Win3.1, etc.).

doshea wrote on 2024-03-30, 01:30:

I wish there was a reference online to all these commands from DOS which indicated when the command itself and various parameters were introduced, I often find myself having to look this stuff up!

I agree, such a reference would be very helpful.

doshea wrote on 2024-03-30, 01:43:

My recollection is that you need to put quotes on both sides of the equality operator, e.g.: […]
Show full quote

My recollection is that you need to put quotes on both sides of the equality operator, e.g.:

Copy code to clipboard

1IF "%1"=="" GOTO ENDB

Thank you. This worked. The other didn't.

I think the problem is that COMMAND.COM isn't doing the kind of multiple pass parsing including word splitting that a modern shell would, so if %1 is empty and you don't have quotes around it on the left-hand side of the equality operator (==), in your code it ends up with nothing on the left hand side of the equality operator and it doesn't like that. I think the reason what I have provided above works is that it prevents there ever being nothing at all on either side of the equality operator, and if %1 is empty, what you get on the left hand side is just two double quotes, which is exactly what is on the right-hand side. Much dumber than a modern shell which uses quotes to delimit words/parameters!

That might be a useful explanation.

BTW, the internal DOS help for

1help if

does only say:

1string1==string2
2  Specifies a true condition only if string1 and string2 are the same.
3  These values can be literal strings or batch variables (%1, for
4  example). Literal strings do not need quotation marks.

I somehow missed the last sentence. It ultimately means that variables need quotation marks.

If you need a more powerful BATCH system, you could of course write your own IF evaluation program, name it different and then call it with parameters in the BATCH file.

I think there are probably a lot of programs like that out there. I think Norton Utilities's "Batch Enhancer" might be one, PC Magazine's DOS Power Tools book probably had at least one, and I imagine there would be lots of shareware ones.

I agree.

Edit: something else I remembered: I think if you do have a lot of directories in your PATH, then whenever you run a command which is in the last directory, DOS has to scan every directory before it for the command first, which can be slow. I seem to remember there being advice in magazines against long PATHs for that reason - everyone had slow hard drives and probably not much RAM for a disk cache - if they even had a cache - and that scan could take a relatively long time. Modern *nix shells cache the results of scanning the PATH but I doubt that COMMAND.COM would have ever done something like that due to the possible need for unbounded amounts of RAM. Just another reason to not put too many things on your PATH!

You're right, it also slows down the evaluation. Another reason not to use this ridiculous PATH only solution suggested by a user on my ignore list.

Exploit wrote on 2024-03-30, 03:01:

Things like this need to be solved with a boot menu. I had a boot menu with about 5-6 entries where I could cover all cases (with and without XMS, EMS, CD-ROM, Win3.1, etc.).

The problem with a boot menu is that you're forced to make a choice on start, and you could pick a game that will require you to reboot and make a different choice to then be able to run it. If you're happy with that it's fine, but you can automate it further.

Have multiple autoexec.bat and config.sys files including a very paired down version that boots you quickly into the selection menu.

Examples.
autoexec.xms config.xms
autoexec.ems config.ems
etc

Have a config.bat in each game directory that replaces the necessary boot configuration. As well as a rungame.bat (or whatever you name it) that will execute the game.
copy c:\launch\autoexec.ems c:\autoexec.bat
copy c:\launch\config.ems c:\config.sys
copy x:\gamepath\rungame.bat c:\rungame.bat
trigger a reboot (search github for reboot.com or use whatever you want)

The last steps of each autoexec file could replace the configuration files back to the base quick booting. And then run the game.
copy c:\launch\autoexec.1 c:\autoexec.bat
copy c:\launch\config.1 c:\config.sys
c:\rungame.bat

With this setup, your menu would just need to have the path where any game is and it will just execute the the config.bat in that directory and all of the configuration could happen. The rungame.bat file could all make calls to programs that adjust the CPU speed if needed, in my experience I couldn't turn the level 2 motherboard cache on/off, but the programs can adjust cpu cache and other settings depending on the processor you are using.

SScorpio wrote on 2024-03-30, 14:29:

Exploit wrote on 2024-03-30, 03:01:

Things like this need to be solved with a boot menu. I had a boot menu with about 5-6 entries where I could cover all cases (with and without XMS, EMS, CD-ROM, Win3.1, etc.).

The problem with a boot menu is that you're forced to make a choice on start, and you could pick a game that will require you to reboot and make a different choice to then be able to run it. If you're happy with that it's fine, but you can automate it further.

You can theoretically automate it, like you described, but it's not a good idea, because of the following reasons:

1. Sometimes a user might think "Oh, I have to reboot for this game, this takes to much time now. I don't feel like doing that now. I'd rather play something else instead."
In such a case, it is better to give the user the choice to change their mind if the configured and currently loaded memory configuration does not suit the game.
For this reason, after running the batch file, it is better to simply inform the user that the game requires a specific memory configuration and exit if the memory configuration does not fit. The easiest way to test a specific memory configuration is to create an environment variable in AUTOEXEC.BAT that persists in memory and then test it.

2. In addition the other reason against such automation is flash memory. Some users of old computers now use modern flash memory as a hard drive replacement and the flash memory will not like this if you regularly change the AUTOEXEC.BAT and CONFIG.SYS files and file allocation table because that can mean too many writes to the same memory cells.

3. If you do not want to reboot the computer each time after running the corresponding batch file for a game, you must check anyway with the batch script which memory setting was loaded before rebooting and starting the game.

4. After booting, you must be able to distinguish whether a specific game should be started or the computer was booted normally. Otherwise the computer doesn't know which game should be started after booting and whether one should be started at all.
This could certainly be solved with an environment variable in the Autoexec.bat, a game-specific Autoexec.bat file that then starts the game directly, or a separate batch file to be started at the end, but in both first cases the Autoexec.bat would have to be game-specific and in the latter case the extra batch file to be started. So it wouldn't be enough to copy a handful of preconfigured Autoexec.bat files to C:\ and overwrite the old one, but you would need a separate one for each game or at least change the entry that specifies the environment variable of the game to be started . Or, if you use the third variant with the extra batch file, this would have to be changed.

5. If your game crashes, the game will boot again immediately after restarting.

For all of these reasons, I wouldn't recommend this.
Most of the time, users know roughly what game they want to launch when they turn on their computer and then select the correct memory configuration that the game requires from the 5-6 available configurations in the boot menu and then launch the game's corresponding batch file manually. At least that's how I used to do it.

Have multiple autoexec.bat and config.sys files including a very paired down version that boots you quickly into the selection m […]
Show full quote

Have multiple autoexec.bat and config.sys files including a very paired down version that boots you quickly into the selection menu.

Examples.
autoexec.xms config.xms
autoexec.ems config.ems
etc

That's not enough. See point 4 above.

Have a config.bat in each game directory that replaces the necessary boot configuration.

Configuration data does not belong in the program's directory. For backup reasons, it's better to have a special directory for such a data. In this way, you can delete your game directory, apart from the saved games, game profiles and high score lists, which of course have to be backed up, without having to worry about forgetting something.

The rungame.bat file could all make calls to programs that adjust the CPU speed if needed,

Since there is a batch file for each game, you can also start programs like slowdown in it before the game starts. Of course, this doesn't work with the ridiculous PATH only solution.

Exploit wrote on 2024-03-30, 22:19:

You can theoretically automate it, like you described, but it's not a good idea, because of the following reasons: […]
Show full quote

You can theoretically automate it, like you described, but it's not a good idea, because of the following reasons:

1. Sometimes a user might think "Oh, I have to reboot for this game, this takes to much time now. I don't feel like doing that now. I'd rather play something else instead."
In such a case, it is better to give the user the choice to change their mind if the configured and currently loaded memory configuration does not suit the game.
For this reason, after running the batch file, it is better to simply inform the user that the game requires a specific memory configuration and exit if the memory configuration does not fit. The easiest way to test a specific memory configuration is to create an environment variable in AUTOEXEC.BAT that persists in memory and then test it.

2. In addition the other reason against such automation is flash memory. Some users of old computers now use modern flash memory as a hard drive replacement and the flash memory will not like this if you regularly change the AUTOEXEC.BAT and CONFIG.SYS files and file allocation table because that can mean too many writes to the same memory cells.

3. If you do not want to reboot the computer each time after running the corresponding batch file for a game, you must check anyway with the batch script which memory setting was loaded before rebooting and starting the game.

4. After booting, you must be able to distinguish whether a specific game should be started or the computer was booted normally. Otherwise the computer doesn't know which game should be started after booting and whether one should be started at all.
This could certainly be solved with an environment variable in the Autoexec.bat, a game-specific Autoexec.bat file that then starts the game directly, or a separate batch file to be started at the end, but in both first cases the Autoexec.bat would have to be game-specific and in the latter case the extra batch file to be started. So it wouldn't be enough to copy a handful of preconfigured Autoexec.bat files to C:\ and overwrite the old one, but you would need a separate one for each game or at least change the entry that specifies the environment variable of the game to be started . Or, if you use the third variant with the extra batch file, this would have to be changed.

5. If your game crashes, the game will boot again immediately after restarting.

For all of these reasons, I wouldn't recommend this.
Most of the time, users know roughly what game they want to launch when they turn on their computer and then select the correct memory configuration that the game requires from the 5-6 available configurations in the boot menu and then launch the game's corresponding batch file manually. At least that's how I used to do it.

1. How long does DOS take to boot for you? I'm see 5-10 seconds tops, and depending on the needed configuration, a user would need to reboot anyways to go into the correct environment.

2. If you use anything modern it should have automated wear leveling, just saving a game while playing could lead to more writes. Your looking at hundreds to a few thousand rewrites of those files. It's not like swap memory rewriting millions of times an hour.

3. You can implement it that way, my idea was just something less complex and faster loading the first time.

4+5. You don't need to monitor the game. I said that before running the actual game, revert back to your main menu autoexec.bat and config.sys. Then next boot of the PC will go back to the original menu. You could have it force a reboot of the PC after game exit, but I'd recommend against it as you might run into issues that are difficult to troubleshoot. Better to just exit to DOS prompt. The regular autoexec.bat would just call the rungame.bat file that custom to each game. Then you can have more generic autoexec.bat files for each configuration, and anything specific is just handled per game. So if you wanted to say use a different mouse drive with a smaller footprint. You just need to edit a few files rather than files for each individual game.

Exploit wrote on 2024-03-30, 22:19:

The easiest way to test a specific memory configuration is to create an environment variable in AUTOEXEC.BAT that persists in memory and then test it.

I'm sure you know this, but for anyone reading who might not: the CONFIG environment variable is set to the menu item name in CONFIG.SYS when you use a [menu], and you can check that variable in AUTOEXEC.BAT (often by doing a "GOTO %CONFIG%") but you could also check it later.

It might still be better to define separate variable(s) in AUTOEXEC.BAT to check later though, in case for example you have a game that requires EMS and you have more than one configuration that provides EMS so you don't have to tie that game to just one of the EMS-providing configurations. Checking the properties of the configuration in that way rather than checking its identity/name is a good rule of thumb for programming to limit how much you need to change when you add a new configuration.