Xref: utzoo comp.lang.pascal:5457 comp.sys.ibm.pc.misc:6562
Newsgroups: comp.lang.pascal,comp.sys.ibm.pc.misc
Path: utzoo!utgpu!watserv1!maytag!watstat.waterloo.edu!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Subject: Re: Turbo Pascal/DOS Batch Heap Peculiarity
Message-ID: <1991Feb16.214924.27449@maytag.waterloo.edu>
Keywords: pascal, batch, heap
Sender: daemon@maytag.waterloo.edu (Admin)
Organization: University of Waterloo
References: <296@cogsci.ucsd.EDU>
Date: Sat, 16 Feb 1991 21:49:24 GMT
Lines: 33

In article <296@cogsci.ucsd.EDU> miller@cogsci.ucsd.EDU (Jeff Miller) writes:

>Here's a peculiarity that's new to us, and we hope someone can help us
>understand it.  The symptoms are easy to observe:
...
>3.  Run the batch files, and they report different HeapOrg's!!!!!!
>
>Anyone know why this is?  (Choose one from column A and one from column B)
>    A       B
>   DOS     Bug
>  Turbo    Feature

It looks to me like a property of DOS, not really a bug or a feature.  The
test program is being loaded at a different place, lower in memory, when
the batch file has no more lines in it.

>Any suggestions on how to handle this problem?
>The peculiarity becomes a problem when we run, inside batch files, programs
>that use the heap-- if we forget that final carriage return, there goes the
>FAT table.

I don't see how this can really be a problem.  Are you relying on having
the heap stay unchanged between calls to your program?  That's very dangerous:
the transient part of COMMAND.COM lives up in high memory, and will stomp on
whatever you've left in the heap, after your program terminates and releases
it.

If you really need shared memory between calls, I don't think there's an easier
way than just putting what you want into a file.  You could also write one of
the programs as a TSR so that its heap is never released, but that's 
a lot of work.

Duncan Murdoch