mattern@ncoast.UUCP (Duane L. Mattern) (06/25/88)
I'm looking for a way to install/de-install device drivers into DOS 3.xx. Typically these drivers are installed during booting, (in config.sys), but they can eat up a lot of memory. Does anyone have way to de-install and re-install device drivers, so that they are only active when actually need and not eating up memory than could be used (read that "is needed") for application programs? Better yet, can I move the device drivers to expanded or extended memory? (I know the answer is no, but I just thought I'd ask). No flames about DOS please. I'd switch to QNX (or even a hog like UNIX) if I could get anyone to agree with me....(and pay for it) -------------------------------------------------------------------- Duane L. Mattern Sverdrup Technology, Inc 27387 Westown Blvd. #1412 @ NASA Lewis Research Center Westlake, Ohio 44145 21000 Brookpark Rd, M/S 77-1 (216) 835-2676 Cleveland, Ohio 44135 mattern@ncoast.uucp (216) 433-2355 --------------------------------------------------------------------
dixon@zephyrus.steinmetz (Walter V. Dixon) (06/27/88)
Newsgroups: comp.sys.ibm.pc Subject: Re: DOS 3.xx device install/de-install ?? Summary:it is possible Expires: References: <8178@ncoast.UUCP> Sender: Reply-To: dixon@zephyrus.UUCP (Walter V. Dixon) Followup-To: Distribution: na Organization: General Electric CRD, Schenectady, NY Keywords: DOS, device drivers, config.sys What you are asking is quite feasible and, in fact, I have done it. The most expedient approach is to write a utility to load drivers (or use a self-loading driver). By hooking code into the appropriate DOS data structures, one can convince DOS that this code truly is a driver. For character drivers the driver chain is the key structure. The driver chain is a singly linked list of device headers whose listhead is the NUL device header. One can locate the NUL device using the undocumented int 21h ah=52h or opening NUL with an FCB (one of the "reserved FCB fields contains the driver header -- the offset varies with DOS version). If one is replacing the console or clock device, one must update the header address stored in a DOS global data structure (the one returned by int 21h ah=52h). DOS records the address of the console device (stdin and stdout bits in driver attributes word set) to deal with detecting breaks. Recording the clock header is a performance enhancement. Block drivers must link to the Curent Directorory Structure (CDS) and Device Control Block (DCB) chain. These structures can also be located via int 21h ah=52h. They also must adjust the count of block devices (constrained by lastdrive= in config.sys) and must respect the largest sector size (set when DOS is booted). Unloading drivers gets tricky. Drivers associated with a real piece of hard- ware usually hook one or more interrupt vectors. Before unloading, one must make sure that no other program has also hooked this vector and is waiting to pass an interrupt along to the code you are about to unload. Before unloading a block device driver, one must make sure that there are no dirty blocks in the cache. DOS records the device header (character) or DCB (block device) header in the System File Table (SFT). Since DOS is not expecting you to unload a driver, you had better make sure you don't leave any dangling references in the SFT. I've described how DOS implements character device i/o in fairly great detail in chapter 10 of The MS DOS Papers (edited by the Waite Group and published by Howard Sams) [I don't get any royalties from sales of this book -- I'm just giving a reference]. I hope this information helps and is of enough general interest to warrant posting to the net rather than replying directly to the sender. Walt Dixon (ARPA: Dixon@GE-CRD.ARPA ) (US Mail: GE Corp R&D ) ( PO Box 8 ) ( Schenectady NY 12345 ) (Voice: 518-387-5798 )