X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Rotes Sapiens Newsgroups: comp.os.msdos.djgpp Subject: Re: DOS memory allocation Date: Sat, 03 Apr 2004 12:34:20 +0930 Message-ID: <2j8s601klsefgt1aig9nnoogeu6641965n@4ax.com> References: <0e6401c41033$bf95f970$0600000a AT broadpark DOT no> X-Newsreader: Forte Free Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Chariot Internet - http://www.chariot.net.au X-Original-NNTP-Posting-Host: 127.0.0.1 Lines: 39 NNTP-Posting-Host: 203.87.95.150 X-Trace: 1080961551 lon-reader.news.telstra.net 93296 203.87.95.150 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Mon, 22 Mar 2004 18:33:11 +0100, "Gisle Vanem" wrote: >Does DOS function 58h have any effect on DPMI function 100h >on how it allocates memory? AFAICS it always does low-memory >with first fit. >When shelling out of a djgpp program that allocates DOS-mem, I >sometime see that there is a big hole where the block was freed. >From mapmem under Windows-XP: >0741 5 24,624 4DOS -wdebug D9 DA E4 >0752 1 34,720 DOSX 1B D9 DA E4 FE >28A7 2 20,288 LYNX -wdebug > 1 57,600 --free-- << block that was freed in Lynx >2DB9 2 4,352 4dos << resident portion of 4DOS >But mostly there's no hole in the memory range. >Lynx calls _go32_dpmi_allocate_dos_memory with the same size >every time and _go32_dpmi_free_dos_memory before shelling out >with system(). >Anybody know why NTVDM does this? And if DOS fn 58h can fix this? Are you running cwsdpmi v5? This can have a big effect on things compared to using the Windows inbuilt dos dpmi service. When a free() is done, djgpp (and many other compilers) don't release the mem back to the operating system. The mem is held as free mem by djgpp, other programs can't use it. Only when the program exits is the memory released back to the operating system. In theory the memory is used on a first free basis, but in practice it seems to be allocated at random. There's no garbage collection in most C compilers (although it can be added), so the program could have a large chunk of the memory free but not available to the operating system. Does that answer your question? Sig: You know, a lot of things, in this world, they make no sense. But now Im here, everthing make no sense.