Where is the entry point CS:IP?

[Rogare]

Hi,
I'm trying to find the entry point of a 16-bit program's .exe file, without opening it with a tool like TD.
I found the IP in the 21st byte, but couldn't find the CS.
I suspect it might be dynamic, and that CS is set only when the program is loaded onto the memory, but I want to be on the safe side before I do crazy things.
Thanks,
Rogare.

[sinsi]

> I suspect it might be dynamic, and that CS is set only when the program is loaded onto the memory

Yes, the MZ header contains CS:IP, the value for CS is relocatable, so it is a paragraph offset from the PSP, same for SS:SP.

[Rogare]

Thanks!
Another sort-of related question.
I have a .asm file which ends with:

Code Select Expand

__start: int 3h
__table db 01h
dw seg nullsetup, offset nullsetup
end __start
I assemble the file, and give the result to my other .exe file as a command line argument.
I want this file to open the first .exe (using int 21h/3Dh) and then to execute "nullsetup".
How can I do that?

[FORTRANS]

Thanks!
Another sort-of related question.
I have a .asm file which ends with:

Code Select Expand

__start: int 3h
__table db 01h
dw seg nullsetup, offset nullsetup
end __start
I assemble the file, and give the result to my other .exe file as a command line argument.
I want this file to open the first .exe (using int 21h/3Dh) and then to execute "nullsetup".
How can I do that?

Hi,

   The normal way to execute/run a child program is
through the use of Fn 4BH subfunction 0 (AX = 04B00H).
You create a "LOADEXEC" structure, point DS:DX to a
string containing the filename, point ES:BX to the structure,
and execute Int 21H/4BH.

   Fn 3DH is the "open file with handle" function.  You could
then read a *.COM file into your memory, and execute it.
But that has problems with program termination.  To run
an *.EXE file you would have to write a relocating loader to
do what MS-DOS does to load and run the file.

HTH,

Steve

[Rogare]

Thanks for your reply!
Umm... I see that 21/4B01 is Load but do not execute, could I do that as well? I just want to call some of the procedures in the file, not run it.
I could put a call for an interrupt in the file and hook this interrupt, but seems a bit patchy (maybe it isn't - my experience with advanced ASM programming is limited).

[FORTRANS]

Hi,

Thanks for your reply!

   You're welcome.

Umm... I see that 21/4B01 is Load but do not execute, could I do that as well? I just want to call some of the procedures in the file, not run it.

   Well, probably.  It would depend on what the program does
to initialize things and the program flow.  If you know enough
about the routines to use them, why not include them in your
program?  I guess the easiest way to find out is to try it out.

I could put a call for an interrupt in the file and hook this interrupt, but seems a bit patchy (maybe it isn't - my experience with advanced ASM programming is limited).

   Not sure what you mean here.  Run the program with your
program as a shell or TSR and try to gain control?  That could
work, I used a TSR to fix a Y2K problem for instance.  But for
realistic control, this looks poor.  And the Microsoft programmer's
reference says some things in the discussion of Int 21H / 4B05H,
set execution state, that sounds like the system may be in a
fragile state if you try almost anything useful with an interrupted
program.

Regards,

Steve N.

[Rogare]

Umm... I see that 21/4B01 is Load but do not execute, could I do that as well? I just want to call some of the procedures in the file, not run it.

   Well, probably.  It would depend on what the program does
to initialize things and the program flow.  If you know enough
about the routines to use them, why not include them in your
program?  I guess the easiest way to find out is to try it out.

This is a program I wrote, I know it well. Cannot include because I need dynamic linking (on each run I use a different version of the file, and I don't want to re-assemble whenever I write a new version - waste of both time and space).

[FORTRANS]

Hi,

   Okay, what you are doing in essence is loading code as an
overlay to get your different versions.  You should be good to go.
You might try the Int 21h/4B03H load overlay.

Regards,

Steve N.

[Rogare]

Do you know any examples?
I got no idea what to do after the interrupt call (of 21/4B03).

[FORTRANS]

Hi,

   Amusing.  I tried to create an example using a Fn 4B03
call.  If I try to load a non-existant file I get an error (carry
flag set).  If I try to load a real file (.OBJ, .EXE, or .COM)
I get no error, but nothing is loaded.  At least not where I
asked it to load.  (A small file into my data segment.)  Any
comments guys?

   In a Waite Group book "MS-DOS Developer's Guide" there
is a paragraph on using LINK to create overlays.  No real
discussion on any preparation though.  And trying the standard
random programming techniques locked up the computer.

   In my PowerStation FORTRAN documentation there is a
mention of overlays in the index, but nothing in the text.  In
my DOS 3.0 and associated Programmer's Utility Pack
documentation, there is a discussion of "overlay manager"
overlays in the LINK.EXE sections.  First attempts along
those lines are in progress. So far requires using LINK and
LIB (from MASM 5.0 for now) to work anything at all.  The
program created is different from a standard program
without the extra command line LINK stuff.

   Oh well, more amusement ahead I guess.  If I get it to
work I may work up an example to post.  Something fishy
going on in LINK so far.

Cheers,

Steve N.

Edit:  Corrected a document reference.  Also the LINK from
MASM 5.0 just supressed error messages and did not work
in any case.  See later post.

SRN

[dedndave]

i suspect some of the mechanisms to handle DOS overlays are absent in newer OS's
so - not sure it's worth too much effort to learn it - lol
but, if i wanted to figure it out....
.... i would take some old program that uses overlays and see how it was put together

[tenkey]

Most DOS linkers defaulted to allocating all of free DOS space on startup, so one of the things you needed to do before loading a second program was to release some memory first. Or you could just set the linker up to allocate the minimum required memory space.

[dedndave]

good point, tenkey
as i recall, .COM programs own all the memory up to the 640K boundry, so you must free some first
.EXE programs own all that is required to accomodate the code, data, and stack space specified in the EXE header
i think there is a DOS function you can call to see how much is available (don't remember - lol)
if not, you can chase the heap allocation header blocks (paragraphs) to the end of 640K

[japheth]

i suspect some of the mechanisms to handle DOS overlays are absent in newer OS's

No - because the mechanisms are all supplied by the executable. You told the linker that you want overlays and then  it added a module - the "overlay manager" - during the link step to your object modules, which later, at runtime, did the work required to manage overlays.

The MS "overlay manager", included by the MS OMF linker, replaced all far calls into other overlays by code sequence CD 3F XX OOOO ( INT 3Fh, followed by "overlay number" XX, and then the 2 byte offset within the overlay).

[clive]

The overlays the linker generates are placed in the same EXE, each has it's own MZ header and code.

The syntax for the 16-bit linker went something like this,

Code Select Expand

LINK /SEG:250 /NOE /STACK:8000 main.obj (thing1.obj) (thing2.obj) bit1.obj (thing3.obj) (thing4a.obj thing4b.obj thing4c.obj),main.exe,main.map,lib1.lib lib2.lib,

It figure things out automatically, and made a hole in memory big enough to pull in each individual overlay (ie big enough to hold the largest footprint).

Most of it was invisible. There are a couple of examples for using 4B03h in the context of loading device drivers from the command line.