Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!apple!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: <141@qmsseq.imagen.com>
Date: 2 Jul 90 15:21:44 GMT
References: <j8t1seef8@tmsoft.uucp>
Reply-To: pipkins@imagen.com (Jeff Pipkins)
Organization: QMS Inc., Mobile, Alabama
Lines: 25

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.