Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!elroy.jpl.nasa.gov!ames!sun-barr!newstop!sun!imagen!qmsseq!pipkins From: pipkins@qmsseq.imagen.com (Jeff Pipkins) Newsgroups: comp.sys.ibm.pc.programmer Subject: Re: .SYS (device drivers) that are actually .EXEs? Message-ID: <143@qmsseq.imagen.com> Date: 9 Jul 90 22:32:37 GMT References: <141@qmsseq.imagen.com> <552@csource.oz.au> <142@qmsseq.imagen.com> <90187.102930TOMIII@MTUS5.BITNET> Reply-To: pipkins@imagen.com (Jeff Pipkins) Organization: QMS Inc., Mobile, Alabama Lines: 37 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!"