Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84; site talcott.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!genrad!grkermi!panda!talcott!lotto
From: lotto@talcott.UUCP
Newsgroups: net.micro.pc
Subject: MSKERMIT is OK, DOS on the other hand...
Message-ID: <452@talcott.UUCP>
Date: Fri, 14-Jun-85 08:43:05 EDT
Article-I.D.: talcott.452
Posted: Fri Jun 14 08:43:05 1985
Date-Received: Sat, 15-Jun-85 10:15:38 EDT
Distribution: net
Organization: Sociology Dept., Harvard Univ.
Lines: 47


	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-relay