Mail Archives: djgpp/2001/07/24/23:45:15
> The only way I can get [spawning a Pharlap286 application from
> within a DJGPP app] to work is to load the following statement in the
> config.sys:
>
> Device=c:\emm386.exe RAM NOEMS
>
> I believe this is because the Pharlap app cannot talk to the CWSDPMI host,
> but I don't know for sure. (Using EMM386 forces the memory allocations to
> go through EMM386, not through the DPMI host, I think...)
This is exactly correct. When a DJGPP application loads it loads CWSDPMI.
If a VCPI memory provider is not provided CWSDPMI will allocate all the
XMS memory and manage it for DPMI applications. If a non-32-bit-DPMI
protected mode application tries to run, it won't be able to get any XMS
memory (bad things can happen in the raw memory management world). If
EMM386 is present, memory allocation goes through EMM386 which will pool
VCPI and XMS requests and provide mode switching services.
> This is highly undesirable, and I would love a way around it.
No good way, but you could purposely write an application to look at XMS
memory, fragment it on purpose (by allocating say 1Mb, then 1Kb, then
freeing the 1Mb) which would cause CWSDPMI to manage the larger block
leaving the smaller block potentially to the Pharlap application. It
might work, I haven't tried it recently. You would need to know something
about the Pharlap application's memory needs and fragment the memory before
running the DJGPP application. I could probably provide an example if
needed.
- Raw text -