J de Boyne Pollard wrote:
> MT> I can't help with the rest, but *.com was an extension that
> preceded
> MT> *.exe under CP/M, MS-DOS (DR-DOS etc.), and maybe other places.
> MT> It had to do with the executable address space (but I won't
> *even*
> MT> try to remember the details... beyond 0x100h, that is ;-)
>
> Actually, on MS/PC-DOS (version 3.x and later, at least), Novell/DR-
> DOS (all versions), OS/2 (all versions), and Windows NT (all
> versions), the extension portion of the filename has _nothing
> whatsoever_ to do with the executable file format. None of the system
> API functions for executing programs on those operating systems pay
> any attention to the filename in order to determine the executable
> program image format. That *.COM files sometimes contain program
> images in the "COM" file format is largely an accident of history
> rather than any sort of requirement that the file format be embodied
> in the filename. Indeed, there is at least one DOS where all of the
> supplied program image files, *.EXE and *.COM alike, are "MZ" format
> executables. And, of course, native executables on OS/2 and Windows
> NT, in files named *.COM and otherwise, don't use the "COM" file
> format at all.
>
> The only thing determined by the filename is that *.COM conventionally
> precedes *.EXE in the extension search order used by the various
> incarnations (IBM's, Microsoft's, Novell's, FreeDOS', ReactOS', and
> mine) of COMMAND and CMD when searching for program image files and
> script files. Thus a file named *.COM will be loaded, by those
> command interpreters, in preference to a file named *.EXE in the same
> directory. But since most of the recent incarnations (of CMD, at
> least) employ the PATHEXT mechanism, even that isn't universally
> true. And programs other than command interpreters are not bound to
> do any such thing.
>
A com program can be loaded into memory at any paragraph boundary and execute
correctly without any modifications by the loader. In contrast, an exe program
may contain address constants which have to be adjusted by the loader to reflect
where the program has been placed in memory.

In alt.folklore.computers "James J. Weinkam" wrote:

>J de Boyne Pollard wrote:
>> MT> I can't help with the rest, but *.com was an extension that
>> preceded
>> MT> *.exe under CP/M, MS-DOS (DR-DOS etc.), and maybe other places.
>> MT> It had to do with the executable address space (but I won't
>> *even*
>> MT> try to remember the details... beyond 0x100h, that is ;-)
>>
>> Actually, on MS/PC-DOS (version 3.x and later, at least), Novell/DR-
>> DOS (all versions), OS/2 (all versions), and Windows NT (all
>> versions), the extension portion of the filename has _nothing
>> whatsoever_ to do with the executable file format. None of the system
>> API functions for executing programs on those operating systems pay
>> any attention to the filename in order to determine the executable
>> program image format. That *.COM files sometimes contain program
>> images in the "COM" file format is largely an accident of history
>> rather than any sort of requirement that the file format be embodied
>> in the filename. Indeed, there is at least one DOS where all of the
>> supplied program image files, *.EXE and *.COM alike, are "MZ" format
>> executables. And, of course, native executables on OS/2 and Windows
>> NT, in files named *.COM and otherwise, don't use the "COM" file
>> format at all.
>>
>> The only thing determined by the filename is that *.COM conventionally
>> precedes *.EXE in the extension search order used by the various
>> incarnations (IBM's, Microsoft's, Novell's, FreeDOS', ReactOS', and
>> mine) of COMMAND and CMD when searching for program image files and
>> script files. Thus a file named *.COM will be loaded, by those
>> command interpreters, in preference to a file named *.EXE in the same
>> directory. But since most of the recent incarnations (of CMD, at
>> least) employ the PATHEXT mechanism, even that isn't universally
>> true. And programs other than command interpreters are not bound to
>> do any such thing.
>>
>A com program can be loaded into memory at any paragraph boundary and execute
>correctly without any modifications by the loader. In contrast, an exe program
>may contain address constants which have to be adjusted by the loader to reflect
>where the program has been placed in memory.

Mainly a .COM file is small enough to fit in one segment; particularly
inside the 640K limit of DOS. There are a few other constraints as
well; but size is the biggest one. You load a completely different set
of libraries for a .COM file than a .EXE file.

A .EXE file can be any size up to 4 gigabytes.

--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_

"James J. Weinkam" wrote:
>
.... snip ...
>
> A com program can be loaded into memory at any paragraph boundary
> and execute correctly without any modifications by the loader. In
> contrast, an exe program may contain address constants which have
> to be adjusted by the loader to reflect where the program has been
> placed in memory.

A .com program is an exact memory image of the running code and
initialized data. It must be loaded in x86 mode into the bottom
640k of memory. The PSP starts at address 0, and extends to 100h,
where the actual code begins. That 100h is also the entry point.
The diskfile holds the code form 0100h up. At initialization the
code seizes all the base memory, so if you want to make memory
available for other things (such as this item is a TSR) you have to
release it first.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.




--
Posted via a free Usenet account from http://www.teranews.com

JJW> A com program can be loaded into memory at any paragraph
boundary
JJW> and execute correctly without any modifications by the loader.
In contrast,
JJW> an exe program may contain address constants which have to be
adjusted
JJW> by the loader to reflect where the program has been placed in
memory.

You didn't read what I wrote. Here once again is the important fact
that you are still missing, with emphasis: THE FILE FORMAT IS NOT
EMBODIED IN THE FILENAME. There are _no such things_ as "exe
programs" as you are envisaging them. The "com program"/"exe program"
distinction that you are employing is a false one, that you have
incorrectly inferred from filenames. You are far from the only person
to get this wrong. Even Pat Villani gets it wrong in xyr book on
Win32 programming, where xe writes about "COM files", "EXE files", and
"PE files". But wrong it is, nonetheless.

The (relevant) file formats are (colloquially) "COM format", "MZ
format" (Mark Zbikowski), "NE format" (New Executable), "LE
format" (Linear Executable), "LX format" (Linear Executable), and "PE
format" (Portable Executable). Filenames have _no bearing whatsoever
upon the file format_. (As I wrote before: There is at least one
version of DOS where all of the executable files are in the MZ file
format, irrespective of whether they are named *.COM or *.EXE. And
native executables in OS/2 and Windows NT may have *.COM names but,
even so, don't use the COM format.) The idea that there is a
"COM"/"EXE" dichotomy, let alone Villani's "COM"/"EXE"/"PE"
trichotomy, is false.

FM> Mainly a .COM file is small enough to fit in one segment;
particularly
FM> inside the 640K limit of DOS. There are a few other constraints
as
FM> well; but size is the biggest one. You load a completely
different set
FM> of libraries for a .COM file than a .EXE file.
FM>
FM> A .EXE file can be any size up to 4 gigabytes.

Wrong. BOTH *.COM files and *.EXE files can be that large. The
relevant factor is the actual executable file format, WHICH IS WHOLLY
DIVORCED FROM THE FILENAME. The "COM"/"EXE" dichotomy based upon
filenames that you are propounding does not exist. It is a false
inference, that does not match what operating systems and command
interpreters actually do. Please read what I wrote, again. I did
explain this.

"J de Boyne Pollard" wrote in message
news:1189530062.219685.214450@57g2000hsv.googlegro ups.com...
>
> You didn't read what I wrote. Here once again is the important fact
> that you are still missing, with emphasis: THE FILE FORMAT IS NOT
> EMBODIED IN THE FILENAME.

Of course, but it *is* customary to use the .COM suffix for COM-format
(non-relocatable) executables, and .EXE for all the kinds of relocatable
executables. As many of us discovered in very early DOS days, they all run
just fine if you give them the "wrong" suffixes.

My recollection is that, historically, the ending .COM comes from CP/M (as
does the basic idea of the file format with which it was normally used).

In article <1189530062.219685.214450@57g2000hsv.googlegroups.c om>,
J de Boyne Pollard wrote:
>JJW> A com program can be loaded into memory at any paragraph
>boundary
>JJW> and execute correctly without any modifications by the loader.
>In contrast,
>JJW> an exe program may contain address constants which have to be
>adjusted
>JJW> by the loader to reflect where the program has been placed in
>memory.
>
>You didn't read what I wrote. Here once again is the important fact
>that you are still missing, with emphasis: THE FILE FORMAT IS NOT
>EMBODIED IN THE FILENAME. There are _no such things_ as "exe
>programs" as you are envisaging them. The "com program"/"exe program"
>distinction that you are employing is a false one, that you have
>incorrectly inferred from filenames. You are far from the only person
>to get this wrong. Even Pat Villani gets it wrong in xyr book on
>Win32 programming, where xe writes about "COM files", "EXE files", and
>"PE files". But wrong it is, nonetheless.
>
>The (relevant) file formats are (colloquially) "COM format", "MZ
>format" (Mark Zbikowski), "NE format" (New Executable), "LE
>format" (Linear Executable), "LX format" (Linear Executable), and "PE
>format" (Portable Executable). Filenames have _no bearing whatsoever
>upon the file format_. (As I wrote before: There is at least one
>version of DOS where all of the executable files are in the MZ file
>format, irrespective of whether they are named *.COM or *.EXE. And
>native executables in OS/2 and Windows NT may have *.COM names but,
>even so, don't use the COM format.) The idea that there is a
>"COM"/"EXE" dichotomy, let alone Villani's "COM"/"EXE"/"PE"
>trichotomy, is false.

One of NT's problems is that its grandfather had well-understood
definitions of extension names. COM would have been an ASCII
file that contained user mode commands. EXE was the executable
spit out by the linker.

/BAH

jmfbahciv@aol.com writes:

> In article <1189530062.219685.214450@57g2000hsv.googlegroups.c om>,
> J de Boyne Pollard wrote:
> >JJW> A com program can be loaded into memory at any paragraph
> >boundary
> >JJW> and execute correctly without any modifications by the loader.
> >In contrast,
> >JJW> an exe program may contain address constants which have to be
> >adjusted
> >JJW> by the loader to reflect where the program has been placed in
> >memory.
> >
> >You didn't read what I wrote. Here once again is the important fact
> >that you are still missing, with emphasis: THE FILE FORMAT IS NOT
> >EMBODIED IN THE FILENAME. There are _no such things_ as "exe
> >programs" as you are envisaging them. The "com program"/"exe program"
> >distinction that you are employing is a false one, that you have
> >incorrectly inferred from filenames. You are far from the only person
> >to get this wrong. Even Pat Villani gets it wrong in xyr book on
> >Win32 programming, where xe writes about "COM files", "EXE files", and
> >"PE files". But wrong it is, nonetheless.
> >
> >The (relevant) file formats are (colloquially) "COM format", "MZ
> >format" (Mark Zbikowski), "NE format" (New Executable), "LE
> >format" (Linear Executable), "LX format" (Linear Executable), and "PE
> >format" (Portable Executable). Filenames have _no bearing whatsoever
> >upon the file format_. (As I wrote before: There is at least one
> >version of DOS where all of the executable files are in the MZ file
> >format, irrespective of whether they are named *.COM or *.EXE. And
> >native executables in OS/2 and Windows NT may have *.COM names but,
> >even so, don't use the COM format.) The idea that there is a
> >"COM"/"EXE" dichotomy, let alone Villani's "COM"/"EXE"/"PE"
> >trichotomy, is false.
>
> One of NT's problems is that its grandfather had well-understood
> definitions of extension names. COM would have been an ASCII
> file that contained user mode commands. EXE was the executable
> spit out by the linker.

It was fine in VMS's day. But now there are so many different file
types that aside from a handful of well-known ones every possible TLA
has several file types associated with it.

-- Patrick

On Thu, 13 Sep 2007 02:11:14 UTC, kkt wrote:

> > One of NT's problems is that its grandfather had well-understood
> > definitions of extension names. COM would have been an ASCII
> > file that contained user mode commands. EXE was the executable
> > spit out by the linker.
>
> It was fine in VMS's day. But now there are so many different file
> types that aside from a handful of well-known ones every possible TLA
> has several file types associated with it.

Why the past tense when referring to VMS???

--
Bob Eager

In article <176uZD2KcidF-pn2-5d3xxwRKH32w@rikki.tavi.co.uk>,
"Bob Eager" wrote:
>On Thu, 13 Sep 2007 02:11:14 UTC, kkt wrote:
>
>> > One of NT's problems is that its grandfather had well-understood
>> > definitions of extension names. COM would have been an ASCII
>> > file that contained user mode commands. EXE was the executable
>> > spit out by the linker.
>>
>> It was fine in VMS's day. But now there are so many different file
>> types that aside from a handful of well-known ones every possible TLA
>> has several file types associated with it.
>
>Why the past tense when referring to VMS???
>
Because that's how the owners of the IP treat it.

/BAH