🚀 go-pugleaf

In article <j8t1seef8@tmsoft.uucp> mshiels@tmsoft.UUCP (Michael A. Shiels) writes:
>I have been folling around with the MS-NET and Lan Manager connection
>using NDIS network drivers.  And low and behold the drivers are .SYS files
>but they don't have a standard header.  They actually have a .EXE header.
>
>Does anyone know if Microsoft has allowed RELOCATABLE Device Drivers as .EXEs?

In MS-DOS versions < 3.0, the EXEC function call (EXE loader) was actually
a part of COMMAND.COM.  Because COMMAND.COM is not loaded until after
CONFIG.SYS is processed, device drivers could not be in .EXE format.
(incidently, that is also why it's COMMAND.COM instead of COMMAND.EXE)

With MS-DOS versions >= 3.0, the EXEC function is part of MS-DOS proper
(if indeed one can use the word "proper" in the same sentence with the
word "MS-DOS"), so now device drivers can be in .EXE format.  After the 
program is loaded and the relocation is performed, the image must look just
like the .SYS image, with device driver header at ORG 0 and all that.

It is also possible to create a plain old .EXE file program that can be
invoked from the command line that can install itself as a device driver.
To do this, it must find the device driver chain (via an undocumented
function call) and link a device driver header into it.  The initialization
call will not be made, of course.  If you need to write a device driver
in a high-level language (even <GASP> turdo pascal or <NOOOO!> basic),
this is your best bet.

In OS/2, device drivers have the .SYS extension and are .EXE files complete
with headers, relocation information, dynamic library link information, etc.

In article <141@qmsseq.imagen.com> pipkins@imagen.com (Jeff Pipkins) writes:
>
>In MS-DOS versions < 3.0, the EXEC function call (EXE loader) was actually
>a part of COMMAND.COM.  Because COMMAND.COM is not loaded until after
>CONFIG.SYS is processed, device drivers could not be in .EXE format.
>(incidently, that is also why it's COMMAND.COM instead of COMMAND.EXE)

Wrong!  I just whipped out the M'soft Encyclopedia, and the EXEC function
call has been there all along.  Maybe you're thinking of that short lived
abortion known as DOS 1.0.

Not to mention, I remember playing with the SHELL option to CONFIG.SYS
back in the days of 2.0 and 2.1.  Really neat tricks like having the
machine boot right into Lotus, Dbase, or Wordstar.  Only drawback was,
don't try to quit the program; very unfriendly.

kaleb@thyme.jpl.nasa.gov            Jet Propeller Labs
Kaleb Keithley

"So that's what an invisible barrier looks like"

>It is also possible to create a plain old .EXE file program that can be
>invoked from the command line that can install itself as a device driver.
>To do this, it must find the device driver chain (via an undocumented
>function call) and link a device driver header into it.  The initialization
>call will not be made, of course.  If you need to write a device driver
>in a high-level language (even <GASP> turdo pascal or <NOOOO!> basic),
>this is your best bet.
Most if not all of my drivers can use this technique already.  What I had
not even thought about was the ability to use a.EXE driver in the normal
DEVICE= line.  Most of not all the drivers I write are C with a small
.ASM stub to get things going.

In article <4237@jato.Jpl.Nasa.Gov> kaleb@mars.UUCP (Kaleb Keithley) writes:
}In article <141@qmsseq.imagen.com> pipkins@imagen.com (Jeff Pipkins) writes:
}>In MS-DOS versions < 3.0, the EXEC function call (EXE loader) was actually
}>a part of COMMAND.COM.  Because COMMAND.COM is not loaded until after
}>CONFIG.SYS is processed, device drivers could not be in .EXE format.
}>(incidently, that is also why it's COMMAND.COM instead of COMMAND.EXE)
}
}Wrong!  I just whipped out the M'soft Encyclopedia, and the EXEC function
}call has been there all along.  Maybe you're thinking of that short lived
}abortion known as DOS 1.0.

DOS 1.x had the program loader in COMMAND.COM (there was no EXEC function as
such).  At least PCDOS 2.10 had the EXEC function INT 21/AH=48h in a second
transient portion of COMMAND.COM.  All versions of DOS 3 and up have the
EXEC function in the kernel.


-- 
{backbone}!cs.cmu.edu!ralf  ARPA: RALF@CS.CMU.EDU   FIDO: Ralf Brown 1:129/3.1
BITnet: RALF%CS.CMU.EDU@CMUCCVMA   AT&Tnet: (412)268-3053 (school)   FAX: ask
_How_to_Prove_It_ by Dana Angluin  23. proof by semantic shift: some standard
    but inconvenient definitions are changed for the statement of the result.

In article <4237@jato.Jpl.Nasa.Gov> kaleb@mars.UUCP (Kaleb Keithley) writes:
$In article <141@qmsseq.imagen.com> pipkins@imagen.com (Jeff Pipkins) writes:
$>In MS-DOS versions < 3.0, the EXEC function call (EXE loader) was actually
$>a part of COMMAND.COM.  Because COMMAND.COM is not loaded until after
$>CONFIG.SYS is processed, device drivers could not be in .EXE format.
$>(incidently, that is also why it's COMMAND.COM instead of COMMAND.EXE)
$Wrong!  I just whipped out the M'soft Encyclopedia, and the EXEC function
$call has been there all along.  Maybe you're thinking of that short lived
$abortion known as DOS 1.0.

   He didn't say it didn't exist, just that it was part of COMMAND.COM.
Depending on whose DOS (IBM/Microsoft/other), the version in which it was
moved from COMMAND.COM to MSDOS.SYS/IBMDOS.COM may vary, but it _did_
originally exist in COMMAND.COM.

   From _Advanced MS-DOS_ (Ray Duncan, Microsoft Press, first edition):

	In addition, EXE-format drivers cannot be used with the IBM
	PC, since the EXE loader is located in COMMAND.COM ...

   That's from the section on installable device drivers, which are a
feature that came in with version 2.0, implying that at least some
2.0-and-higher DOS versions/flavours work that way.
-- 
   /Nikebo \ Nikebo says "Nikebo knows how to post.  Just do it."\silver@xrtll/
  /---------\_____________________________________________________\----------/
 /yunexus!xrtll!silver (L, not 1)\ Hi Ho Silver \   just silver for short   /
/Silver:  Ever Searching for SNTF \  Life sucks. \  someone buy me a BEER! /

In <141@qmsseq.imagen.com> pipkins@qmsseq.imagen.com (Jeff Pipkins) writes:

>It is also possible to create a plain old .EXE file program that can be
>invoked from the command line that can install itself as a device driver.
>To do this, it must find the device driver chain (via an undocumented
>function call) and link a device driver header into it.  The initialization
>call will not be made, of course.  If you need to write a device driver
>in a high-level language (even <GASP> turdo pascal or <NOOOO!> basic),
>this is your best bet.


DESQview comes with small utility called DEVICE.COM (around 600 bytes or
so) which allows loading _some_ device drivers - namely those that don't
link into the chain.  It loads the driver, calls the init function and
leaves it as a TSR.  It specifically checks for block device drivers (since
these MUST be linked into the device chain) and only allows character
device drivers to be loaded.  Some will work; but you couldn't load a
replacement for device which requires access from DOS - only those which
intercept and use interrupts.


david

-- 
_______________________________________________________________________________
 Unique Computing Pty Ltd  Melbourne  Australia  -  Communications Specialists 
        david@csource.oz.au    3:632/348@fidonet    28:4100/1@signet           

In article <552@csource.oz.au> david@csource.oz.au (david nugent) writes:
>In <141@qmsseq.imagen.com> pipkins@qmsseq.imagen.com (Jeff Pipkins) writes:
>
>>It is also possible to create a plain old .EXE file program that can be
>>invoked from the command line that can install itself as a device driver.
>>[deleted]
>
>
>DESQview comes with small utility called DEVICE.COM (around 600 bytes or
>so) which allows loading _some_ device drivers - namely those that don't
>link into the chain.  [deleted...]

It would not be any great feat to create a program that would load a
traditional character device driver and link it into the chain.  I'm not
sure what extra would be involved for doing the same with a block
device driver.  Also, the loaded device driver could be removed later.
The combination would give you a dynamically configurable system without
rebooting.  I've been asked for such programs many times, but not by
anyone who was willing to pay for it, and time allocated for charity
work is getting shorter all the time ;-)

Additional interesting functions are to rename devices that are already
loaded, and to rotate devices with the same name.  (If more than one
device driver is loaded with the same name, the one most recently
loaded is closer to the beginning of the chain, so the older one is no
longer used.)

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?  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)?

Thanks,
Thomas Dwyer III                            TOMIII   @ MTUS5.BITNET
Network Programmer                          DWYERIII @ MTUS5.BITNET
Computing Technology Services
Michigan Technological University

> They must have realised the problem - as IBM DOS 3.x did not work in
> this way (neither did MS DOS 2.x).  All this information and more can
> found in Dave Williams Shareware "Dos Technial Information" manual.  A
           ---------------------------------------------------------
> must for any DOS sysprog (but UNIX is more fun anyway :-)

Where can this great manual be found?

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

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!"

In <143@qmsseq.imagen.com> Jeff Pipkins writes:

[initial text deleted]
>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.
Despite what some documentation says,  this field is never used.  DOS
looks only at the unit count returned in the init request header.

>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.

This is not true.  DOS maitains a data structure refered to as the
current directory structure (CDS).  This structure is a contiguous
array of entries for each drive;  its size is set by the LASTDRIVE
statement (or its default value).  The first entry corresponds to
drive A:,  etc.  In addition to status (joined, etc),  and then current
directory,  each entry condains a pointer to the Device Control Block
(DCB) for the device which in turn points to the Device Header.  Any
relationship between drive letter and position in the driver chain is
merely a conincedence.

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

In article <9542@crdgw1.crd.ge.com> dixon@sagittarius.crd.ge.com (walt dixon) writes:
>DOS maitains a data structure refered to as the
>current directory structure (CDS).  This structure is a contiguous
>array of entries for each drive;  its size is set by the LASTDRIVE
>statement (or its default value).  The first entry corresponds to
>drive A:,  etc.  In addition to status (joined, etc),  and then current
>directory,  each entry condains a pointer to the Device Control Block
>(DCB) for the device which in turn points to the Device Header.  Any
>relationship between drive letter and position in the driver chain is
>merely a conincedence.

This brings up a somewhat related question.  I have two floppy drives, a
hard disk with two partitions (C: and D:), and a ram drive (E:).  I want to
make a separate boot partition but with a drive letter other than C.  Since I
gather this is not possible as such, I thought of simply (?) having a
program run at boot time which changes the drive letters in the CDS array such
that the normal C: is something else and I can rename another partition C:.

The question:  Is this possible?  Do I merely have to change drive letters
in the CDS, or would it be necessary to swap entire array structures to
maintain the proper order?

Thanks!

Doug Lee  (dgl292@athenanet.com or uunet!pallas!dgl292)