Message-Id: <199604101807.OAA30152@mail-e2b-service.gnn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Apr 1996 14:12:51 From: Jethro Wright To: djgpp AT delorie DOT com Subject: Re: Paths and .COM files >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 ================================================================