X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
From:	"Rod Pemberton" <dont_use_email AT xnothavet DOT cqm>
Newsgroups:	comp.os.msdos.djgpp,comp.os.msdos.programmer
Subject:	Re: What other DPMI hosts work with DJGPP?
Date:	Sun, 27 Jul 2014 11:55:31 -0400
Organization:	Aioe.org NNTP Server
Lines:	49
Message-ID:	<op.xjnyitbh6zenlw@localhost>
References:	<op DOT xdxwpebn6zenlw AT localhost>
NNTP-Posting-Host:	CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org
Mime-Version:	1.0
X-Complaints-To:	abuse AT aioe DOT org
User-Agent:	Opera Mail/12.16 (Linux)
X-Notice:	Filtered by postfilter v. 0.8.2
Bytes:	3363
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

On Mon, 07 Apr 2014 05:30:40 -0400, Rod Pemberton  
<dont_use_email AT xnothavet DOT cqm> wrote:

> FYI, nesting is when one DPMI program spawns a child program
> that uses DPMI too.

Well, that isn't exactly a correct description ...

It was rather difficult to understand exactly what a nestable
DPMI host is or what nestability is in terms of DPMI, since
there doesn't seem to be much information on it anywhere.

So, first, I'll describe what I understand and then describe
how to detect nestable DPMI hosts.  (reentrant, stays resident)

When a new DOS DPMI application is spawned, a DPMI host must be
available for it.  If there isn't a DPMI host already loaded
in memory - the normal situation - the application startup code must
find and load a DPMI host.  So, there is one DPMI host in memory
for each and every application.  This consumes low memory which
eventually becomes exhausted.  A better solution is to load a DPMI
host only once.  This is done by making it stay resident, like a
TSR.  However, this requires that the DPMI host be coded as to be
reentrant.  Many DPMI hosts are non-reentrant, so one must be
loaded for each spawned application.  However, some DPMI hosts
are reentrant.  Hosts which are reentrant allow multiple applications
to be spawned without consuming memory for additional DPMI hosts.
A single DPMI host will do the work for many.  This ability is
called a nestable DPMI host or nestability.

The test for detecting a DPMI host which remains resident is similar
to that for detecting a parent or child process by comparing PSP's.
(mentioned in another thread by me)  A DPMI host which remains
resident will have the same address for some of the interrupts
hooked by the DPMI host.  If a new DPMI host is loaded for each
application, then these interrupts will have different addresses
for the parent and child.  Situations where the DPMI host remains
resident is for DOS console windows such as Windows 98/SE console
and Linux dosemu console, and for certain RM DOS DPMI clients which
are reentrant, such as CWSDPMI.  CWSDPMI has the ability to be
made resident or permanent via a commandline flag.  However, under
normal use, if an application spawns child applications, CWSDPMI
will remain resident in memory until the parent application exits.
This is transparent to the user.  Think of this as a temporary TSR.
Information about a handful of DPMI clients as to their nestability
was provided by me in another post in this thread.


Rod Pemberton

- Raw text -