X-Authentication-Warning: ieva01.lanet.lv: pavenis owned process doing -bs
Date: Mon, 22 Feb 1999 10:09:28 +0200 (WET)
From: Andris Pavenis <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: Does Windows 98 lose DMPI descriptors?
In-Reply-To: <Pine.SUN.3.91.990221131553.6539I-100000@is>
Message-ID: <Pine.A41.4.05.9902220943410.72826-100000@ieva01.lanet.lv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com



On Sun, 21 Feb 1999, Eli Zaretskii wrote:

> 
> On Fri, 19 Feb 1999, Andris Pavenis wrote:
> 
> > Maybe it's possible to hook int 0x31 to avoid real freeing descriptors
> > but reusing them. Only question is whether we are able to simulate ALL
> > needed functions there (including __create_alias_descriptor) 
> 
> As I understand it, the problem is with the CS descriptor.  A running
> program cannot free it, so if the DPMI host doesn't do it properly,
> you have no work-around.
> 

As far as I tested normally 4 descriptors are leaked for starting each
DJGPP program from another one. My example posted earlier to
DJGPP mailing list additionally allocated and freed some more descriptors.
If we don't do that we see that 4 descriptors are lost per each spawned
DPMI executable but they all are freed when returning to command prompt.

Trying to debug my test example with FSDB shows that DPMI function
to free LDT descriptor seems to be totally broken under Win95. However I'm
not totally sure hooking DPMI interrupt in libdbg.a is fully Ok (I'm not
using unmodified dbgcom.c from djlsr202.zip, but seriously modified
version from Pierre Muller)

Anyway I see possible workaround for descrptor leak when spawning DPMI
program from another one under Win95. Usually such problem happens only
in applications that starts large amount of other programs (for example
make, bash and maybe some more). Possible solution would be hooking 
int 0x31 in such applications to reuse descriptors being freed:
	- when freeing LDT descriptor we could only mark this descriptor
          to be usable but not telling it to Win9X
	- when allocating descriptor we should look at first whether we 
	  have descriptor to reuse and only if such lookup is
          unsuccessfull we could ask Win9X to allocate new one.
	  The problem may be with attemp to allocate more than one
          descriptor at call, but I think also this function should be
          considered.
        - we should also similary hook allocating alias descriptor to
          provide reusing descriptors also in this function.
        - maybe I have missed some functions. Then they also should
          be hooked

If such workaround could work then It could realised as single object file
with global constructor (__attribute__((constructor))) that installs
int 0x31 hook and corresponding descructor that uninstalls it. So linking
in such module in application would be enough. However we should consider
situation when such hooking is done recursively as it will happen in many
situation. But I hope it is not a serious problem. Of course it will cause
some performance penalty if the int 0x31 is hooked many times.

Maybe only we should avoid hooking int 0x31 more than once but then we
should decide how best to do that. Also we should test for pressence of
broken DPMI servers (Win9X) as such thing is not required with for example
CWSDPMI.

Andris