Date: Fri, 15 Jan 1999 03:54:58 +0000 (GMT) From: George Foot To: djgpp AT delorie DOT com Subject: Re: UNchain_protected_mode_interrupt_vector? In-Reply-To: <369E02C7.A7206CB1@giganet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Thu, 14 Jan 1999, Harold Roman wrote: > So it seems that the "chain" function creates the wrapper. AFAICS it is allocated in the same way as the wrapper allocated by _go32_dpmi_allocate_iret_wrapper, so the _go32_dpmi_free_iret_wrapper function should be able to free it -- but I didn't check whether or not this is a good idea. > I observed that memory is disapearing faster than a 100 > bytes at a time. I put calls to > _go32_dpmi_remaining_virtual_memory around the "chain" > function and I observed that some times no memory is > consumed, other times 64KB is lost. (Perhaps this really a > memory fragmentation problem?) When your program, or parts of libc, call malloc (in libc) it needs to get the memory from the DPMI server. Even if you only allocate 100 bytes, it will get the memory in chunks of 64K. It will satisfy further requests from that block until it is all used up, and then it will go back to the DPMI server and ask for another 64K chunk. The function you're using to measure free memory is a DPMI function -- it doesn't know anything about what's going on inside libc. As far as it is concerned, there's only an occasional allocation of 64K -- no small allocations at all. -- george DOT foot AT merton DOT oxford DOT ac DOT uk ko cilre fi la lojban -- http://xiron.pc.helsinki.fi/lojban/