In the case of cd drivers the device driver provides a standard interface for MSCDEX to talk to the physical hardware, and MSCDEX handles translating the regular DOS file I/O functions (as well as providing extra functionality like CD audio). So the hardware driver has to be loaded first.

Oetker wrote on 2021-02-28, 08:02:

every mouse driver I've seen was a .com file

Search for "mouse701.zip" - contains both .COM and .SYS files.

SYS drivers occupy slightly less RAM, because there's no Program Segment Prefix.
But COM/EXE drivers can be loaded at any time, and occupy no RAM until loaded...

Grzyb wrote on 2021-02-28, 13:13:

SYS drivers occupy slightly less RAM, because there's no Program Segment Prefix.
But COM/EXE drivers can be loaded at any time, and occupy no RAM until loaded...

There's actually a PC-98 DOS program called ADDDEV that allows you to load .SYS drivers at any time. It also bundled a program called DELDEV to unload them at any time. Not sure if something similar exists for IBM PCs.

thepirategamerboy12 wrote on 2021-02-28, 13:24:

There's actually a PC-98 DOS program called ADDDEV that allows you to load .SYS drivers at any time. It also bundled a program called DELDEV to unload them at any time. Not sure if something similar exists for IBM PCs.

There's the DYNALOAD in PC DOS 7.0/2000, but I experienced some issues with it.
And I think I saw something like that in QEMM.

Grzyb wrote on 2021-02-28, 13:13:

SYS drivers occupy slightly less RAM, because there's no Program Segment Prefix.

Interesting, thanks!

Just to make things more confusing, I just ran across https://web.csulb.edu/~murdock/install.html earlier which says that if you use INSTALL= in CONFIG.SYS to load a TSR (.COM/.EXE):

In the past, INSTALL may have saved you a little bit of memory because it does not create an environment when it loads a program. With DOS 6.0 an environment is created, so the extra memory is no longer gained by using the INSTALL command

I assume that either way there will be a PSP but it won't have an environment of its own in older DOS versions, it will just point to the global one or something?

Another difference is that as far as I know .SYS drivers seem to be necessary to install actual "devices" as seen by DOS, i.e. the ones you see in the output of the MEM /D command. I suppose installing devices is one way to enable other software to communicate with your driver, but you could just implement a TSR which hooks an interrupt, so I'm not sure when it's particularly important to actually install a device except when you need to conform to a particular interface. MSCDEX is an example where you need to conform to the interface it expects: it requires a device name to be passed to it, so the low-level CD-ROM driver pretty much has to be a .SYS one (unless maybe you can hook some interrupts and pretend that you installed a device without really doing it, but that seems unnecessarily complicated?).

Grzyb wrote on 2021-02-28, 17:21:

thepirategamerboy12 wrote on 2021-02-28, 13:24:

There's actually a PC-98 DOS program called ADDDEV that allows you to load .SYS drivers at any time. It also bundled a program called DELDEV to unload them at any time. Not sure if something similar exists for IBM PCs.

There's the DYNALOAD in PC DOS 7.0/2000, but I experienced some issues with it.
And I think I saw something like that in QEMM.

There seem to be quite a few tools like this around from well before DOS 7. See Re: If in config.sys or some work around for it. and the post after it if you're interested in some pointers.

doshea wrote on 2021-03-01, 10:38:

Grzyb wrote on 2021-02-28, 17:21:

thepirategamerboy12 wrote on 2021-02-28, 13:24:

There's actually a PC-98 DOS program called ADDDEV that allows you to load .SYS drivers at any time. It also bundled a program called DELDEV to unload them at any time. Not sure if something similar exists for IBM PCs.

There's the DYNALOAD in PC DOS 7.0/2000, but I experienced some issues with it.
And I think I saw something like that in QEMM.

There seem to be quite a few tools like this around from well before DOS 7.

DEVLOAD, DRVLOAD, DDL, LOADSYS, and CTLOAD also come to mind. Many are listed in this thread:
How to load DOS device drivers from the command line?

Thanks for the info thus far, I guess I can conclude that in many cases developers just chose to go with an executable file as that's easier for users.

I expect it is also much less likely for random, unrelated problems to start cropping up if a driver is loaded early in config.sys rather than at the end of autoexec.bat, so from a support standpoint a developer might be much more inclined to force a user to load the driver early rather than deal with random queries about insufficient conventional memory and so on.

as someone who has written both, there are a few issues when developing with .sys files,

1 - The whole DOS api is not available to you, you have a limited set of api (honestly its not a big deal, but its not all there)
2 - Because the system is in transition when you get control at the .sys level your not allowed to do a lot of things
3 - Compilers dont output native sys format, so if your not doing assembler, your more screwed.

with a sys, you cant control where you are loaded at, unlike a COM TSR, you can move yourself around in memory, you cant do with as a .SYS file because does has some very set expectations on memory at that stage.

Jorpho wrote on 2021-03-01, 16:32:

DEVLOAD, DRVLOAD, DDL, LOADSYS, and CTLOAD also come to mind. Many are listed in this thread:
How to load DOS device drivers from the command line?

Thanks for the pointer!