lotto@talcott.UUCP (06/14/85)
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.
Microsoft and Intel already disagree on the way segment
combine types are handled, maybe IBM wants to "set a standard"
by preempting the linker? I hope not, but it would at least be
nice if it behaved the same way as it used to.
Anyway, I still am annoyed that DOS couldn't figure out
that the stack owned C8 bytes of high memory from the .EXE
header. The loader obviously has to know this to initialize SS:SP.
The technical reference manual makes a strong point about .COM
files needing to allocate thier own stack space so it won't
get clobbered. I wonder if I try to allocate a C8 byte block
if DOS won't seek out and destroy that little stack anyway.
What good is memory management with discriminatory wiring
practices?
Responses that would help make some sense out of
these problems (Why did the assembler reorganize things and
why did memory management fail to deal with it anyway?) would
be greatly appreciated. I don't have nearly as much time to
explore as I used to, but the need is much greater...
--
____________
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-relaytj@utcs.UUCP (tj) (06/16/85)
Does this mean that all the versions of MSKERMIT 2.28 out here are going to run into problems in the near future as our users get DOS 3.x? Is a version 2.29 to be made available with the segments re-ordered? t.jpnes
lotto@talcott.UUCP (Jerry Lotto) (06/18/85)
> > Does this mean that all the versions of MSKERMIT 2.28 out here are going > to run into problems in the near future as our users get DOS 3.x? Is a version > 2.29 to be made available with the segments re-ordered? > t.jpnes No. Working versions of KERMIT will work under DOS (anything). The problems are: 1. MASM (IBM versions) will not produce a working KERMIT because it REorders the segments alphabetically (contrary to docs). You either have to use a Microsoft version of MASM, rename STACK (segname) to CTACK (to force proper segment ordering) or build a working version from a .BOO file. 2. The reason that the segments cause problems in the other order has to do with an inconsistancy in DOS memory management that I do not yet under- stand. The correct ordering of segments is the order stated in MSXDMB.ASM for all versions of MS-DOS. -- ____________ 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
davido@mmintl.UUCP (David Ornstein) (06/21/85)
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: <Start of Automatic Response File> SEGMNT00.OBJ SEGMNT01.OBJ . . . SEGMNTnn.OBJ MAIN.OBJ etc. <End of ARF> 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