lotto@talcott.UUCP (06/13/85)
KERMIT 2.28 has revealed a possible problem with DOS 3.1.
The .EXE file header describes segments for loading, and the map
confirms that there is a stack segment allocated C8H bytes long,
(I'll use absolute addresses for my machine for ease) in segment
20EEH. Great, the loader (command.com) loads everything correctly
and initializes the ss:sp pair to 20EE:00C8. The problem comes in
when a DOS call 48H (allocate memory block) is made. Unlike a .COM
file, the stack of an .EXE file should be respected by DOS as
previously allocated memory. However, calling function 48H with an
argument of F00H paragraphs (in this case) returns a segment address
of 20EF which of course will end up colliding with the top B8H bytes
of stack. Are we supposed to preallocate stack space in .EXE files?
If not, what is going on here. This apparently does not happen in
previous DOS versions, although I have not tried it.
Please respond by direct mail for speed, I will summarize
for the net if the problem is solved. I sure hope that it is some-
thing that I am doing wrong, otherwise, this is bad news....
Thanks
(P.S. preliminary bug reports have gone in to CU20B already)
--
____________
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