VOGONS

Common searches


First post, by Oetker

User metadata
Rank Member
Rank
Member

Why is it that some DOS drivers are .sys files that need a device= line in config.sys, while others are .exe or .com files? I can see that .sys files have to adhere to a specific interface, is that too limited in some cases?

For example, every mouse driver I've seen was a .com file, sound card drivers vary and cd drivers use a combination for low/high level logic (.sys files and mscdex.exe). Though I guess that in the cd driver case, the reason might be to have the low-level part always be loaded first.

Reply 1 of 11, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 2 of 11, by Grzyb

User metadata
Rank Oldbie
Rank
Oldbie
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...

Reply 3 of 11, by thepirategamerboy12

User metadata
Rank Member
Rank
Member
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.

Reply 4 of 11, by Grzyb

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 5 of 11, by doshea

User metadata
Rank Newbie
Rank
Newbie
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?).

Reply 6 of 11, by doshea

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 7 of 11, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
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?

Reply 9 of 11, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 10 of 11, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

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.

--/\-[ Stu : Bloody Cactus :: http://kråketær.com :: http://mega-tokyo.com ]-/\--

Reply 11 of 11, by doshea

User metadata
Rank Newbie
Rank
Newbie
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!