Mail Archives: djgpp-workers/1999/03/10/05:42:29
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.
Are you working on this? If not I'll have a go when I find the time
(not hooking any interrupts).
How do I know if I (the program) is run under WINDOZE and not plain
DOZE? Does this bug exist under NT too?
Right,
MartinS
- Raw text -