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