From: Michael Bukin <bukinm AT inp DOT nsk DOT su>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: What's Broken in Windows DPMI
Date: 06 Apr 1999 07:16:20 +0700
Organization: Budker Institute of Nuclear Physics
Lines: 29
Message-ID: <20emly7gdn.fsf@Sky.inp.nsk.su>
References: <20vhfc47t7 DOT fsf AT Sky DOT inp DOT nsk DOT su> <3708e4ee DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host: sky.inp.nsk.su
X-Newsreader: Gnus v5.5/Emacs 19.34
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"Charles Sandmann" <sandmann AT clio DOT rice DOT edu> writes:

> > Anybody know what exactly is the problem with leaking descriptors on
> > Windows-9X?  
> 
> If you have a nested application (DPMI app #1, like GCC, calls DPMI app
> #2, like CC1) windows should clean up the selectors it allocated for the
> child application on it's exit.  The child can't clean them up, since it
> must have a protected mode CS/SS to call the DPMI exit call.  This is the
> bug - Windows does NOT clean up things on nested DPMI calls - and leaks
> 4 selectors per nesting.

There is another problem, perhaps connected with that problem above.
When DOS stub executes int 0x21, ah=0x4B (load and execute), DOS
allocates some memory with int 0x21, ah=0x48.  When program terminates
with int 0x21, ah=0x4C, DOS does not deallocate that block (at least
there is no call to int 0x21, ah=0x49).  Therefore, it will leak DOS
memory in addition to leaking selectors.  So, even if we can fix
problem with leaking selectors by reusing deallocated selectors,
problem with leaking DOS memory will remain (while we did not find
workaround).

I have tested spawn on Borland C 3.1.  When it calls "load and
execute" interrupt, there are no calls to "allocate memory"
interrupt.  Now I'm trying to compare spawn functions in DJGPP and
Borland C.

-- 
Michael Bukin