Mail Archives: djgpp/1996/07/19/19:55:07
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
- Raw text -