[an error occurred while processing this directive] Node:Swap out, Next:, Previous:EMM386 alloc, Up:Memory

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

Q: How much memory is available when I invoke other programs from my DJGPP program?

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, CWSDPMI uses about 130KB (including 41KB to load CWSDPMI itself), QDPMI uses about 55KB, and Windows only 18 KBytes. Each subsidiary call to system or spawn (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 104K bytes of low memory for the subsequent calls. 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.

In addition, most DPMI servers (with the notable exception of Windows) take up 16KB of expanded memory when they first load.

Extended memory management for the spawned programs is left to the DPMI server; DJGPP does nothing special about XMS when system or spawn 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).

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.

[an error occurred while processing this directive]