delorie.com is funded by banner ads.
  www.delorie.com/djgpp/v2faq/faq125.html   search  

| Previous | Next | Up | Top |

15.8 How much memory do parent DJGPP programs leave for their child?

Q: How much memory is available when I call the system library function?

A: In the conventional (below 640K mark) memory, you are left with everything which was free before your program started, except what the DPMI host uses. The amount of conventional memory required by the DPMI host depends heavily on the host you use. For the first DJGPP program, QDPMI uses about 97K, CWSDPMI uses about 70K, Windows 3.X only 18 KBytes. Each subsidiary call to system (like in recursive invocation of Make) eats up about 18K (16K for the transfer buffer and 2K for the PSP and environment) for most DPMI servers; a notable exception is QDPMI which needs 97K bytes of low memory for the subsequent calls too. If you change the size of the transfer buffer (with STUBEDIT), the amount of free conventional RAM left when shelling out of it will change accordingly.

Extended memory management is left to the DPMI server; DJGPP does nothing special about XMS when system is called. This means that all the extended memory used by the parent program is not freed when the child program starts; if the child requests more memory than is physically free, the DPMI server is expected to page some of the parent out to honor the request. (This is unlike DJGPP v1.x, where the go32 extender would completely page out the parent before starting the child.) The advantage of this is that spawning a child or shelling out is much faster in v2 than it used to be with v1.x, except on machines with low amounts of installed RAM. A disadvantage is that if you spawn a real-mode program that uses XMS, the extended memory used up by your DJGPP program will be unavailable to it, unless you use a memory manager (as opposed to when CWSDPMI uses raw XMS or HIMEM). The only way around this problem is to buy more RAM, or to install a real memory manager.

Note that if you use a memory manager such as EMM386 or QEMM386 with the NOEMS and NOVCPI parameters, CWSDPMI will use the XMS (as opposed to VCPI) services to allocate extended memory, and will allocate all of the available XMS memory for itself. So if, while your DJGPP program runs, some resident software such as device driver or TSR will try to allocate XMS, the allocation will fail.


  webmaster   donations   bookstore     delorie software   privacy  
  Copyright ⌐ 1998   by Eli Zaretskii     Updated Sep 1998  

Powered by Apache!

You can help support this site by visiting the advertisers that sponsor it! (only once each, though)