cyclone3d wrote on 2021-02-27, 08:58:

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.

Yes, that would be nice, but as has already been pointed out those tools don't work in all cases, and didn't work for one case that ruthan wanted:

gdjacobs wrote on 2018-08-08, 19:54:

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

ruthan wrote on 2018-08-15, 13:03:

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.

I suppose it is possible that other tools do better or worse at this task. I think the software I used to use was called DRVLOAD. https://toogam.com/software/archive/drivers/d … rt/dosstart.htm seems to have a collection of a few tools, I suppose one could do some experiments to see which one works best.

About the other tool I found interesting, it's not something that does everything BOOT.SYS can, but it's something that is public domain with source code, so it could serve as a starting point to implement an alternative to BOOT.SYS. Here is the link: http://malban.de/oldies/software/software-maus-sys-sys It's graphical and uses a mouse, there's a screen shot on that page.

BOOT.SYS also has some hardware detection capability which you can use in its "if" statements. It can detect CPUs (up to Pentium) and video cards (up to VGA), plus:

ID( ssss:oooo, hh ... ) […]
Show full quote

ID( ssss:oooo, hh ... )

This condition can be used to check for specific hardware. It is
true if the RAM or ROM at address ssss:oooo contains the
hexadecimal byte(s) hh..., for example, on a given PC, DEBUG will
show the following:

-d f000:fff0
F000:FFF0 CD 19 E0 00 F0 30 37 2F-30 37 2F 39 31 00 FC 00
.....07/07/91...

This ROM BIOS has a date of 07/07/91, and ID( F000:FFF5, 30 37 2F
30 37 2F 39 31 ) will be true on this PC, but not on another one
with a different ROM BIOS date.

What I would like is the ability to detect PCI devices, which is a pretty standard thing to be able to do these days. It would be nice if we could get the source code to BOOT.SYS so we can add this, but if not maybe we can add some functionality to MAUS-SYS.SYS so it can do the things BOOT.SYS does and more.

Ok, so Netroom 3.04 Devload should be what you want. There are some other programs included that help in different situations.

The manual is really needed to see what you need to do to set up stuff properly.

I really don't want to tear apart my manual to scan it though. I don't have a non-destructive book scanner setup yet.

doshea wrote:

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

Problem with Grub is that i needs Linux, i experiment with some Linux os SS7 and SC370 machine, it could be done, but its annoying and it need lots of place, special partition etc. So solution would be grub4dos or something like that.. i experimented with it, made it working, but as usually for Linux like things its not straight forward.

So it would need make some easy to install package, which could be installed right through ms-dos and setup basic setup, without breaking booting and with minimal learning curve - if there would be some some options, it has to be some press X to this option wizard, any command line hell.

One thing I want to try is overwriting my config.sys and autoexec.bat with batch scripts from within windows 9x before a restart-in-dos mode. This would make it possible to essentially create a boot disk for each configuration you need, or for what I want to do essentially every dos app/game I want to run. I haven't tried setting it up yet though.

ruthan wrote on 2021-02-28, 21:30:

Problem with Grub is that i needs Linux, i experiment with some Linux os SS7 and SC370 machine, it could be done, but its annoying and it need lots of place, special partition etc. So solution would be grub4dos or something like that.. i experimented with it, made it working, but as usually for Linux like things its not straight forward.

SYSLINUX works fine from DOS - I have my SYSLINUX.CFG in a FAT filesystem and it comes with tools that run under DOS.

I think I read in a prior post in this thread that grub4dos lets you immediately boot something from the command line? I don't think SYSLINUX can do that, unfortunately. Also SYSLINUX is complicated too 😀

Are you going to try out BOOT.SYS which I posted about? It seems like exactly what you want! I haven't had a chance to do anything with it yet myself but will post if/when I do.

mothergoose729 wrote on 2021-02-28, 22:32:

One thing I want to try is overwriting my config.sys and autoexec.bat with batch scripts from within windows 9x before a restart-in-dos mode. This would make it possible to essentially create a boot disk for each configuration you need, or for what I want to do essentially every dos app/game I want to run. I haven't tried setting it up yet though.

There's some built-in support for what I think you want to do! In Windows 95 RTM, for example, go to the Properties for a shortcut, go to the Program tab, then click on the Advanced... button and you can tell it to start in MS-DOS mode and supply a CONFIG.SYS and AUTOEXEC.BAT. I suppose the drawback compared to your approach is that you need to edit those files in tiny 3-line edit boxes, but I suppose you could put INCLUDE= line(s) in CONFIG.SYS (I think that's a thing?) and CALL statement(s) in AUTOEXEC.BAT that refer to files you can edit in an actual editor. When you launch the shortcut, after displaying a warning (which you can disable) it will restart in MS-DOS mode, run your program, then when you exit DOS it will go back to Windows.

I was reminded that this exists by a PhilsComputerLab video I watched recently.

Are you going to try out BOOT.SYS which I posted about? It seems like exactly what you want! I haven't had a chance to do anything with it yet myself but will post if/when I do.

It needs more time to analyze it, its big side step.. so far i need clarify these..

Advantages vs. standard MS-DOS inbuild confs files

1. Bootmenu before MS-DOS with boot menu support, that is MS-DOS 6, i guess?
2. Better colored graphics.
3. AFAIK - 1 file, instead of autoexec and config - 2 files.
4. Support of classical IF conditions, it can safe lots of text blocks and make clear more clear etc.

Disadvantages

1. You need to learn new syntax.
2. You need port old good configs to new format.
3. Limited documentation and community support in comparison with standard way.
4. Normal installers are often modifying autoexec and config, with this there will not do anything, or they will report problems, which are not really problem, because if will not have reason to setup these files properly

Open

1. Installation - - you somewhere download it and its not free, its cant be bough (tried someone to contact author to make it free for retro hobby use?) and somehow install it, i dunno how complicated it is
2. There are known incompatibilities?
3. In-Build bootmenu has limit max 9 items, its possible with this make more?
4. Is needed some resident loader or something like?
5. Is there additional used memory?
6. Its fast to load, its some addional slow wait to load that fancy graphics and features?

doshea wrote on 2021-03-01, 02:35:

mothergoose729 wrote on 2021-02-28, 22:32:

One thing I want to try is overwriting my config.sys and autoexec.bat with batch scripts from within windows 9x before a restart-in-dos mode. This would make it possible to essentially create a boot disk for each configuration you need, or for what I want to do essentially every dos app/game I want to run. I haven't tried setting it up yet though.

There's some built-in support for what I think you want to do! In Windows 95 RTM, for example, go to the Properties for a shortcut, go to the Program tab, then click on the Advanced... button and you can tell it to start in MS-DOS mode and supply a CONFIG.SYS and AUTOEXEC.BAT. I suppose the drawback compared to your approach is that you need to edit those files in tiny 3-line edit boxes, but I suppose you could put INCLUDE= line(s) in CONFIG.SYS (I think that's a thing?) and CALL statement(s) in AUTOEXEC.BAT that refer to files you can edit in an actual editor. When you launch the shortcut, after displaying a warning (which you can disable) it will restart in MS-DOS mode, run your program, then when you exit DOS it will go back to Windows.

I was reminded that this exists by a PhilsComputerLab video I watched recently.

Interesting, I didn't know that. Thank!

ruthan wrote on 2021-03-01, 03:13:

It needs more time to analyze it, its big side step..

It sure is!

[*] Bootmenu before MS-DOS with boot menu support, that is MS-DOS 6, i guess?

Correct, the manual says: "BOOT.SYS will work with any IBM-compatible computer that uses MS-DOS or PC-DOS versions 2.11 through 6.x. It will also work with DR DOS versions 5.0 and 6.0 and Novell DOS 7."

[*] Better colored graphics.

Yes, I had a little play and got the menu to look like this so you can definitely do some interesting things with the appearance:

I intentionally got rid of the border around the top box, but I think the border on the menu itself went away because it won't fit when there are the maximum (20) menu items on the screen.

The "0 A" at the bottom right corner is debugging information I enabled indicating that it's menu 0, or something like that.

Also it's not really "graphics", it's plain VGA text mode.

[*] AFAIK - 1 file, instead of autoexec and config - 2 files.

I don't think so. It doesn't claim to remove the need for AUTOEXEC.BAT. Perhaps you could use INSTALL= lines in CONFIG.SYS to load TSRs, and I think you can set variables using BOOT.SYS which will be seen in the environment (but you might need to run BOOT.EXE, a BOOT.SYS companion, from AUTOEXEC.BAT to do that). However I think I read that there is a 64KB limit on the size of CONFIG.SYS for MS-DOS and PC-DOS, and the documentation says the limit in DR DOS 6.0 is 8K, so you might not be able to fit everything you need.

[*] You need to learn new syntax.
[*] You need port old good configs to new format.

Yes, work is definitely required, and I don't think anything at this level in DOS is easy enough that you can get away without reading a manual 😀

In terms of porting old configurations, the installer (which doesn't modify your existing configuration in place but instead gives you new files to look at and then copy over to C:\) does understand DOS 6.x menus and converts them into its own syntax. At least that's what the manual says, I haven't tried that yet.

[*] Limited documentation and community support in comparison with standard way.

Definitely true! I did see one or two people mention the tool on the vcfed.org forums, so perhaps there are people there experienced with it.

[*] Normal installers are often modifying autoexec and config, with this there will not do anything, or they will report problems, which are not really problem, because if will not have reason to setup these files properly

That's a very good point. The manual suggests that before you install new software you rename CONFIG.SYS and AUTOEXEC.BAT so that the installer doesn't mess them up, and then you have to manually integrate the installer's CONFIG.SYS and AUTOEXEC.BAT into your original files and rename them back. An alternative they suggest is to hack your IO.SYS/IBMBIO.COM and COMMAND.COM to read from filenames other than CONFIG.SYS and AUTOEXEC.BAT. Neither of these are great solutions unfortunately!

Personally what I would like to do is have a version control system track those files so I can tell what changes the installer made to them - I can ask the version control system for the differences - and then I can choose what to keep, fix or throw away and then store those changes in the version control system. I found a page which says that Mercurial can be made to work under DOS: http://matejhorvat.si/en/dos/hg/index.htm This is really only a solution for programmers though!

[*] Installation - - you somewhere download it and its not free, its cant be bough (tried someone to contact author to make it free for retro hobby use?) and somehow install it, i dunno how complicated it is

I want to evaluate it a bit before I contact the author, to make sure it's worth it.

The install is a bit complicated, it asks quite a few questions and then gives you a log file and updated CONFIG.SYS and AUTOEXEC.BAT files to look at. However, it the author allows it, it would be quite possible to just redistribute the BOOT.SYS and BOOT.EXE files (and maybe some other accompanying files), as the installer doesn't need to be run to modify the MBR or anything, it just exists to extract the archive and to help you get "My First BOOT.SYS Menu" based on your current config.

[*] There are known incompatibilities?

Probably! I haven't read all of the documentation.

[*] In-Build bootmenu has limit max 9 items, its possible with this make more?

"Each menu may have up to 20 items, and you may have up to 25 menus to define different aspects of your system."

[*] Is needed some resident loader or something like?
[*] Is there additional used memory?

"BOOT.SYS typically uses less than 200 bytes of DOS memory; under the newest DOS versions it does not stay resident at all."

I did see this though:

The versions of HIMEM.SYS delivered with DOS 5, DOS 6, and Windows 3.1 are designed to load part of themselves into th […]
Show full quote

The versions of HIMEM.SYS delivered with DOS 5, DOS 6, and
Windows 3.1 are designed to load part of themselves into the HMA
or High Memory Area when DOS=HIGH is active. Unfortunately, they
grow considerably (to about 33K instead of about 4K) when
BOOT.SYS is used to set DOS=LOW. This problem doesn't exist with
the version of HIMEM.SYS that was distributed with Windows 3.0,
nor with any of the third-party memory managers (like QEMM-386,
386MAX, etc.); if you need a memory manager for your DOS=LOW
configurations, we suggest you use one of these.

If I understand correctly, the context here is that if you want different DOS= settings for different configurations, you must set DOS=LOW at the start of CONFIG.SYS, but this apparently causes the weird issue described above.

[*] Its fast to load, its some addional slow wait to load that fancy graphics and features?

I haven't tried on real hardware, so I don't know how long it really takes to load, but as I said above, it's plain VGA text mode, so it shouldn't be slow. BOOT.SYS is 57KB so it shouldn't take too long to load.

Thanks for your useful questions!

ruthan wrote:

AFAIK - 1 file, instead of autoexec and config - 2 files.

doshea wrote:

I don't think so. It doesn't claim to remove the need for AUTOEXEC.BAT. Perhaps you could use INSTALL= lines in CONFIG.SYS to load TSRs, and I think you can set variables using BOOT.SYS which will be seen in the environment (but you might need to run BOOT.EXE, a BOOT.SYS companion, from AUTOEXEC.BAT to do that). However I think I read that there is a 64KB limit on the size of CONFIG.SYS for MS-DOS and PC-DOS, and the documentation says the limit in DR DOS 6.0 is 8K, so you might not be able to fit everything you need.

I dont understand this part, when i checked some code example above, it look as complete autoexec and config.sys replacement.. but i could be wrong.. How looks most basic, barebone configuration when you are using boot.sys? What happens, when autoexec and config are deleted, its still booting? Because 3 files, instead of 2 is not upgrade, is downgrade..

ruthan wrote on 2021-03-04, 04:08:

I dont understand this part, when i checked some code example above, it look as complete autoexec and config.sys replacement.. but i could be wrong.. How looks most basic, barebone configuration when you are using boot.sys? What happens, when autoexec and config are deleted, its still booting? Because 3 files, instead of 2 is not upgrade, is downgrade..

Sorry, I wasn't very clear, BOOT.SYS is the name of the driver which implements the menu system, it's not the name of a new configuration file.

Here's a small (maybe not the most basic, but fairly simple) example from the documentation with one menu that lets you pick either DOS or Windows,and both CONFIG.SYS and AUTOEXEC.BAT do different things based on what you pick:

CONFIG.SYS:

1DEVICE=d:\path\BOOT.SYS
2DEVICE=BOOT.TOP My BOOT.SYS Configuration Menu
3DEVICE=BOOT.1 &Windows Configuration
4  DEVICE=BOOT.SET BOOT=Windows
5  {commands for Windows configuration}
6DEVICE=BOOT.2 &DOS Configuration
7  DEVICE=BOOT.SET BOOT=DOS
8  {commands for DOS configuration}
9DEVICE=BOOT.END

AUTOEXEC.BAT:

1@ECHO OFF
2d:\path\BOOT SET
3IF ERRORLEVEL 255 GOTO No_BOOTSYS
4GOTO %BOOT%
5
6:No_BOOTSYS
7  ECHO BOOT.SYS was not properly installed
8  GOTO END
9
10:DOS
11  {DOS configuration commands go here}
12  GOTO END
13
14:Windows
15  {Windows configuration commands go here}
16  GOTO END
17
18:END