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.