Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!uakari.primate.wisc.edu!crdgw1!sagittarius!dixon
From: dixon@sagittarius.crd.ge.com (walt dixon)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: .SYS (device drivers) that are actually .EXEs?
Message-ID: <9466@crdgw1.crd.ge.com>
Date: 7 Jul 90 12:30:44 GMT
References: <j8t1seef8@tmsoft.uucp> <141@qmsseq.imagen.com> <552@csource.oz.au> <142@qmsseq.imagen.com> <90187.102930TOMIII@MTUS5.BITNET>
Sender: news@crdgw1.crd.ge.com
Reply-To: dixon@sagittarius.crd.ge.com (walt dixon)
Organization: General Electric Corp. R&D, Schenectady, NY
Lines: 60

In <90187.102930TOMIII@MTUS5.BITNET> Thomas Dwyer writes:

>Just what *is* involved in loading a block driver and linking it into
>the chain?

Block devices require patching two additional lists and updating the
current drive count. The listheads for both lists as well as the
drive count is in the data structure returned by the undocumented int
21h ah=52h. The two lists in question are the Current Directory Structure
(CDS) and the Device Control Block (DCB) chain.  The CDS is a contiguous
array whose size is determined by LASTDRIVE (or its default value).
The DCB is a linked list.  The CDS contains the DCB address and the
DCB contains the address of the device header.  This information is
documented in Chapter 10 of "The MS-DOS Papers", (Howard Sams, 1988).

>What about removing drivers?  Can I just set the previous
>driver to point to the following one, and then free some memory?

Removing drivers can be troublesome.  There is no absolutely fool-proof
method.  The issue here is one of tracking down device references.  Does
the driver support Open/Close operations?  Are there any open files?
Are there references to the device in the System File Table?  (FCB access
causes problems here.  Although there is a SFT for FCB access,  one
may not find information here.  The FCB maintains complete context
information).  What about cached disk blocks?  A reset will flush the
cache.  What about a program doing absolute reads/writes (int 25 and 26).
What about lower level access?  What about a program that determines
the driver address and then bypasses DOS? (Print.com does this).
The bottom line here is that removing a driver is tricky.  It may work
most of the time.

>  One
>more thing - suppose I want to install a ram disk, and have my autoexec
>copy some files there.  How can I determine the device number (ie A=0,
>B=1, etc) of the ramdisk?

The index into the current directory structure determines the drive
number.  If there is some way to identify the ram disk (eg it contains
the string RAM DISK following the device header,  it creates a RAM DISK
volume label,  it has a unique media code/structure),  then one can walk
the CDS looking for a particular driver.

[text deleted]

>My solution was to patch the init routine of the ramdisk I use now to
>save the device number passed to it by DOS.  Then I track down the
>driver in memory, and grab the number from a predetermined offset from
>the device header.  Isn't there a better method that does not require
>me to patch my driver(s)?

I've offered an alternative technique.  Whether it is better or not is
subjective.

Walt Dixon		{internet:	dixon@crd.ge.com	}
			{us mail:	ge crd			}
			{		po box 8		}
			{		schenectady, ny 12301	}
			{phone		518-387-5798 (W)	}
			{		518-875-6203 (H)	}
Walt Dixon dixon@crd.ge.com