VOGONS


Reply 20 of 50, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
ruthan wrote:

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.

No. The whole idea behind GRUB4DOS is that you do not need GRUB code in MBR. GRUB4DOS is a standard DOS/MZ executable that's why you can call it from autoexec.bat. With GRUB4DOS you could boot even different DOS images from DOS itself based on even autoexec.bat variables (which you wanted). I have already regretted mentioning this since it seems caused just confusion.
It was just a theoretic example how you can emulate something you wanted, not considering practical aspects.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 21 of 50, by derSammler

User metadata
Rank l33t
Rank
l33t
dr_st wrote:

do any of these cards actually require device drivers to be loaded from CONFIG.SYS, or only TSRs from AUTOEXEC.BAT?

No idea, since I have never used any of these cards in DOS. The Yamaha one however seems to need something in config.sys. I own one and looked at the drivers when I got it. It had some .sys files for DOS.

Reply 22 of 50, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie
derSammler wrote:

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.

Could you be more specific?

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.

Im doing it because of save conventional memory.. At least some cd-rom driver are in memory even without working MSCDEX.exe because MSCDEX is loaded from autoexec same ESS sound drivers, which has Config.sys part too. On some machines, especially on those with big Videocards roms every KB of conventional memory counts..

dr_ST wrote:

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).

I dont thing that user friendliness is ridiculous, submenu means additional user actions.. and im lazy and every unnecessary key press counts even on Core 2 machine is boot already annoyingly slow and there even slower machines, yeah is mainly because of Grub loading (i need it for multiboot) is slow and its not something what i can to improve (or at least without addional research, maybe default grub is loading too muc videocards drivers, resolution is too big). Because in grub, except my present testing are not Windows 98+Dos default option.. and there is some timer for users decision (which could bes skipped by key press), there are already few key presses to select Windows 98 option and activate it.. And imagine that there even users which needs to fiddle with Bios profiles / settings to boot pure Dos.

derSammler wrote:
ruthan wrote:

and easy selection of soundcard - supported are Yamaha, Creative - Audigy and !Live(only Win98/DPS comp. version), AurealV1,AurealV2,ESS-Solo1../quote]
So I guess that *is* one of his problems, too. 😉.

This actually already working quite well, except ESS driver which need some *.sys config.. there is one thing for user - setup some variable on 1 place in top of autoexec, im calling it autoexec header.. and it move in some text config file i would want too.. maybe even create some that snippets program to setup that header.. but other annoying thing is to say user.. sorry header is not good enough.. have to go other file - config somewhere middle and rem some ESS line (yeah i could be done by snippets too.. but it would be additional work and would be autoexec header working, dont feel it as necessary.. if someone want to code it, ok its great optional feature / tool).

FalcoSoft wrote:

No. The whole idea behind GRUB4DOS is that you do not need GRUB code in MBR. GRUB4DOS is a standard DOS/MZ executable that's why you can call it from autoexec.bat.
With GRUB4DOS you could boot even different DOS images from DOS itself based on even autoexec.bat variables (which you wanted). I have already regretted mentioning this since it seems caused just confusion.
It was just a theoretic example how you can emulate something you wanted, not considering practical aspects.

Sorry im a bit lost here.. So ok i will start Grub4Dos from autoexec, what about default config.sys, i would let it empty, or with minimize settings? So after mini-zed (slim) config processing, i would start autoexec, which would start thick configs? And after that would be started thick autoexecs?
Even if this would work, i now sure, if is better solution to have lots of smaller configs and autoexecs instead 1 big.. Yeah it would solve maybe configuration problem, but only if that tools which could generated those images can ran in pure Dos.. otherwise.. images have to be created in advance, there is too many combinations i would want to cover every combination boot menu items list would be huge..

Sys manipulations way
For now that.. *.sys solution seems to be much better /easier. If is possible start SYS from other "master/ dummy" *.sys (config way) or some sys through some executable from Autoexec (autoexec way)- both solution would be fine.
If this would be possible it would same need only some cmd tool, to package some existing *.sys into master *.sys which would have only true/false logic - load/ not load packaged slave *.sys and i would replace file lines in config.sys, instead of device=cdrom.sys i would use device=MasterCdrom.sys true/false.. that true/false value has to be loaded form some configuration file (ideally from some autoexec header where would otherwise unused variable) <= config Way
or some *.exe tool to start *.sys from Autoexec, so we not need some *.sys packaging <=Autoexec way

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 23 of 50, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
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)..

There are utilities for doing so (I gather), but that wasn't what I was thinking.

Falcosoft wrote:

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.

That is what I was thinking. I'm not sure about everyone else, but pretty much all my configs have a standard arrangement.

Preamble:
This has FILES, STACKS, DOS directives.
Memory Manager:
HIMEM, UMBPCI, EMM386, JEMM, etc are loaded.
Multimedia Drivers:
Here I load SCSI, sound, CD drivers and such which can't be done in AUTOEXEC.BAT or at runtime.

Stuff continues in AUTOEXEC.BAT

I'm thinking you could store the appropriate bits for each piece of hardware or utility and assemble them into a custom configuration or set of configurations as required. If a utility gets added or hardware gets changed, add and remove components with the wizard as needed to generate a new set of CONFIG.SYS and AUTOEXEC.BAT files for your setup.

As a bonus, something like this could incorporate a resource resolver that keeps track of DMA, IRQ, and IO, emitting the correct flags or copying in files for CTCM (for example) as needed. Granted, not so much of an issue with PCI only, but for many DOS machines it might be snazzy.

All hail the Great Capacitor Brand Finder

Reply 24 of 50, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie
gdjacobs wrote:
Preamble: This has FILES, STACKS, DOS directives. Memory Manager: HIMEM, UMBPCI, EMM386, JEMM, etc are loaded. Multimedia Driver […]
Show full quote

Preamble:
This has FILES, STACKS, DOS directives.
Memory Manager:
HIMEM, UMBPCI, EMM386, JEMM, etc are loaded.
Multimedia Drivers:
Here I load SCSI, sound, CD drivers and such which can't be done in AUTOEXEC.BAT or at runtime.

Nice splitting.
- - Enviroment settings - your FILES, STACKS, DOS directives. //Line Im ok which how config,sys is handling this part. Im using universal block for all branches, but if want i could easily create multiple blocks with different block and call them in dependency of selected branch (which is derived from memory managers settings - see bellow)
- Im also ok with memory managers config.sys handling - my config branches are mainly derived from memory manager settings, and that is what users / games really want.. again im ok with that.
- Multimedia Drivers - that is only part - where im not satisfied wit config,sys possibilities .. because i would say that other level of setting, which is not dependant of selected memory manager branches - logic, its lots more machine depended.. i would create branch for every possibility there would be zillions of branches, so some configuration header / file.. is best solution, which would be applied across the branches (with some limitation, as that no CD-ROM debug branch would not include CD-ROM block at all etc.. but these are details).
If driver could be handled by autoexec only - its already solved - variable at top of autoexec and ifs, but when i needs some sys driver from config - we have problem, to solve.. why i need some workaround.

gdjacobs wrote:

Stuff continues in AUTOEXEC.BAT

I'm thinking you could store the appropriate bits for each piece of hardware or utility and assemble them into a custom configuration or set of configurations as required. If a utility gets added or hardware gets changed, add and remove components with the wizard as needed to generate a new set of CONFIG.SYS and AUTOEXEC.BAT files for your setup.

This solution would be more complex that i proposed and im already features greedy:) I would be ok with autoexec header - one place to set up all variable by true/false variable or selection from predefined set of posssiblities (list of supported soundcards), i think that is simple enough for users, lots of programs have such ini files, this just copy/paste form line above.. Im already using this logic.. but as i already mentioned about.. its not possible to sys.. and possible solution for that are above.. If user has to care only about header, he dont need to be worry about that whole rest of autoexec or config code is long, complex, ugly spaghetti thing.. - he can pretend that its just some binary dont touch piece of code.

Yeah you can everytime upgraded my solution by updating autoexec header by some external utility, but its enhancement not necessity.. Primary problem to solve is sys handling.. unless you would handle also config part by utility too, but im a bit against this, because config has not variables, no simple header like structure and you would need to mess with whole "body", its code would have to be more complex and more chance to broke it by config upgrades. With autoexec header solution, autoexec and utility coders dont need to cooperate too much.. with autoexec+config - they do, or whole solution would be at least more complex. With autoexec header only.. if someone give me simple setup like GUI utility (magnificently said framework), where i could simply adding / remove binding to autoexec header variable to add/remove GUI option + define available values from option to (it could be defined in utility framework, or loaded from header automatically, to remove declaration duplicity.. binding could be automated to by some naming convention for variables names.. use only variables with some preffix, ignore others.) . In reality only 2 - GUI elements whould be needed (except labels- text and butons (shortcuts) for save or quit) - checkbox (booleans - enable cd-rom, enable virtual cd-rom, enable sound) and combobox (selecting for predefined set - string - select cd-rom handler, soundcard etc..)... I would not need any other features, support for utility creator etc.. with autoexec+config closer cooperation would be needed and solution would be more fragile..
I hope you understand what i wanted to say.

Update (im still mainly intereesting about *.sys part of solution, but) how to GUI config should work:

  1. Open Autoexec.bat and search for variable with agreed prefix
  2. When is varaible found parsed for value for this variable
  3. Repeat until end of file
  4. Draw gui header + elements depend on what parsed - checkbox for variables with YES/NO values, combobox for others.. Lets say that first value with be default one. Add scrollbar, if list to long for 1 screen.
  5. Draw gui footer - info how to use - save / quit key short cuts labels or buttons
  6. Unlock elements for user action - check / uncheck checkbox.. select item form combobox..
  7. If quit action - quit without saving..
  8. If save button click or save key pressed.. Open file, search for variables with preffix.. if user selected value is different from that in file replace.. otherwise repeat until all found variable in previn step 1. Save file changes, quit utility.
    * Bitch about declaration / parsing errors between steps:)
gdjacobs wrote:

As a bonus, something like this could incorporate a resource resolver that keeps track of DMA, IRQ, and IO, emitting the correct flags or copying in files for CTCM (for example) as needed. Granted, not so much of an issue with PCI only, but for many DOS machines it might be snazzy.

its other brand new layer.. nice enhancement.

I already have SB IRQ 5 / 7 handled by my branches. that only other main variable beside memory manager setting.. i have all main branches with both IRQ variable and also created some user friendly *.bat to change these setting for sound drivers which could be unloaded.. witch could be run, even without reboot - autoexec / configs edit just for one setting.
Add DMAs global variables to autoexec header is already possible, im using LOW-DMA1 + HIGH-DMA5 for all my braches, im not aware that i would be problem for some users.. but i said, i could make header variable for that very quickly with present toolset.

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 25 of 50, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
ruthan wrote:

This solution would be more complex that i proposed and im already features greedy:) I would be ok with autoexec header - one place to set up all variable by true/false variable or selection from predefined set of posssiblities (list of supported soundcards), i think that is simple enough for users, lots of programs have such ini files, this just copy/paste form line above.. Im already using this logic.. but as i already mentioned about.. its not possible to sys.. and possible solution for that are above.. If user has to care only about header, he dont need to be worry about that whole rest of autoexec or config code is long, complex, ugly spaghetti thing.. - he can pretend that its just some binary dont touch piece of code.

I'm not sure you follow my thinking. Here's a simple example without any menu options (the proper stanzas could be injected the same way).

Say I start with a chunk that has FILES, BUFFERS, DOS=HIGH,UMB, etc...

COPY \UTIL\CONFIG.SYS\CONFIG.HDR CONFIG.TMP

I then add a chunk for HIMEMX.

TYPE \UTIL\CONFIG.SYS\HIMEMX\NOLIMIT.CFG >> CONFIG.TMP

I add a chunk for my EMM.

TYPE \UTIL\CONFIG.SYS\MSFTEMM\EMS.CFG >> CONFIG.TMP

CD-ROM driver

TYPE \UTIL\CONFIG.SYS\CDDRV\GCDROM.CFG >> CONFIG.TMP

The process continues for AUTOEXEC.BAT.

If this were to be automated, it would effectively give you a scripted configuration for CONFIG.SYS which simply isn't possible otherwise.

All hail the Great Capacitor Brand Finder

Reply 26 of 50, by derSammler

User metadata
Rank l33t
Rank
l33t
ruthan wrote:
derSammler wrote:

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.

Could you be more specific?

Not sure how I can be more specific. You can then just load .sys files in autoexec.bat, e.g.

devlod C:\SB16\DRV\CSP.SYS /UNIT=0 /BLASTER=A:220
devlod C:\SB16\DRV\CTMMSYS.SYS

Reply 27 of 50, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie
derSammler wrote:

Not sure how I can be more specific. You can then just load .sys files in autoexec.bat, e.g.

I just wanted name of tool and maybe some syntax examples, now i have it, thanks..
Any info about compatibility / incompatibility? What is last version, where to get it?

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 30 of 50, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie
gdjacobs wrote:

I'm not sure you follow my thinking. Here's a simple example without any menu options (the proper stanzas could be injected the same way).

Sorry what you wrote was too cryptic to me, thanks for clarification, but there are still things which i dont understand..

gdjacobs wrote:
Say I start with a chunk that has FILES, BUFFERS, DOS=HIGH,UMB, etc... CODE: SELECT ALL COPY \UTIL\CONFIG.SYS\CONFIG.HDR CONFIG. […]
Show full quote

Say I start with a chunk that has FILES, BUFFERS, DOS=HIGH,UMB, etc...
CODE: SELECT ALL
COPY \UTIL\CONFIG.SYS\CONFIG.HDR CONFIG.TMP

I then add a chunk for HIMEMX.
CODE: SELECT ALL
TYPE \UTIL\CONFIG.SYS\HIMEMX\NOLIMIT.CFG >> CONFIG.TMP

I add a chunk for my EMM.
CODE: SELECT ALL
TYPE \UTIL\CONFIG.SYS\MSFTEMM\EMS.CFG >> CONFIG.TMP

CD-ROM driver
CODE: SELECT ALL
TYPE \UTIL\CONFIG.SYS\CDDRV\GCDROM.CFG >> CONFIG.TMP

The process continues for AUTOEXEC.BAT.
If this were to be automated, it would effectively give you a scripted configuration for CONFIG.SYS which simply isn't possible otherwise.

Sorry i still dont understand main mechanism /sense. The commands above- Will where, in some configuration tool, or directly in config? If in config, where is if logic?, conditions which will define which cfg would be used? Because that is what we need add some if-else (or if-if-if ) logic.. Because there is not such logic, which cfg would be used would be handled only by selected branch.. we are already there, i dont see the benefit.. Unless you will generate it for only for next reboot - that not what is see as big improvement.

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 31 of 50, by Koltoroc

User metadata
Rank Member
Rank
Member

what you wan't to do cannot be done unless you develop your own version of dos with that specific feature set.

What gdjacobs proposes is an automated script to assemble a config.sys based of text snippets containing individual pieces for the next reboot. That is the best and approximation of what you want that can be done.

Once again, it will NOT get better than his suggestion. what you want is NOT POSSIBLE.

Reply 32 of 50, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

If DEVLOD will work there is everything what i wanted.. but it doesnt seems to be part of 7.1, at eleast when i call "devlod" get bad command. Could someone try it on older MS-DOSes?

Nobody also didnt yet proved that my 1 more layer *.sys theory is nonsense.

New version of Dos, these are big worlds, technically you can call any OS hack as new OS..

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 33 of 50, by derSammler

User metadata
Rank l33t
Rank
l33t

devlod is not part of any DOS version, it's a third-party tool. The link I've posted above even contains the source code to it.

technically you can call any OS hack as new OS..

No, you can't.

Reply 34 of 50, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie
derSammler wrote:

devlod is not part of any DOS version, it's a third-party tool. The link I've posted above even contains the source code to it.

Ok, i see, its after references part, i didn read further. Does someone DOS IDE ready to compile it and share the result?

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 35 of 50, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
ruthan wrote:
If DEVLOD will work there is everything what i wanted.. but it doesnt seems to be part of 7.1, at eleast when i call "devlod" ge […]
Show full quote

If DEVLOD will work there is everything what i wanted.. but it doesnt seems to be part of 7.1, at eleast when i call "devlod" get bad command. Could someone try it on older MS-DOSes?

Nobody also didnt yet proved that my 1 more layer *.sys theory is nonsense.

New version of Dos, these are big worlds, technically you can call any OS hack as new OS..

DEVLOD will help with what you want, but my understanding is that it's sometimes hit and miss.

All hail the Great Capacitor Brand Finder

Reply 36 of 50, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie
gdjacobs wrote:

DEVLOD will help with what you want, but my understanding is that it's sometimes hit and miss.

Primary is if it would work with ESS SOlo-1 dos driver.. and cd-rom drivers, but there is quite few CD-ROM drivers, so at least 1 should work.. other sys are more optimal.

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 37 of 50, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

Ok i have tried devload which was bundled with Netbootdisc image.

2 of 3 cd-rom drivers could be loaded fine, 3rd im not capable to test with my present HW, unfortunately ESSOLO-1 sound driver ESSsolo.sys not working, i get driver not loaded message.

So it could help, but not with everything.

Attachments

  • Filename
    DEVLOAD.zip
    File size
    3.27 KiB
    Downloads
    81 downloads
    File license
    Fair use/fair dealing exception

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 38 of 50, by doshea

User metadata
Rank Member
Rank
Member
ruthan wrote on 2018-08-06, 16:46:

I dont thing that user friendliness is ridiculous, submenu means additional user actions.. and im lazy and every unnecessary key press counts even on Core 2 machine is boot already annoyingly slow and there even slower machines, yeah is mainly because of Grub loading (i need it for multiboot) is slow and its not something what i can to improve (or at least without addional research, maybe default grub is loading too muc videocards drivers, resolution is too big).

Yes, grub certainly can be quite slow! I'm pretty sure you can tell grub to use standard VGA 80x25 text mode, as I've seen this even with modern grub 2, and I would hope that would be faster. Another alternative is SYSLINUX, which I've used to boot DOS directly from a FAT partition or from a bootable floppy or hard drive image inside a FAT partition (or using PXELINUX boot the same over the network).

More importantly, to answer the original question: I want similar CONFIG.SYS conditionals, and in searching for ways to do that I found this thread and also found some possible solutions. And they said it couldn't be done!

My trick for finding the first solution was to look in places with old utilities. For example if you do a Google search for "site:cd.textfiles.com config.sys" you'll find simtel20 had a "Booting Utilities" file collection. I just went through those files one by one. I found some tools which provide MS-DOS 6-style menus for older DOS versions, and other tools which let you pick from one of a number of CONFIG.SYS and AUTOEXEC.BAT files and then reboot your system. The best I found so far is BOOT.SYS which apparently has "if/then/else and use of variables in CONFIG.SYS, editing CONFIG.SYS lines on the fly". It is the "most powerful multiboot software" according to PC Magazine, September 14, 1993.

Even though BOOT.SYS was last updated in 1994 it has an official web page: https://salvisberg.com/boot.sys Unfortunately it is shareware and the author no longer sells licenses for it. Perhaps now that a lot of time has passed they can be convinced to release it as open source, or sell all rights to the software?

I found this in the documentation, which I think might satisfy your needs, it is certainly what I've been looking for:

     Nested Menus vs. Menu Sequences

BOOT.SYS supports two different kinds of menus. The more common
are hierarchical or nested menus: there is a main menu and some
of the selections lead on to one or more submenus that define the
main choice in detail. Let's illustrate this with an example:


DEVICE=d:\path\BOOT.SYS |
DEVICE=BOOT.1 DOS | DOS
DEVICE=BOOT.A | plain
DEVICE=BOOT.1 plain | EMM386
DEVICE=BOOT.2 EMM386 | QEMM
DEVICE=BOOT.3 QEMM | Windows
DEVICE=BOOT.Z |
DEVICE=BOOT.2 Windows
DEVICE=BOOT.END

The main menu presents only two choices, DOS or Windows; if you
choose DOS, you get a submenu with either plain DOS, or DOS with
one of two memory managers.

Now imagine you want to select whether to load a network driver
or not. With hierarchical menus, you have several ways of doing
so, but you can't avoid duplication:

* Expand the main menu to four items, DOS or Windows, each
with or without the network, and duplicate the submenu for
the two DOS choices.

* Add a new main menu for the network question and duplicate
the entire menu tree for Yes and No.

* Add a submenu to each of plain, EMM386, QEMM, and Windows,
asking about the network.

None of these choices is attractive because duplication results
in additional complexity and makes your configuration files more
difficult to maintain as you add more options. The core of the
problem is that the operating environment and the network are
unrelated choices, but a hierarchical menu is based on a
relationship between the choices.


BOOT.SYS - 74 - Version 2.1



What you really need is a set of independent menus or a menu
sequence:

DEVICE=d:\path\BOOT.SYS
|
DEVICE=BOOT.A |
DEVICE=BOOT.1 load Network | Load Network
DEVICE=BOOT.2 no Network | Don't Load Network
|
DEVICE=BOOT.B | -------------------
DEVICE=BOOT.1 DOS |
DEVICE=BOOT.A | DOS
Show last 135 lines
                  DEVICE=BOOT.1 plain        |      plain
DEVICE=BOOT.2 EMM386 | EMM386
DEVICE=BOOT.3 QEMM | QEMM
DEVICE=BOOT.Z | Windows
DEVICE=BOOT.2 Windows |
|
DEVICE=BOOT.Z
DEVICE=BOOT.END

Now we have a menu A for the network question and a menu B for
the operating environment. Item B1 in menu B happens to contain
a submenu, which we call B1A. These are the menu names you will
see in the lower right corner of the screen if you specify the /P
parameter on the BOOT.SYS command line (see page 33).

Note the similarity of syntax between submenus and menu
sequences: submenus are really just menu sequences (with only one
menu in this case) inside a menu item. You can combine nested
menus and menu sequences in any way you like. For example, you
could add a menu C to define a third unrelated aspect of your
configuration, a menu B1B to specify DOS=UMB or NOUMB, or a menu
A1A to select among different networks.

Instead of adding a submenu to A1, you might prefer to add more
menu items (A3, A4, etc.) to menu A. Only you know what works
best for you.


Using Variables and Conditionals in CONFIG.SYS

Let's look at the previous example once again and assume that we
cannot run the network software without a memory manager. That
is, there should be no "plain" choice in menu B when the user
selected to start the network in menu A:


BOOT.SYS - 75 - Version 2.1



DEVICE=d:\path\BOOT.SYS

DEVICE=BOOT.A
DEVICE=BOOT.1 load Network
DEVICE=BOOT.SET NET=Y
DEVICE=BOOT.2 no Network

DEVICE=BOOT.B
DEVICE=BOOT.1 DOS
DEVICE=BOOT.A
DEVICE=BOOT.? NOT %NET% == Y # plain
DEVICE=BOOT.# EMM386
DEVICE=BOOT.# QEMM
DEVICE=BOOT.Z
DEVICE=BOOT.2 Windows

DEVICE=BOOT.Z
DEVICE=BOOT.END

Here the "plain" choice is displayed only when the variable NET
does not have a value of Y.

Perhaps we always want to load the network driver into upper
memory, using the proper command for the chosen memory manager:

DEVICE=d:\path\BOOT.SYS

DEVICE=BOOT.A
DEVICE=BOOT.1 load Network
DEVICE=BOOT.SET NET=Y
DEVICE=BOOT.2 no Network

DEVICE=BOOT.B
DEVICE=BOOT.1 DOS
DEVICE=BOOT.A
DEVICE=BOOT.? NOT %NET% == Y # plain
DEVICE=BOOT.# EMM386
device=c:\dos\HIMEM.SYS
device=c:\dos\EMM386.EXE ram
dos=umb
DEVICE=BOOT.IF %NET% == Y
devicehigh=d:\net\wd8003.sys
DEVICE=BOOT.ENDIF
DEVICE=BOOT.# QEMM
device=c:\qemm\QEMM386.SYS
DEVICE=BOOT.IF %NET% == Y
device=c:\qemm\LOADHI.SYS d:\net\wd8003.sys
DEVICE=BOOT.ENDIF
DEVICE=BOOT.Z
DEVICE=BOOT.2 Windows

DEVICE=BOOT.Z


BOOT.SYS - 76 - Version 2.1


DEVICE=BOOT.END
DOS=NOUMB

If you want to avoid duplicating the command line for the network
driver, you can use another variable:

DEVICE=d:\path\BOOT.SYS

DEVICE=BOOT.A
DEVICE=BOOT.1 load Network
DEVICE=BOOT.SET NET=Y
DEVICE=BOOT.SET NETDRVR=d:\net\wd8003.sys {parameters...}
DEVICE=BOOT.2 no Network

DEVICE=BOOT.B
DEVICE=BOOT.1 DOS
DEVICE=BOOT.A
DEVICE=BOOT.? NOT %NET% == Y # plain
DEVICE=BOOT.# EMM386
device=c:\dos\HIMEM.SYS
device=c:\dos\EMM386.EXE ram
dos=umb
DEVICE=BOOT.IF %NET% == Y
devicehigh=%NETDRVR%
DEVICE=BOOT.ENDIF
DEVICE=BOOT.# QEMM
device=c:\qemm\QEMM386.SYS
DEVICE=BOOT.IF %NET% == Y
device=c:\qemm\LOADHI.SYS %NETDRVR%
DEVICE=BOOT.ENDIF
DEVICE=BOOT.Z
DEVICE=BOOT.SET NETDRVR=
DEVICE=BOOT.2 Windows

DEVICE=BOOT.Z
DEVICE=BOOT.END
DOS=NOUMB

This is what the initial menu it created for me looked like, not very exciting or powerful yet but it seems like a very interesting tool.

screenshot.png
Filename
screenshot.png
File size
2.5 KiB
Views
1427 views
File license
Public domain

The manual says you can change the colours and the background fill pattern.

I think I found another alternative which has source code available, but I need to find my notes and then download and try it, then I'll post again.

Reply 39 of 50, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

I am not at home right now, but I am pretty sure I have a memory manager suite that can load and unload drivers, etc. from batch files and/or the command prompt.

This would essentially leave you with the option to only need the very basics in config.sys and be able to do almost everything through autoexec.bat and/or other batch files.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK