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!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!cornell!uw-beaver!tektronix!hplabs!qantel!dual!lll-crg!gymble!umcp-cs!seismo!harvard!talcott!lotto
From: lotto@talcott.UUCP (Jerry Lotto)
Newsgroups: net.micro,net.micro.pc
Subject: Microsoft version MASM + utils 3.0 problems
Message-ID: <463@talcott.UUCP>
Date: Fri, 12-Jul-85 00:38:32 EDT
Article-I.D.: talcott.463
Posted: Fri Jul 12 00:38:32 1985
Date-Received: Thu, 11-Jul-85 06:38:10 EDT
Distribution: net
Organization: Harvard Univ. Chem. Dept.
Lines: 25
Xref: watmath net.micro:10953 net.micro.pc:4494


	After a recent posting complaining about the environment
space patch to DOS 3.1 not working with the Microsoft program
MAPSYM, I tried a few experiments. Apparently (under PC_DOS 3.1
on an IBM-PC AT), mapsym is not too tolerant of any environment
expansion. No matter how you do it (normal growth or patching),
MAPSYM works fine when the environment is 14 paragraphs and bombs
with a 'Stack Overflow' when the environment is 15 paragraphs
long. In fact, if you delete some stuff from the environment
after one of these 'Stack Overflow's, everything will come back
to normal and the program will run again.
	My negative experience with the Symbolic Debugger seems to
stem from a similar problem, although I have yet to give that a
complete workout. Since MS-DOS can have up to 32K reserved for
environment space, I was quite surprised by these results. If
there are any other people who are running different
hardware/software combinations that can try this, I would like to
know what the scope of the problem is.
-- 

Gerald Lotto - Harvard Chemistry Dept.

 UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
 ARPA:  lotto@harvard.ARPA
 CSNET: lotto%harvard@csnet-relay