Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!sdd.hp.com!caen!sol.ctr.columbia.edu!lll-winken!iggy.GW.Vitalink.COM!widener!dsinc!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!ralf
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.os.msdos.programmer
Subject: Re: Writing a device driver in TP
Message-ID: <28524450@ralf>
Date: 9 Jun 91 15:08:00 GMT
Organization: Carnegie Mellon University School of Computer Science
Lines: 18
In-Reply-To: <7e3131w164w@spocom.guild.org>
Originator: ralf@B.GP.CS.CMU.EDU

In article <7e3131w164w@spocom.guild.org>, luns@spocom.guild.org (Luns Tee) wrote:
}but I have yet to hear a list of version numbers. I don't think it was 
}very clear-cut, but I'd imagine it was only in certain 1.x and 2.x 
}versions.

The program loader in in COMMAND.COM for all versions 1.x (both PC- and MS-
DOS), since there is no EXEC function call.  PC-DOS 2.x puts the EXEC code
into COMMAND.COM, but not PC-DOS 3.x or any MS-DOS 2.x or higher.  The
PC-DOS code consists of a short stub in the resident portion of COMMAND.COM,
with the actual loader in a *second* transient portion of COMMAND.COM.	As
a result, COMMAND.COM needs to be available, as the EXEC program loader
must first load itself from disk each time it is called.

-- 
{backbone}!cs.cmu.edu!ralf  ARPA: RALF@CS.CMU.EDU   FIDO: Ralf Brown 1:129/53
BITnet: RALF%CS.CMU.EDU@CARNEGIE   AT&Tnet: (412)268-3053 (school)   FAX: ask
DISCLAIMER?  Did  | It isn't what we don't know that gives us trouble, it's
I claim something?| what we know that ain't so.  --Will Rogers