Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

TSR vs DEVICE= (Announce)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 18.06.2010, 21:50

Regarding the Device Driver vs. TSR "controversy", I would like to throw in my two cents.

TSR's are actually "easier" to write. While CONFIG.SYS is being processed, many of the DOS services that you generally take for granted (even very basic things like writing text to the screen, manipulating files, and redirection/piping) are limited or non-existent. With TSR's, all DOS services are available for use.

I think it is safe to say that anything that can be done with a device driver in CONFIG.SYS can also be done with a TSR (either in AUTOEXEC.BAT or from the command-line), but the reverse most certainly is NOT true. The only drivers that actually need to be in CONFIG.SYS are things that the BIOS or DOS kernel may require early in the boot process (e.g., a memory manager needs to be in CONFIG.SYS or DOS may not be able to use/manage UMB's or HMA).

Even you never take advantage of the opportunity, I think you should always have the option of removing drivers from memory ad-hoc if you want to without needing to reboot. It is true that rebooting isn't nearly as big of a deal in DOS as it is in Windows or Linux, but should still be avoided whenever possible. Also, just because you believe there should never be a reason to uninstall any particular driver doesn't mean the end-user will think the same thing, no matter how "illogical" you think their reasoning may be. FORCING the user to reboot to change something when it isn't really necessary is bad policy, IMHO.

Although they are a very interesting concept, there really is no reason to build "dual" EXE/device-drivers (or COM/device-drivers), except for those that are needed by DOS while booting as discussed above. From a practical perspective, device drivers provide no advantage whatsoever over TSR's, either to the programmer or the end-user. In fact, device drivers have many disadvantages.

If a DOS driver is so old that it is not being updated or maintained any more, than there is not a lot you can do about that. But, all modern DOS programs should IMHO use modern protocols and installation techniques such as AMIS (which inherently includes IISP), which provide a structured environment for TSR's and device drivers to communicate and cooperate with each other regarding items such as interrupt handlers, device headers, and hot-keys.

I must admit that even I was slow to accept AMIS, I think because I was confusing it with the older TesSeRact which I knew from experience was fraught with problems. After Christian Masloch mentioned AMIS to me, I investigated it a little and found that AMIS has addressed most (though not quite all) of the issues that were present in TesSeRact. I personally think all modern TSR's and device drivers should use it, and will be adding it to all of my programs as they are updated. In many cases, AMIS also makes the order of installation (and removal) far less critical to the end-user, which is a good thing.

 

Complete thread:

Back to the forum
Board view  Mix view
22781 Postings in 2123 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum