X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" 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: References: NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 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