If you use the DOS boot menu feature, you can have sections in your config.sys, e.g. if you have:

menuitem=xmsonly, DOS with XMS memory only

you can create a section in config.sys like:

[xmsonly]
device=c:\dos\himem.sys

Other sections are not executed then. Exception is [common], which is always executed.

I know this, but its not help with some Autoexec / Config synchro or with some input variable behavior.

Lets imagine that you would like to use same branch once with cd rom driver and second time without it, make new branch for every combination means in zillion of branches, with working if or enableCdrom True/False variable in header or transfered variable from autoexec would be much better solution.. without zillion of branches.

I already have too much branches problem (max is 9), yes i add branches in branches.. yes can rem them temporarily, but both are a bit cumbersome solutions.

Reading your project thread, this:

"a) First 2 are Windows 98 boot and Windows 98 safe mode boot,"

already shows that your fundamental design is way off. Setting bootmenu=1 in msdos.sys already gives you those options incl. additional ones like real-mode DOS before even config.sys and autoexec.bat are executed. Anyway, what you want is not possible. Config.sys is parsed first and can not react on anything that happens later. What you can do is to write a program that does all the asking and then creates config.sys / autoexec.bat based on that and reboots.

Why would you need so many branches?

I think he's working on an "ultimate boot disk" that will be compatible with every single configuration out there. 😀 Kinda like Hiren's and similar solutions; of course, Hiren's is for apps, not games, so it does not bother with custom sound card drivers and memory managers, which is where things start getting super-complicated.

Regarding what you're asking - as was said, it's not really possible. Use proper Config.sys menus instead. If you are running out of room, use Sub-menus:
http://www.easydos.com/submenu.html

Lets imagine that you would like to use same branch once with cd rom driver and second time without it, make new branch for every combination means in zillion of branches, with working if or enableCdrom True/False variable in header or transfered variable from autoexec would be much better solution.. without zillion of branches.

That can be solved rather easily, since you can assign stuff to multiple branches, e.g.

[xmscdrom]
[emscdrom]
[whatever...]
device=cdrom.sys [...]

I dont think that ask for If support is not too much.

So no solution here yet, i hope that someone will write something for that in future, i saw bigger barriers which were broken..

From my experience response that you dont need that, is always bad.. who would need personal computer, mice etc.. what nonsenses.. 🙁

derSammler wrote:

[xmscdrom] [emscdrom] [whatever...] device=cdrom.sys [...] […]
Show full quote

[xmscdrom]
[emscdrom]
[whatever...]
device=cdrom.sys [...]

Im sure if i understand this. If you mean this that block/module can be used, its once again the same. = Too many blocks.. if would be much better solution (logic inside blocks and more universal block, less spaghetti code). In general block of code which has more that node simple use which catn define by itself some conditions or use condition as input, is bad one...

ruthan wrote:

i hope that someone will write something for that in future

Your best bet is FreeDOS then, as that is open-source and one could easily add such a feature. However, it won't fix your fundamental design flaws like wanting to have if-branches in config.sys that depend on what the autoexec.bat does. That's simply not possible.

If you mean this that block/module can be used, its once again the same. = Too many blocks..

My memory could play tricks on me here. Might be that I was confusing that with what is possible in autoexec.bat.

ruthan wrote:

So no solution here yet, i hope that someone will write something for that in future, i saw bigger barriers which were broken..

Config.sys parsing, however, is a core feature of the OS. You're basically asking someone to add a feature to DOS.

You may check FreeDOS and similar alternatives. They have more features and possibly something along the lines of what you are looking for. But then you are no longer backwards compatible.

ruthan wrote:

From my experience response that you dont need that, is always bad.. who would need personal computer, mice etc.. what nonsenses.. 🙁

It's not always bad. There are often "best practices" and sometimes it's good to remind folks that they exist, when they steer too far away from them. Not saying that this applies or doesn't apply to this particular case, it's just a general remark.

One option would be to automatically assemble CONFIG.SYS and AUTOEXEC.BAT files using known good snippets. It could probably be done with a batch file and menu extension.
http://www.horstmuc.de/ui.htm

The user just picks and chooses according to what they have for hardware.

dr_st wrote:

Config.sys parsing, however, is a core feature of the OS. You're basically asking someone to add a feature to DOS.

Its could be some already undocumented feature which is not known too much people, there still could be some loop hole.. otherwise yeah we would need add feature to Dos.

dr_st wrote:

ruthan wrote:

From my experience response that you dont need that, is always bad.. who would need personal computer, mice etc.. what nonsenses.. 🙁

It's not always bad. There are often "best practices" and sometimes it's good to remind folks that they exist, when they steer too far away from them. Not saying that this applies or doesn't apply to this particular case, it's just a general remark.

Best practices.. i would say that best practice is try to maximize product use possibilities even outside you visions of its inventor. and if we would no try steer too far away we would be probably still life in the caves.

gdjacobs wrote:

One option would be to automatically assemble CONFIG.SYS and AUTOEXEC.BAT files using known good snippets. It could probably be done with a batch file and menu extension.
http://www.horstmuc.de/ui.htm

If i understand it correctly, this could no bypass that config.sys is executed first.. because as utils could be used only from autoexec (too late)..

ruthan wrote:

Its could be some already undocumented feature which is not known too much people, there still could be some loop hole.. otherwise yeah we would need add feature to Dos.

Well, if you find it, let us know. Otherwise feel free to add it yourself and share. 😀

ruthan wrote:

Best practices.. i would say that best practice is try to maximize product use possibilities even outside you visions of its inventor. and if we would no try steer too far away we would be probably still life in the caves.

Best practices are not about stifling innovation. Innovation and invention is good. Best practices areabout not spending excessive resources when a simpler solution exists.

ruthan wrote:

If i understand it correctly, this could no bypass that config.sys is executed first.. because as utils could be used only from autoexec (too late)..

I don't think you understand correctly what gdjacobs suggested.
He suggested that you can create a Config.sys/Autoexec.bat maker that would assemble startup files from good snippets for the NEXT boot, not for the actual one. So instead of one monster Config.sys/Autoexec.bat the user could select on a user interface what snippets he really wants and he would get a a much simpler Config.sys/Autoexec.bat pair. At the end of the process you can ask the user if he wants to replace the original startup files with the new ones (so they can be active at the next boot). Gdjacobs only suggested that this kind of maker can be done even with the help of some menus+batch files but of course a program like this maybe more easily can be written in Basic/Pascal/C if you have the skills.

As far we talk about DOS always autoexec.bat depends on config.sys and never the other way around, just accept it.
To emulate the behavior you want you actually have to restart the whole boot process with the help of e.g. GRUB4DOS. With it you can actually start even a Windows 10 from an autoexec.bat if you want. But for your purposes you can make small DOS images with prepared Config.sys/Autoexec.bat pairs and start them like this from autoexec.bat:

1IF %CONFIG%==Memtest c:\grub.exe --config-file="map --mem (hd0,0)/memtest.img (fd0); map --hook; chainloader (fd0)+1; rootnoverify (fd0); map --floppies=1; boot"
2IF %CONFIG%==KolibriOS c:\grub.exe --config-file="map --mem (hd0,0)/kolibri.img (fd0); map --hook; chainloader (fd0)+1; rootnoverify (fd0); map --floppies=1; boot"

Needless to say I think it's overkill for your scenario and the startup file maker is a better idea.

Falcosoft wrote:

I don't think you understand correctly what gdjacobs suggested.

Yeah you are right, he didnt add too much explanation i suspected something more complex.. Im not familiar with this - assemble startup files from good snippet So i understand it correctly it means just some Dos user friedly setup like text wizard, which would be connected with some code and result would be generated config files for next boot?

Grub:
Im familiar with Grub, but i always used Linux version. Would it mean, that i would have migrate all other OS executions to Grub4dos, it this could be done in Linux version too? If im not wrong this is Grub1 code (menu.1st), not Grub2 (grub.cfg), i would prefer Grub2 one i would have possibility of choice.
If i understand it correctly this solution would need Grub code in MBR, i twould be maybe good for my personally, but would be hard to distribute for other people.

Quick hack:
In present situation would be probably best solution just hack menu items wizard and change max menu items from 9 (its using only half of screen) to bigger value, in theory it could be just one variable. Its not what originally wanted, but its improvement too. At the moment im not even familiar in which file would be such variable saved and how dos startup sequence (which files are initialized during boot.,) is working..

Or other idea:
create some 1 more layer around *.sys files - so in config would be called some enhanced (optimal for user logic) *.sys - which would in proces check some configuration file (or cmd line variables, whatever.. if *.sys during start has read text file possibility.. there is not reason, not read even autoexec or config.. some additional config file wouldnt be necessary ) and after it depends on input values it would just executed or not executed target *.sys - because this is really only thing for what i need those ifs.. Its something like that possible? I never tried to create *.sys , even when i was coding in DOS (last time i was 14 years old and tried to make some own vesa 1.X 2D game engine).

More ideas:

* There are tools that allow loading device drivers (.sys) from the command line and hence also from autoexec.bat, where branching is not an issue. Not all .sys files can be loaded this way, but many can.

* Most device drivers won't do anything bad if you load them without the hardware being present. They will simply tell you that the hardware wasn't found and that the driver was not installed. So instead of doing over-complicated branching, just put all device drivers under [common] and let them always load. If the hardware is present, they will load and install, if not, then not.

ruthan wrote:

In present situation would be probably best solution just hack menu items wizard and change max menu items from 9 (its using only half of screen) to bigger value, in theory it could be just one variable. Its not what originally wanted, but its improvement too. At the moment im not even familiar in which file would be such variable saved and how dos startup sequence (which files are initialized during boot.,) is working..

ruthan wrote:

create some 1 more layer around *.sys files - so in config would be called some enhanced (optimal for user logic) *.sys - which would in proces check some configuration file (or cmd line variables, whatever.. if *.sys during start has read text file possibility.. there is not reason, not read even autoexec or config.. some additional config file wouldnt be necessary ) and after it depends on input values it would just executed or not executed target *.sys - because this is really only thing for what i need those ifs.. Its something like that possible? I never tried to create *.sys , even when i was coding in DOS (last time i was 14 years old and tried to make some own vesa 1.X 2D game engine).

Now you are just going into realms of utter ridiculousness. A bit pretentious for someone, who by his own admission, does not really understand how software works, not to mention writing it or hacking it. And all this to solve a "problem" which is not a real problem, and for which working solutions exist (submenus).

derSammler wrote:

* There are tools that allow loading device drivers (.sys) from the command line and hence also from autoexec.bat, where branching is not an issue. Not all .sys files can be loaded this way, but many can.

This is probably the best idea.

derSammler wrote:

* Most device drivers won't do anything bad if you load them without the hardware being present. They will simply tell you that the hardware wasn't found and that the driver was not installed. So instead of doing over-complicated branching, just put all device drivers under [common] and let them always load. If the hardware is present, they will load and install, if not, then not.

That's not the "problem" he's trying to solve. He's trying to optimize memory usage and produce an amazing, ultimate, bestest in the universe set of config files. Never mind that at that point (and frankly, already way before that point) they will end up way too convoluted and messed up for anyone to actually use. Apparently, there is not much that can be done: messing with DOS startup files is a contagious disease. 😉

dr_st wrote:

That's not the "problem" he's trying to solve. He's trying to optimize memory usage and produce an amazing, ultimate, bestest in the universe set of config files.

Well, he refered to his project thread where he explains his goals. And there's that sentence:

and easy selection of soundcard - supported are Yamaha, Creative - Audigy and !Live(only Win98/DPS comp. version), AurealV1,AurealV2,ESS-Solo1..

So I guess that *is* one of his problems, too. 😉

Yes, you are right. I have not been keeping up with specifics - do any of these cards actually require device drivers to be loaded from CONFIG.SYS, or only TSRs from AUTOEXEC.BAT? And are they only device-specific or some of them generic (so they would load and take up memory even if unused)?

In any case, in my view, and based on my experience with DOS gaming, different soundcards is pretty much the most serious reason to have different paths in startup files (there are also games incompatible with real mode / EMM386 - a secondary reason). So if ever it makes sense to have a boot menu, it's for selecting the sound card configuration.

Of course, if it happens that you don't need any differences in CONFIG.SYS, you can handle it without any boot menus by a single variable in AUTOEXEC.BAT.