Path: utzoo!attcan!uunet!steinmetz!control!dixon
From: dixon@control.steinmetz (walt dixon)
Newsgroups: comp.sys.ibm.pc
Subject: Re: DOS device driver problem
Message-ID: <12534@steinmetz.ge.com>
Date: 5 Nov 88 13:29:24 GMT
References: <712@inuxh.UUCP>
Sender: news@steinmetz.ge.com
Reply-To: dixon@control.steinmetz.ge.com (walt dixon)
Organization: General Electric CRD, Schenectady, NY
Lines: 30

There are basically two i/o paths through DOS  --  character i/o functions
(ah=01h to 0ch) and other i/o functions.  The character i/o requests transfer
a single character directly to the driver.  DOS does not mess with the text
stream.  Writes to CON, AUX, or PRN using these functions should pass 1ah
(^Z).

The second i/o path encounters a DOS internal write routine.  This routine
looks at some attributes in an internal DOS data structure called the
System File Table (SFT).  If the target dis a device and it is not in
transparent mode,  each character is checked.  If an EOF (^Z) is detected,
an EOF status is set in the SFT and the write returns without sending
the character to the device.  If the device is in transparent mode,  DOS
does not check the character stream.

The LSB of the driver attributes word is copied to the SFT when the driver
is open.  DOS specifically masks the bit corresponding to transparent mode,
so you can not set this bit in your driver unless you (*GASP*) patch DOS.
Such drastic action is normally not required,  because one can easily put
a device into transparent mode with an IOCTL request.  Once in transparent
mode,  DOS will faithfully pass all characters to your device.

You should be aware of one side effect of transparent mode.  In text
(ie non transparanet) DOS passes one character at a time to the driver
because it is looking for special (ie ^Z) characters.  In transparent mode,
DOS passes the entire request.  The bottom line is you really need to
look at the count field in the request header.

Walt Dixon

Standard disclaimers apply