Xref: utzoo comp.sys.ibm.pc:35395 comp.lang.c:22303
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!accuvax.nwu.edu!tank!eecae!netnews.upenn.edu!dsl.cis.upenn.edu!catone
From: catone@dsl.cis.upenn.edu (Tony Catone)
Newsgroups: comp.sys.ibm.pc,comp.lang.c
Subject: Re: Microsoft C - Heap space question
Keywords: heap microsoft-c
Message-ID: <14792@netnews.upenn.edu>
Date: 27 Sep 89 19:19:06 GMT
References: <3631@cbnewsh.ATT.COM> <4143@csd4.csd.uwm.edu>
Sender: news@netnews.upenn.edu
Reply-To: catone@dsl.cis.upenn.edu (Tony Catone)
Distribution: usa
Organization: University of Pennsylvania
Lines: 20

In article <4143@csd4.csd.uwm.edu> chad@csd4.csd.uwm.edu (D. Chadwick Gibbons) writes:
>	One very important note about farmalloc: usually, it will grab memory
>that was not original assigned to the executable when it ran.  Therefore, upon
>normal terminal exit (via exit) this memory _will not_ be returned to the
>operating system.  To avoid "Insufficent Memory" errors later down the road,
>be sure to explicitly free this allocated memory.  I believe farmalloc has a
>corresponding free function called farfree, but check for user's guide to be
>exact on it's usage.

Is this really true?  I thought that DOS automatically allocated all free
system memory (not expanded or extended) to the currently executing program.
At least this is the way it worked when I used the EXEC call from assembly
language in DOS's 2.1 and 3.1; before you could spawn a child process, you 
had to explicitly deallocate memory.  I also believe I just recently saw an
article in the MicroSoft Systems Journal that used this same technique.
Does using C make a difference in this behavior?

- Tony
  catone@dsl.cis.upenn.edu
  catone@wharton.upenn.edu