Mail Archives: djgpp/1996/04/10/14:14:24
>As I understand it (and don't quote me here), .COM files don't get
>copies of the environment to work with. They are also supposed to be
>limited in the things they can do, but it's supposedly a tradeoff for
>reduced size.
>
>Am I right? Wrong? Crazy? :)
>
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.
However if, for test purps, you want to make a .COM file, here's
what you can do:
1) run DEBUG
2) use the Assemble command to enter in a few DOS ints or
whatever you need to do
3) use the N cmd to name the .COM file, like NFOO.COM
4) I *believe* the next step is to set the CX reg, via
the R cmd, w/ the nbr of bytes you just assembled
5) Finally use the W cmd, to write out the image
I haven't done this is in years, so confirm the last two
instructions by reading up on DEBUG usg HELP.... Jet
================================================================
In Paris, they simply stared when I spoke to them in French;
I never did succeed in making those idiots understand their
own language. - Mark Twain, The Innocent Abroad,1869
================================================================
- Raw text -