Comments: Authenticated sender is From: "George Foot" To: califax AT wupperonline DOT de (Klaus Petzold) Date: Sat, 29 Aug 1998 03:04:02 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Strange results with own maxheapblock()-function Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk CC: djgpp AT delorie DOT com Message-Id: Precedence: bulk On 28 Aug 98 at 21:17, Klaus Petzold wrote: > Hi, > > I tried to write a function, which finds out the size of the largest > block I can allocate on the heap. On my system it gives back > 33558524 bytes, but with "char* ptr = (char *)malloc(size);" it > is possible to allocate 67112956 bytes. Has anyone an idea why > maxheapblock() fails? When you malloc a block, the memory is taken from the DPMI server. When you free it, it is not returned; it is just available for future mallocs. For obvious reasons, it can only satisfy requests for roughly the same amount of memory, because it might not have taken enough from the DPMI server to satisfy larger requests. So what your routine does is allocate a lot of blocks, ranging from small to large, all over the heap -- the smaller blocks are not necessarily being reused when allocating the larger blocks. That's a reason why you might in fact be able to allocate more than this routine says you can (though probably not after running it). This sort of routine is doomed to fail in a DPMI environment. I think I'm right in saying that with CWSDPMI the memory is not paged in until it is actually used, so you can allocate much more than your total available (physical + virtual) memory, so long as you don't actually try to use it all. Part of the problem with this routine is that malloc is a lot more complicated than it appears to your programs. If you want very primitive heap functionality you can call sbrk directly, but that's pretty low-level, and it's best not to mix direct sbrk calls with malloc calls. -- george DOT foot AT merton DOT oxford DOT ac DOT uk