Mail Archives: djgpp/1996/07/19/13:30:28
Xref: | news2.mv.net comp.os.msdos.djgpp:6167
|
From: | Cees Wesseling <Wesseling AT frw DOT ruu DOT nl>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | spawning 16 bit DPMI apps from a DJGPP/CWSDMPI app
|
Date: | Fri, 19 Jul 1996 18:03:47 +0100
|
Organization: | Utrecht University
|
Lines: | 25
|
Message-ID: | <31EFBFF3.5FA34DA9@frw.ruu.nl>
|
NNTP-Posting-Host: | holycow.frw.ruu.nl
|
Mime-Version: | 1.0
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Hi,
I have written an DJGPP app that needs to call an 16 bit DPMI app.
I don't need to do anything after the 16 bit app terminates.
So I thought I could use execlp from the DJGPP app that will
overlay the 16 bit app and it's own 16 bit DPMI extender (rtm.exe
from Borland Pascal 7.0):
execlp("app16", "app16", NULL);
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?
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.
--
Cees Wesseling | PO BOX 80.115 |
Dept. of Physical Geography | 3508 TC Utrecht | phone: (+31) 30 2532768
Utrecht University | the Netherlands | fax: (+31) 30 2540604
- Raw text -