Date:	Tue, 20 Nov 2001 19:14:58 -0500
Message-Id:	<200111210014.fAL0Ew218517@envy.delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	djgpp AT delorie DOT com
In-reply-to:	<3BF5B3EB.2040003@ESTOwanadoo.es> (message from Aitor Santamaria
	Merino on Sat, 17 Nov 2001 00:39:11 GMT)
Subject:	Re: DOS Exec() for COFF-Executables
References:	<3BF5B3EB DOT 2040003 AT ESTOwanadoo DOT es>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> (1) I suppose that the sections are loaded. Now, for COFF executables,
> are EDS and ECS selectors for different segments, meaning that .data and
> .text are loaded into different segments?

No, same segment.  Different selectors.

> (2) Is the stack segment of a program empty when it starts up?

crt0 might put a single word of zero at the top, but otherwise yes.

> Then what would a have? the reply was: relative to 0. Does this mean,
> relative to where you locate .text?

It has the actual offset of the procedure.  "Offset" relative to the
segment, of course.

> Now, how does proc know a's address? Would this be relative to 0,
> meaning relative to where you place .data?

The linker knows where everything goes, because it knows where .data
goes (that's in the coff header).  The DJGPP stub puts .data where the
linker says to put it (within the segment), so everything is in the
right place.  There are no relocations done at run time.

> (4) Finally, how do I know where the main() code starts?  Will EIP in
> the EXE file point to main() relative to .text base location?

No, CS:IP in the exe header point to the stub.  The stub loads the EIP
of the 32-bit image from the COFF header and jumps to it.

- Raw text -