X-Authentication-Warning: ieva01.lanet.lv: pavenis owned process doing -bs Date: Wed, 10 Mar 1999 11:21:10 +0200 (WET) From: Andris Pavenis To: Martin Stromberg cc: DJGPP-WORKERS Subject: Re: Does Windows 98 lose DMPI descriptors In-Reply-To: <199903100904.KAA15551@juno.erisoft.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 10 Mar 1999, Martin Stromberg wrote: > Please note that I've moved the discussion to djgpp-workers. > > Andris said: > > 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. > > Neat. But perhaps overkill? Why not rewrite the functions that calls > int 0x31? No need to hook any interrupts. I don't think it's possible. Currently I think best would be to develop one program that hooks int 0x31 to workaround Win9X DPMI problems and spawns unchanged program which is specified in command line. So we'll not have to think how to avoid recursive hooking of int 0x31. > > Are you working on this? If not I'll have a go when I find the time > (not hooking any interrupts). Currently not and I don't know when (and whether) I'll do it. I repeat that I think it's impossible without hooking interrupts. Perhaps src/debug/common/dbgcom.c can be example how to hook int 0x31 (I know it is not from files in djlsr which are easy to understand and hack) > > How do I know if I (the program) is run under WINDOZE and not plain > DOZE? Does this bug exist under NT too? > Did some limited tests on WinNT 4.0+SP3 and seems that problem is not present there. Andris