Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mmintl.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!genrad!panda!talcott!harvard!seismo!cmcl2!philabs!pwa-b!mmintl!davido
From: davido@mmintl.UUCP (David Ornstein)
Newsgroups: net.micro.pc
Subject: Re: MSKERMIT is OK, DOS on the other hand...
Message-ID: <456@mmintl.UUCP>
Date: Thu, 20-Jun-85 23:16:21 EDT
Article-I.D.: mmintl.456
Posted: Thu Jun 20 23:16:21 1985
Date-Received: Wed, 26-Jun-85 05:18:19 EDT
References: <452@talcott.UUCP>
Reply-To: davido@mmintl.UUCP (David Ornstein)
Distribution: net
Organization: Multimate International, E. Hartford, CT
Lines: 55


In Article: <452@talcott.UUCP>, lotto@talcott.UUCP (Jerry Lotto) writes:
>
>	First, thank you to the people at CU20B for the suggestion,
>"sounds like your data and stack segments are reversed". You were
>right, they were, and when repaired all went well. However the fix
>was not as simple as reordering the linker args. since I had already
>followed the MSBUILD instructions to a "t".
>
>	MASM 2.0 seems to rearrange segments in object files. This
>is aside from the linker segment organization. MSXDMB did not produce
>an object module with segments CODE, STACK, DATAS; they ended up
>alphabetized by segment type. Changing the class name did not help,
>I had to actually rename the STACK segment to CTACK! I thought that
>the linker had done it, util I saw that the symbol names in the .OBJ file
>appeared sorted. To confirm that the linker behavior was right,
>I linked the original object modules with the DOS 2.1 linker....
>same bug, therefore MASM must be doing something different.
>
>Gerald Lotto - Harvard Chemistry Dept.
>
>UUCP:  {genrad,cbosgd}!wjh12!h-sc4!harvard!lhasa!lotto
>       {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
>ARPA:  lotto@harvard.ARPA
>CSNET: lotto%harvard@csnet-relay

We build our product out of a few hundred modules and use MASM versions from
1.00 all the way up to 2.17.  Segment ordering is important to us.  Most
linkers will order segments in the order that they are received, module by
module.  Later versions of MASM (I'm not sure what version it started with)
mess things up because they order segments in the object file in
alphabetical order.  I assume that this is because they are keeping the
symbol table sorted for efficiency.  What we do is have some segment-order
defining modules at the start of the linker response file.  It goes
something like this:

	
		SEGMNT00.OBJ
		SEGMNT01.OBJ
		    .
		    .
                    .
                SEGMNTnn.OBJ
		MAIN.OBJ
		etc.

	

The MAIN module is your program. The SEGMNTxx modules are simply modules
with empty segment definitions.  The linker will then order the segments in
the order that you have those first few files in your ARF.


				Davido