From: j DOT aldrich6 AT genie DOT com
Message-Id: <199604110342.AA171264157@relay1.geis.com>
Date: Thu, 11 Apr 96 03:44:00 UTC 0000
To: djgpp AT delorie DOT com
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Paths and .COM files

Reply to message 1131853    from JETMAN AT GNN DOT CO on 04/10/96  5:25PM


>	John:  The principal diff bet .EXEs and .COMs is that a .COM
>is a simple memory image and an .EXE is a multi-segment image.  .COMs
>generally can do everything that an .EXE can do, it's just that, by
>default, you only start w/ a max of 64K of mem.  That is, your code and
>data for the *image loaded by DOS* must fit into a sgl stmt.  By
>defalt, CS == DS == ES == SS.  This is a remnant from DOS' origin as
>a clone of the 8080/Z80 OS called CP/M.  Now if one's a real bonehead,
>one can subvert this behavior in one's code by creating and usg multiple
>segs, doing custom overlays, etc.  But who'd want to, given the ease
>w/ which one can create .EXEs.  Said another way:  there's almost no
>reason to create .COM files anymore.

Thanks for the info.  Like I said, the only reason I really wanted to do it
was to test the order in which COMMAND.COM looks for files.  I didn't
even really need a working file.  :)

But according to what you have said, isn't DJGPP already compatible
with the .COM format?  The stub program that actually gets loaded is
only 2K - well within the 64K limit.  It handles all the rest of the loading
itself, which is exactly what you just described.  I don't mean to suggest
that there's any reason to do it that way, only that it is possible.

As for there being no reason to make .COMs anymore, heck -- what
about WIN.COM? :)

John