.COM style files larger than 64 Kb? (Was: Re: masm .com(PSP) related trouble)
Matthias Paul
>> For your convenience a few excerpts from some in-edit files for
>> the forthcoming RBIL62:
>>
>> --------D-214B-------------------------------
>> INT 21 - DOS 2+ - "EXEC" - LOAD AND/OR EXECUTE PROGRAM
>> AH = 4Bh
| [...]
>> the .COM executable format was not intended to support larger
>> than 64 Kb memory images, however, some DOS issues can deal
>> with larger files to a varying degree.
>> MS-DOS 6.0 will read only the first 64 Kb-PSP of the image
>> in case it would be larger, the stack pointer will be set
>> to SS:FFFEh.
???
| DOS-C (1996) seems to load up to 64 Kb of data with unknown
| consequences for the PSP (wrap around???) and the stack at
| SS:FFFEh-something???
| RxDOS 6.0-7.1.6 will load .COM-format executables into
| memory even when they are larger than 64 Kb, but the stack
| pointer will be created at the end of the first segment,
| and thus will overwrite parts of the image if this has not
| been taken into account.
| PTS-DOS 6.51 and S/DOS 1.1 will completely discard
| .COM-format executables larger than FEFFh bytes (64 Kb-PSP)
| file size.
| [...]
>
> Are you sure? At least in DOS 6.20 (German Version) command.com
> will not execute a com program greater 64K. And I think command.com
> also just uses INT21 AH=4B.
Thanks for the reply. Of course, the shell does use this function.
I just tried it under MS-DOS 7.10 (from Windows 98 SE) and DR-DOS 7.03:
Under MS-DOS 7.10, the prepared .COM file is rejected due to the
API function returning an error (similar to your own observation),
whilst under DR-DOS 7.03 it is accepted. The error messages were
different, but the results were the same under both, COMMAND.COM
and 4DOS.COM.
Unfortunately, I don't have MS-DOS 6.0 and 6.22 here right now
to run cross-checks, but clearly, this needs some more detailed
investigation to track this down. Let's move this into the
news:alt.msdos.programmer group, where I posted a similar
answer under the subject "Run a COM file" on 2002-10-07;
I think it's more on-topic there.
My dumb test file today was derived from a true .COM style file
(not a "MZ" or "ZM" .EXE style file renamed to .COM) and I just used:
COPY /B true.com+true.com huge.com
to create a file image larger than 64 Kb. (The resulting file was
128.666 bytes in size, in case the exact size makes a difference,
somehow.)
Anyone else?
Greeetings,
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
Joe Fischer
Matthias Paul <Matthi...@post.rwth-aachen.de> wrote:
: On 2002-10-08, Herbert Kleebauer wrote:
: My dumb test file today was derived from a true .COM style file
: (not a "MZ" or "ZM" .EXE style file renamed to .COM) and I just used:
:
: COPY /B true.com+true.com huge.com
:
: to create a file image larger than 64 Kb. (The resulting file was
: 128.666 bytes in size, in case the exact size makes a difference,
: somehow.)
:
: Anyone else?
The specification for a MSDOS .COM file states
that Stack, Code and Data segments begin at the same
address, with the first FF bytes containing file info,
and the code starting at 0100 HEX.
This fact restricts the size to one segment,
or 64 k.
There is no minimum size for a .COM file as
long as there is an INT 20H (terminate program)
and an end of file marker.
A .COM file is not restricted to the DOS
Interrupt 21H, but programs that use only that
interrupt will run without modification on most
any MSDOS machine. (There were many machines
that ran MSDOS during the 1980's, but perhaps
not so many now).
By using only INT 21H, text plane video
will work on any machine that runs MSDOS even
if the video memory resides at a different
address than C000 or C800 Hex in the 1st meg.
Some early MSDOS machines used IBM
format floppies, some did not.
Joe Fischer
--
3
Dufflepod
wrote:
>In alt.msdos.programmer
>
>Matthias Paul <Matthi...@post.rwth-aachen.de> wrote:
> There is no minimum size for a .COM file as
>long as there is an INT 20H (terminate program)
>and an end of file marker.
>
Nonsense!
In the first place, you don't need an INT 20h at the end of a .COM
programme, a simple near return will do. Which works because DOS
pushes zero onto the stack before passing control to the COM prog @
0100h, so when it does a return, this loads the IP with 0000, which
conviently points to the 'INT 20h' at offset 0 in the PSP.
This also means, that the smallest size of a COM programme is 1 byte,
namely, C3h, a near return.
As for an end of file marker for a .COM prog, what are you talking
about?! The filesize is stored in the directory entry for the prog.
Dufflepod.
David A. Caabeiro
> or 64 k.
In fact, this restricts com size to 64Kb - 256 bytes
for the PSP...
Regards,
David.
Norm Dresner
news:ao6qq6$jjv9u$1...@ID-84876.news.dfncis.de...
it from using different addresses in the various segment registers so that
a .COM program can -- and some do -- use all of the available memory.
Norm
Joe Fischer
: On 9 Oct 2002 15:53:06 -0400, Joe Fischer <grav...@shell1.iglou.com>
: wrote:
:
: Nonsense!
:
: In the first place, you don't need an INT 20h at the end of a .COM
: programme, a simple near return will do. Which works because DOS
: pushes zero onto the stack before passing control to the COM prog @
: 0100h, so when it does a return, this loads the IP with 0000, which
: conviently points to the 'INT 20h' at offset 0 in the PSP.
:
: This also means, that the smallest size of a COM programme is 1 byte,
: namely, C3h, a near return.
The reason I mentioned it was to compare the
minimum size of an .EXE file, which needs an extensive
header, but I didn't get around to saying that.
The fact that there is an INT 20 at the beginning
of the Program Segment Prefix is just trivia, because
the PSP is not part of the program.
: As for an end of file marker for a .COM prog, what are you talking
: about?! The filesize is stored in the directory entry for the prog.
: Dufflepod.
I like to add an EOF marker to all DOS
files so they can be treated as certain DOS files,
which should have an EOF marker, even if only
to be consistent.
Joe Fischer
--
3
Joe Fischer
David A. Caabeiro <nos...@yahoo.com.ar> wrote:
:> This fact restricts the size to one segment,
:> or 64 k.
:
: In fact, this restricts com size to 64Kb - 256 bytes
: for the PSP...
Right, 65,536 bytes minus the 256 byte PSP which
only exists in core memory.
Joe Fischer
--
3
David A. Caabeiro
> > for the PSP...
> >
> > Regards,
> > David.
> >
> Once a .COM program has started running there's nothing that can stop
> it from using different addresses in the various segment registers so that
> a .COM program can -- and some do -- use all of the available memory.
The OP was refering to COM image size, not its ability to allocate
extra memory.
Regards,
David.
Norm Dresner
Sorry.
Norm
Dufflepod
wrote:
[ S N I P ]
>
>: As for an end of file marker for a .COM prog, what are you talking
>: about?! The filesize is stored in the directory entry for the prog.
>: Dufflepod.
>
> I like to add an EOF marker to all DOS
>files so they can be treated as certain DOS files,
>which should have an EOF marker, even if only
>to be consistent.
>
This is still bollocks. In text mode, typing or copying a file in
cooked, as opposed to raw mode, will stopp at the *text* EOF byte,
which is 1A hex.
But, in a binary file, like a COM, or EXE, or any other non-text file,
a byte value 1Ah can legitimately appear anywhere, and not signify
end-of-file. It can just be the decimal value 26, or the 1st byte of
an SBB opcode, or pretty much any other data value. But and EOF at the
end of a file...... Nah.
Once again - there's no such thing as an EOF marker at the end of a
DOS binary file. So you're not being consistant at all, you're just
plain wrong. Be told.
Dufflepod.