Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!ralf
From: ralf@b.gp.cs.cmu.edu (Ralf Brown)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: .SYS (device drivers) that are actually .EXEs?
Message-ID: <9805@pt.cs.cmu.edu>
Date: 4 Jul 90 03:36:34 GMT
References: <j8t1seef8@tmsoft.uucp> <141@qmsseq.imagen.com> <4237@jato.Jpl.Nasa.Gov>
Organization: Carnegie-Mellon University, CS/RI
Lines: 22

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.