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:
- Open Autoexec.bat and search for variable with agreed prefix
- When is varaible found parsed for value for this variable
- Repeat until end of file
- 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.
- Draw gui footer - info how to use - save / quit key short cuts labels or buttons
- Unlock elements for user action - check / uncheck checkbox.. select item form combobox..
- If quit action - quit without saving..
- 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.