Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.sys.ibm.pc
Subject: Re: TSR's
Message-ID: <22f07455@ralf>
Date: 29 Jul 88 12:49:25 GMT
Sender: netnews@pt.cs.cmu.edu
Lines: 24
In-Reply-To: <665@ns.UUCP>

In article <665@ns.UUCP>, ddb@ns.UUCP (David Dyer-Bennet) writes:
}In article <250@westmark.UUCP>, dave@westmark.UUCP (Dave Levenson) writes:
}> What a `real device driver' can do is look like a disk file.  
}  I'd thought this was just a matter of getting into the name table, which
}is done automatically for device drivers.  Is there some reason a tsr couldn't
}put itself into the name table?  (Whatever the darned official name of the
}thing is).

Yes, it is possible, but undocumented.  For a character device (with a name, 
like CON or PRN), it is simply a matter of hooking into the device driver 
chain.  For a block device (which gets a drive letter), there are several 
other DOS data structures which have to be modified.  I'll let Walt Dixon go 
into the details there, since he's the expert on that subject.

The NUL device is always the first device in the driver chain, and can be 
found with the undocumented DOS call 52h (INT 21h/AH=52h).  On return, ES:BX
points to DOS's list of lists.  In DOS 2.x, the actual NUL device header 
starts at ES:[BX+17h], and in DOS 3.x it's ES:[BX+22h].

--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school)
ARPA: ralf@cs.cmu.edu  BIT: ralf%cs.cmu.edu@CMUCCVMA  FIDO: Ralf Brown 1:129/31
Disclaimer? I     |Ducharm's Axiom:  If you view your problem closely enough
claimed something?|   you will recognize yourself as part of the problem.