From: j DOT aldrich6 AT genie DOT com
Message-Id: <199607192348.AA122730138@relay1.geis.com>
Date: Fri, 19 Jul 96 23:34:00 UTC 0000
To: wesseling AT frw DOT ruu DOT nl
Cc: djgpp AT delorie DOT com
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: spawning 16 bit DPMI apps

Reply to message 3421605    from WESSELING AT FRW on 07/19/96  1:03PM


>It seems that CWSDPMI.EXE is still in control since it says:
> Sorry, no 16 bits etc ..
>
>Is there any construction possible that tells CWSDPMI.EXE to get
>out of the way, from within an DJGPP app?

Unfortunately, no.  It is simply not possible to mix 16-bit and 32-bit DPMI
apps under the DPMI 0.9 spec.  If you can rebuild your code in 32-bits,
you can of course use it with DJGPP if you want to.  It is also possible
to spawn real-mode programs from DJGPP.

For more details, see FAQ sections 6.7 and 17.6.

>The philosophical question is maybe what is an executable image.
>execlp replaces teh executable image. Which is from the point
>of view of a DOS extender something different then from an DOS app:
>image = application code + extender. Hmm, I don't bother:
>Any dirty solutions accepted.

Actually, the way I understand it is as follows:  When you run a DJGPP
app, the 16-bit stub code loads in real modeand looks for existing
DPMI services.  If it doesn't find them, it runs CWSDPMI, which loads
itself into memory as a resident program.  Any protected-mode program
that you call from then on sees that DPMI services are available in the
form of CWSDPMI, and attempts to use them.  When a 16-bit program
does so, however, CWSDPMI recognizes it as such and is unable to
execute it.

BTW, there is no way to unload CWSDPMI from within a pmode program;
even if you could, the program would crash immediately.  This also
applies to system() and exec/spawn() commands, because all they do
is invoke a new shell; CWSDPMI and your program are still resident.

John