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