papa%USC-CSE@USC-ECL.ARPA (05/13/84)
From: Marco Papa <papa%USC-CSE@USC-ECL.ARPA>
I am submitting to the info-ibmpc library an updated version of exec.asm
(exec2.asm) that fixes some bugs in the original version, and a new version
(exec3.asm) that works with .EXE files. Here are the details:
1. exec2.asm
This is a program that works ONLY with Lattice C .COM files, originally
written by Darrel Plank. The previous version works fine when function 4A
(SETBLOCK) returns successfully, while it crashes the system when SETBLOCK
returns an error condition. For example, when inadvertently run on a
.EXE file, it crashes instead of reporting the "Memory control blocks
destroyed" condition. There are two reasons for this. The register ES is
pushed on the stack and never popped, and registers SP and SS are loaded
with uninitialized data at the end of the routine. The changes in the
file are indicated with ****.
2. exec3.asm
This version works with .EXE files ONLY. These are files linked with C.OBJ
instead of CC.OBJ. The routine has to be changed because of the following:
on SETBLOCK (function hex 4A), register ES must contain the segment of the
PSP for both .COM and .EXE files.
- for a .COM file this is the value in CS when exec() is called (since
for .COM programs all four segment registers contain the segment address
of the initial allocation block, that starts with the PSP).
- for a .EXE file this is the value in CS-10H (the PSP is 100H long)
when exec() is called (since for .EXE programs CS is set to the value
passed by the linker. That is, the beginning of the code segment, which
is also the end of the PSP).
Therefore, in a .EXE program built with Lattice C, if you want to access
anything in the PSP you have to subtract 10H from the CS register.
This produces two changes in the exec() routine. One in the call to
SETBLOCK, that needs the segment address of the PSP, and the other one
when accessing the segment address of the environment, located at offset
hex 2C in the PSP. The changes are indicated with **** in the source.
I originally wanted to produce a single routine that would have worked with
both .COM and .EXE programs, but I could not find any "documented" way to
check, at run-time, if I am running a .EXE or a .COM program, so that I
can properly access the PSP. Any idea?
Marco Papa
ARPA, CSNET: papa.usc-cse@csnet-relay
UUCP: ...!randvax!uscvax!papa
[The INFO-IBMPC Library has been updated to include EXEC2.ASM and EXEC3.ASM
The earlier version of the program has been deleted -ed]broehl@wateng.UUCP (Bernie Roehl) (05/15/84)
So far as I know, there is no 100% reliable way of determining (at run
time) whether you were loaded as a .COM or a .EXE file. However, if all
four of your segment registers contain the same value, it's a pretty good
bet you entered this world as a .COM.
--
-Bernie Roehl (University of Waterloo)