Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

.COM files or .EXE?

1 view
Skip to first unread message

Chad Beattie

unread,
May 16, 1998, 3:00:00 AM5/16/98
to

Could anyone tell my why you would want to use a com file over an exe file
or vise versa? What are advantages and disadvantages of either one? Thanks


D. Speir

unread,
May 16, 1998, 3:00:00 AM5/16/98
to

Com files were first in the world of dos. They are becoming a thing of the past.
Com files load faster than Exe files since there is no relocation for the loader
to take care of. They are an exact memory image on disk. Com files must have
code in them to release the rest of conventional memory or you won't be able
to spawn any more programs since dos granted all of conventional ram to them.
Exe files can be compiled to do this on loading. Dos looks for com files before
exe files (or it did thru dos 6.2 ). If you had two files named the same name but
one had a com extension and the other an exe, and you typed the filename at
the prompt, the com file would run not the exe. Some people erroneously thought
that if you typed the extension the exe file would run. It won't. However if I
remember right you can rename an exe file to have the com extension and will run,
and it will load correctly too since the loader simply reads in the relo from the header
without remembering it was just passed a com file, and will load it just like an exe file.
Com files are still used in real/virtual86 tsr programming. Com files or "tiny models" are
sometimes referred to as kinda like Flat Models. But kinda is about it. Flat model progs
have code and data seg (even though they both start at zero ), Flat win32 models have relo
provisions for static data and dynamic linked code in even though it's much different than
the dos or win16 loading. So a little bit of Tiny + little bit of Small + some different relo
technics = Flat.
end.

Will DeWitt

unread,
May 17, 1998, 3:00:00 AM5/17/98
to

Chad Beattie wrote in message <6jkt97$oa0$1...@winter.news.erols.com>...

>Could anyone tell my why you would want to use a com file over an exe file
>or vise versa? What are advantages and disadvantages of either one?
Thanks


COM files are usually faster and smaller, but are limited to 64k total for
code, data and stack space. EXE files are multi-segmented, and calls to
routines in other segments generate larger code (since passing the seg:ofs
is required, unlike a COM, which goes directly to the offset).
Will

Richard Kanarek

unread,
May 18, 1998, 3:00:00 AM5/18/98
to

Greetings.

Regarding...


Will DeWitt wrote:
> COM files are usually faster and smaller, but are limited to 64k total for
> code, data and stack space. EXE files are multi-segmented, and calls to
> routines in other segments generate larger code (since passing the seg:ofs
> is required, unlike a COM, which goes directly to the offset).
> Will

As I recall-- and please don't hesitate to correct me if I'm mistaken:
a. Programs stored in .COM file format are perfectly welcome to have
more than 64k of code, data, & stack space; it just needs to be
allocated dynamically. That is, you can have a disk buffer, for example,
of several hundred kilobytes as long as you allocated it at run time
rather than reading it from the pgrm file (which you'd be unlikely to do
anyway). Similarly, if you wanted to load an additional overlay or
overlay like file at run time-- you'd be most welcome to do so too.
b. Regarding "EXE files are multi-segmented and calls to routines in
other segments generate larger code..." I think your debating the
relative merits & costs of far code vs. near code memory models. While
it would be unlikely for a program in a .COM file format to use far
code, it isn't impossible. The suggestion, however, that .EXE pgrms use
far code exclusively or even predominately seems quite unjustified.

Regarding the original question:


"Could anyone tell my why you would want to use a com file over an exe
file
or vise versa? What are advantages and disadvantages of either one?"

I think the answer it that .COM programs simply lend themselves to
"tiny" programs if for no other reason than that they are programed in a
memory model called "tiny" and they are smaller than there similar .EXE
counterparts by virtue of not having the .EXE header. Do note that for
applications programs, the difference was probably largely insignificant
even in the XT days (which, for me was just yesterday as my "main"
computer is a Turbo XT (H/Z-158)<g>).


Cordially,
Richard Kanarek

P.S. Note to the original poster: Didn't you go rather wild
cross-posting your original post?


0 new messages