What is the "com" in "sb16cqa.com"? - OS2

This is a discussion on What is the "com" in "sb16cqa.com"? - OS2 ; 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> ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: What is the "com" in "sb16cqa.com"?

  1. What is the "com" in "sb16cqa.com"?

    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.


  2. Re: What is the "com" in "sb16cqa.com"?

    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.

  3. Re: What is the "com" in "sb16cqa.com"?

    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.

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

  4. Re: What is the "com" in "sb16cqa.com"?

    "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


  5. What is the "com" in "sb16cqa.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.


  6. What is the "com" in "sb16cqa.com"?

    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.


  7. Re: What is the "com" in "sb16cqa.com"?

    "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).




  8. Re: What is the "com" in "sb16cqa.com"?

    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

  9. Re: What is the "com" in "sb16cqa.com"?

    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

  10. Re: What is the "com" in "sb16cqa.com"?

    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



  11. Re: What is the "com" in "sb16cqa.com"?

    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

+ Reply to Thread