Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

TSR vs DEVICE= (Announce)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 19.06.2010, 20:33

Japheth:

Let me explain what I do in my programs, and you (or somebody) can tell me whether it's possible to do this directly (or some equivalent with perhaps a different syntax) in a CONFIG.SYS driver.

For text output, I always use INT 21.40. If it is "regular" text, I use handle 1 (STDOUT), and I use handle 2 (STDERR) if it is an "error" message. This allows the user, if they want to, to suppress the "regular" text (including the Copyright message, if they don't want to see my name plastered on their screen all the time) by redirecting the output to NUL, or redirecting/teeing the output to a printer or a file in some unusual circumstance. Yet, this still sends any possible "error" messages directly to the screen, e.g.:

Program [options] > NUL

I also use input redirection. Some of my programs may require LOTS of input options, far too many to fit in the 126 character limit of a traditional command-line tail. For example, in the USB keyboard driver the user may want to remap virtually the entire keyboard, which requires the input of many, many parameters. To allow for a "long" command-line tail, I use input redirection, e.g.:

Program < "C:\Option Files\Program.Options"

(I personally don't normally use LFN, but simply did that to exaggerate the point).

While CONFIG.SYS is being processed, DOS is "incomplete". Documentation I have seen states that the only DOS functions that are available while CONFIG.SYS is being processed are 01-0Ch (basic console I/O stuff) and 30h (Get DOS version). DOS-based file/device manipulation, either using FCB's or handles, is unavailable. It is certainly possible that redirection and piping are available (I've never actually tried it), but I would be very surprised. Exactly what's available during CONFIG.SYS processing may also vary depending on the manufacturer and version of DOS, but I don't know that for sure, either.

I realize there are other ways of accomplishing some of the same things, e.g. with additional command-line options, but that is not the point. The point is that a TSR has access to many "nice" DOS functions that can make it "easier" to write a program, especially a complicated program, than a device driver has. With a TSR, the programmer has a choice of whether or not to use those "extra" features, but with a device driver there is no choice.

Post reply
 

Complete thread:

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