Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!wookumz.ai.mit.edu!entropy From: entropy@ai.mit.edu (entropy) Newsgroups: comp.sys.atari.st.tech Subject: Re: g++ Part comment, part question. Message-ID: Date: 1 Mar 91 08:21:09 GMT References: <10745@jarthur.Claremont.EDU> <1991Feb1 <1991Feb28.133252.8714@uwovax.uwo.ca> Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius) Organization: /home/fsg/entropy/temporary/.organization Lines: 25 In-Reply-To: 7103_2622@uwovax.uwo.ca's message of 28 Feb 91 18:32:52 GMT In article <1991Feb28.133252.8714@uwovax.uwo.ca> 7103_2622@uwovax.uwo.ca (Eric Smith) writes: In article , entropy@ai.mit.edu (entropy) writes: > By the way, has anyone noticed that certain programs (such as the CPM > emulator) completely ignore 'limit' and snarf all of memory anyway? There are two different flags for limiting memory: -M and -m. One of them (I forget which) limits the amount of memory the process can Malloc; the other limits the total amount of memory the process can have. Some programs never use Malloc or Mshrink; they just keep all the memory they're given on startup -- for them, you have to use the latter flag. Please, Eric, give me some credit (I do know how to RTFM if nothing else). I've tried both flags independently and in conjunction and neither has any effect on the CP/M emulator. I could swear I noticed another program that acted similarly but I can't for the life of me think of what it was right now. In any case, I seriously doubt this indicates a problem with limit. It's probably just that the emulator does something really stupid (and likely illegal) to allocate its memory. If anyone's had any better luck getting the emulator to use less memory, please let me know. entropy