There was an old tool named drvload that can let you do that.

FreeDOS has a utility called 'devload' which is supported for this exact use on that system. I haven't tried (yet) but it might work on MS-DOS 6+ as well...

Yes, there are a bunch of utilities like this. LOADSYS and DDL are two others. I'm not sure if any one of them is superior to the others.

Thanks guys. If any of these are freeware or shareware, do you have a link or attachment? Thanks.

feipoa wrote:

Thanks guys. If any of these are freeware or shareware, do you have a link or attachment? Thanks.

I just did a google search without any trimming; so the following links may contain duplicates.
loadsys
ddloader
devload
devload from FreeDOS
DDL from FreeDOS
a compilation of devload, drvload, loadsys

OK, I'll check them out with MS DOS 6.22

feipoa wrote:

Is there any way to load DOS device drivers from the command line after boot?

I am doing some troubleshooting with my IBM Blue Lightening BL3 and was wondering if there is a way to run device driver for this CPU after boot, that is, as opposed to including the driver line in config.sys, e.g. device=Revto486.sys /BL /CN /CCM /3

Thanks!

If the driver is a .com or .exe then yes. If it is a .sys file then no.

If you want to setup up multiple boot possibilities you are better off modifying the Autoexec.bat file and making a boot menu so you can choose no drivers loaded, audio and video card drivers loader, mouse driver loaded, et cetera.
This is what I did back then in case a game supported mouse and sound card I would choose a different option. Some guys required max memory so I had to use a different configuration.

Anyhow it gets complex and each game may require less memory or more conventional memory so some games eliminating the mouse and video driver could get the game to work properly. One of the earlier games I think that required a lot of conventional memory was Falcon 3.0.

95DosBox wrote:

If the driver is a .com or .exe then yes. If it is a .sys file then no.

You are mistaken, sir. That is the purpose of the utilities mentioned in every other post in this thread. 😒

Jorpho wrote:

95DosBox wrote:

If the driver is a .com or .exe then yes. If it is a .sys file then no.

You are mistaken, sir. That is the purpose of the utilities mentioned in every other post in this thread. 😒

Interesting Jorpho... as someone who has used DOS since PC-DOS 1.0 around 36 years ago. I haven't seen this program on BBSes then since this one was from abroad. But for a DOS purist this tool wouldn't be available with standard DOS utilities either so the the plain old Copy con or edit would usually suffice with a quick reboot. I even Sysop'd a BBS back in the day till '93 and this would have been a handy tool in certain circumstances. Looks like LOADSYS the British program looks more robust with extensive documentation compared to that DDL one. However how stable and reliable is this program? This might come in handy for a CDrom driver activation or USB driver activation since they are memory hogs and better suited for a floppy boot disk situation where rebooting adds on the floppy boot time. But as far as actual usability if you've created a DOS config boot menu and it usually takes a few seconds to reboot anyhow to a hard drive what major significance is its usage today? Will it cleanly remove itself from memory not leaving any trace?

95DosBox wrote:

However how stable and reliable is this program?

Well, they either work, or they don't..? Back in the day I remember some CD-ROM drivers would work fine, and others would freeze.

yep, i remember Creative supply such program for their CD-ROM drivers, it was called "CTLOAD" (i forgot if it was .EXE or .COM file).
I use them so i can load CD-Rom drivers + MSCDEX later if some games actually requiring access to the CD drive.
And i recall the same CTLOAD also works for loading ANSI.SYS from command prompt.

But iirc the CTLOAD method uses up more bytes of RAM compared to the normal "DEVICE= / DEVICEHIGH=" method.

Jorpho wrote:

95DosBox wrote:

However how stable and reliable is this program?

Well, they either work, or they don't..? Back in the day I remember some CD-ROM drivers would work fine, and others would freeze.

That would be a big issue for me Jorpho if they didn't work. 😀 That's why it is better to just REM areas in your config.sys or just rename config.sys after copying it and removing everything but the driver you need and reboot. From a stability standpoint I would fear uninstall and reinstalling a driver using one of those programs may cause instability or not properly eliminate itself freeing your memory completely compared to a clean boot of just the sys files you needed. But thanks for at least bringing an alternative solution to loading /unloading sys files because it never occurred to me that someone would come up with something like this and Microsoft didn't. 😀

Usually it's tweaking QEMM or something and getting the config.sys just right to free up the most conventional memory and setting the config in stone. It did bug me that I had to keep my CDrom driver in memory when I didn't need it for certain games so I always tried to find a CD patch so it could run directly off the hard drive. I might play around with these SYS unloaders just for fun to see how the work down the road. But the best old school solution always had been creating a very complex Config.sys boot menu structure without such a program to do this.

Joey_sw wrote:

yep, i remember Creative supply such program for their CD-ROM drivers, it was called "CTLOAD" (i forgot if it was .EXE or .COM f […]
Show full quote

yep, i remember Creative supply such program for their CD-ROM drivers, it was called "CTLOAD" (i forgot if it was .EXE or .COM file).
I use them so i can load CD-Rom drivers + MSCDEX later if some games actually requiring access to the CD drive.
And i recall the same CTLOAD also works for loading ANSI.SYS from command prompt.

But iirc the CTLOAD method uses up more bytes of RAM compared to the normal "DEVICE= / DEVICEHIGH=" method.

Interesting I can't recall ever using CTLOAD to load ANSI.SYS. I think most of my conventional memory headaches were solved with QEMM. But during the Sysop BBS days Ansi.Sys was constantly loaded. 😀

feipoa wrote on 2017-01-23, 21:09:

OK, I'll check them out with MS DOS 6.22

How did this work out for you? Did you have better luck with any one tool over the other?

I asked chat ChatGPT to give me a comparison and it was surprisingly verbose. This was the closing summary:

Recommendation

• Use DevLoad if you prioritize driver compatibility and stability.
• Use LoadSys if you need more flexibility in memory management and driver loading options.
• Use DDLoader only for basic setups where simplicity is key and the drivers you need to load are well-tested.

Another one I use is Dynaload.com from PC DOS. Latest is version 12.01.2003.build_1.32
It's worked whenever I have tried it.

douglar wrote on 2024-11-21, 15:55:

How did this work out for you? Did you have better luck with any one tool over the other? […]
Show full quote

feipoa wrote on 2017-01-23, 21:09:

OK, I'll check them out with MS DOS 6.22

How did this work out for you? Did you have better luck with any one tool over the other?

I asked chat ChatGPT to give me a comparison and it was surprisingly verbose. This was the closing summary:

Recommendation

• Use DevLoad if you prioritize driver compatibility and stability.
• Use LoadSys if you need more flexibility in memory management and driver loading options.
• Use DDLoader only for basic setups where simplicity is key and the drivers you need to load are well-tested.

The attachment image.png is no longer available

I forgot about this post. I almost always use DDL.

This archive has these tools and a bunch of CD-ROM drivers:

https://archive.org/details/dosdrivers

I used these under MS-DOS 6.22 ... (just today, to try them out)

LOADSYS.EXE (I liked this one, will load high automatically if possible and has tons of command line options {4 pages!})
DDLOADER.COM (this didn't work too well for me)
DEVLOAD.COM (later modified version, post 1996; there is an earlier V1.8, so caution on which .com you have)
(this package does not have DRVLOAD.COM which appears to also have been written around 1993)

(NOTE for reference, this package also has duse.exe - possibly enable USB attached floppy disk drive; that might be useful for a system that boots C: but has a bad floppy drive)

Use DDL/DDU a command keyword in FreeDOS? I couldn't find these as explicit programs (closest I found was that DDLOADER.COM which didn't have an unloader equivalent)

No matter which of the above I tried, I wasn't able to then load MSCDEX.EXE high (would just lock up). So I'm still at 599KB conventional RAM (on a 386DX) since MSCDEX eats 31KB RAM.

But I do have a use-case for a driver like this: I am using a PnP SB16. Apparently when I power off the system, and later power on - that PnP SB16 reverts to some default config settings. My preferred system settings don't get applied until I set the BLASTER variable and run UNISOUND.COM (which I can't do that until autoexec.bat). That means the first time I boot my system (cold-start?), my CD-ROM driver always fails to load (I'm using the IDE header on the SB16 for the CD-ROM). Then after autoexec.bat is called and BLASTER + unisound.com are ran, then my PnP SB16 are set (and keep its setting if I Ctrl-Alt-Delete warm-start). So then during the second boot, then the SB CD-ROM driver loads and everything is fine.

Using these utilities, I can set BLASTER, execute unisound, then load the IDE driver in the autoexec.bat just before MSCDEX. So all works on first boot instead of needing a second boot.

douglar wrote on 2024-11-21, 15:55:

How did this work out for you? Did you have better luck with any one tool over the other? […]
Show full quote

feipoa wrote on 2017-01-23, 21:09:

OK, I'll check them out with MS DOS 6.22

How did this work out for you? Did you have better luck with any one tool over the other?

I asked chat ChatGPT to give me a comparison and it was surprisingly verbose. This was the closing summary:

Recommendation

• Use DevLoad if you prioritize driver compatibility and stability.
• Use LoadSys if you need more flexibility in memory management and driver loading options.
• Use DDLoader only for basic setups where simplicity is key and the drivers you need to load are well-tested.

The attachment image.png is no longer available

ChatGPT is often wrong about computer/electronics stuff. As it is in this case. DEVLOAD breaks all kinds of stuff. Including Mike Brutman's netdrive. (He says specifically to not use it)

voidstar wrote on 2025-03-23, 19:57:

This archive has these tools and a bunch of CD-ROM drivers: […]
Show full quote

This archive has these tools and a bunch of CD-ROM drivers:

https://archive.org/details/dosdrivers

I used these under MS-DOS 6.22 ... (just today, to try them out)

LOADSYS.EXE (I liked this one, will load high automatically if possible and has tons of command line options {4 pages!})
DDLOADER.COM (this didn't work too well for me)
DEVLOAD.COM (later modified version, post 1996; there is an earlier V1.8, so caution on which .com you have)
(this package does not have DRVLOAD.COM which appears to also have been written around 1993)

(NOTE for reference, this package also has duse.exe - possibly enable USB attached floppy disk drive; that might be useful for a system that boots C: but has a bad floppy drive)

Use DDL/DDU a command keyword in FreeDOS? I couldn't find these as explicit programs (closest I found was that DDLOADER.COM which didn't have an unloader equivalent)

No matter which of the above I tried, I wasn't able to then load MSCDEX.EXE high (would just lock up). So I'm still at 599KB conventional RAM (on a 386DX) since MSCDEX eats 31KB RAM.

But I do have a use-case for a driver like this: I am using a PnP SB16. Apparently when I power off the system, and later power on - that PnP SB16 reverts to some default config settings. My preferred system settings don't get applied until I set the BLASTER variable and run UNISOUND.COM (which I can't do that until autoexec.bat). That means the first time I boot my system (cold-start?), my CD-ROM driver always fails to load (I'm using the IDE header on the SB16 for the CD-ROM). Then after autoexec.bat is called and BLASTER + unisound.com are ran, then my PnP SB16 are set (and keep its setting if I Ctrl-Alt-Delete warm-start). So then during the second boot, then the SB CD-ROM driver loads and everything is fine.

Using these utilities, I can set BLASTER, execute unisound, then load the IDE driver in the autoexec.bat just before MSCDEX. So all works on first boot instead of needing a second boot.

Creative labs literally made a utility for this. CTLOAD

I found a perfect reason to use DRVLOAD.COM (at least that's what I used; the other variant/similar programs might also work - but confirmed DRVLOAD.COM worked for me in the following use case).

I found that Tyrian was taking a really long time to load, almost a minute. At first I couldn't figure out why - it had loaded fast before, and this was on a 386DX-33. I tried removing all peripherals, unnecessary cards, ran scandisk, disabled sound. It was still taking over 40 seconds (same for the setup.exe program with Tyrian). This timeout was so long, you couldn't setup a direct-connect (null modem) game because the other client would timeout while waiting for the connection.

Then I realized, Tyrian sort of does a RAM check on startup, as it tries to prepare a cache of all available extended RAM. In other words, the more RAM you have, the longer Tyrian takes to load.

So the solution is to create a RAM drive that "eats"/waste some RAM, giving Tyrian less to allocate. But maybe you don't always want a RAM drive. So I verified you can dynamically create the RAM drive later from the DOS prompt: (the following I used with MS-DOS 5.0)
DRVLOAD c:\dos\ramdrive.sys 24000 /e
Allocate a 24MB RAM drive, giving Tyrian about 8MB left.

And bam, Tyrian now loads much faster on this same system. Now, even with sound disabled, Tyrian is too slow for multi-player on a 386DX. Even single player is barely playable on a 386DX with 4MB RAM. Still it's nice to confirm we can make RAM drives as needed from the command line.

kingcake wrote on 2025-03-31, 03:17:

Creative labs literally made a utility for this. CTLOAD

Which version of SoundBlaster has this? My SB Pro and SB16 installs did not include CTLOAD. But maybe I didn't do full or original installs, I can't recall. And like all the other programs like this, there may be limitations on how well it works - but nice to know there is another option.

Another aspect here is "period correct" systems. On my 1992 386, I avoid any post-1992 software (which is why I put MS-DOS 5 on there) to keep it closer an "authentic experience." So tracking down when CTLOAD first became available would be good (tentatively it seems to be a post Win95 thing).