🚀 go-pugleaf

In article <90187.102930TOMIII@MTUS5.BITNET> TOMIII@MTUS5.BITNET (Thomas Dwyer III) writes:
>Just what *is* involved in loading a block driver and linking it into
>the chain?  What about removing drivers?  Can I just set the previous
>driver to point to the following one, and then free some memory?

Don't forget that there are other data structures you have to deal with
other than just the device driver chain.  Also, if you intercepted any
vectors, you must make sure that you still own them before you restore
them and release the memory.  Programs that restore vectors and leave
without checking first can cause some really weird stuff to happen later.

>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?  No, I do not want to boot once and start
>guessing letters until I find it, and then code that into the autoexec.
>I want to determine the device number(s) independant of hard drive
>partitions, switch settings, and the order of my config.sys file.
>
>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)?

Character devices have a name field.  For block devices, the first byte
of this is used instead to tell how many units it supports.  By going
through the device driver chain and counting these, you should be able
to determine the drive letters associated with that driver.  Note that
if you inserted your driver anywhere but at the end of the chain, you
would change the drive letters of the drives supported by the other
drivers.  That would cause problems for using a technique like the one
you have just described.

--Jeff Pipkins
pipkins@imagen.com

Disclaimer: "I've already told you more than I know!"