Subject: Re: [PATCH] exec: fix inversions in leak detection logic
To: djgpp AT delorie DOT com
References: <964e3268-2f75-ee73-ab5a-b01bf1aadb98 AT yandex DOT ru>
 <qjb14m$1kqj$1 AT gioia DOT aioe DOT org>
 <7209026e-1f1b-e590-00a3-4ed1a424cc0d AT yandex DOT ru>
 <qjfkbp$1o2c$1 AT gioia DOT aioe DOT org>
From: "stsp (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Message-ID: <bd347f78-b176-6992-291c-2e542241efa1@yandex.ru>
Date: Tue, 20 Aug 2019 09:05:29 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <qjfkbp$1o2c$1@gioia.aioe.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-MW
Content-Transfer-Encoding: 8bit
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

20.08.2019 5:05, Rod Pemberton пишет:
>>> I.e., another DPMI host is already loaded prior to performing the
>>> spawn, e.g., CWSDPMI or Windows DPMI.
>>>
>>> You can test this like so for DOS:
>>>
>>> CWSDPMI -P
>>> 32RTM -X
>>>
> The point of the above, which you seemed to have skipped, was to
> demonstrate that the below claim simply doesn't work, at least, not
> here for the version of MS-DOS that I use.
>
>>> I.e., it's not _just_ an example of a "prot-mode TSR program".
>> In presence of another DPMI server - it is.
> 32RTM -X can't be loaded "in the presence of another DPMI server" as a
> "prot-mode TSR program" under CWSDPMI -P as it errors.  That result is
> for MS-DOS 7.10 (Windows 98/SE).

I have not tried loading it under cwsdpmi.
Host OSes and emulators do provide DPMI these days
(well, yes, some host OSes no longer do that these days :)
If it doesn't work with cwsdpmi, its not my fault and
not djgpp fault. I was not promising to fix it on all
possible environments - the start should be made
from fixing the bug that prevents it from working on
_any_ possible environment. Then someone may also
fix cwsdpmi (but not me - for me things already work).
Try QDPMI, DPMIONE, HDPMI - there are plenty of modern
DPMI servers to try, most of which are compatible with
32rtm (but again, I don't use them, I use the emulator's
DPMI services).

> Also, CWSDPMI - being coded with Borland C++ and TASM - doesn't use any
> of the functions of DJGPP that you're modifying to fix the problem
> with 32RTM.  So, I'm really doubtful that your claim that 32RTM works
> with DJGPP's spawn is true, given that 32RTM won't even work with just
> CWSDPMI alone without calling any DJGPP code.

I never said it works for me under cwsdpmi.
I never even tried that combination.
Once again, the bug should be fixed first, that
prevents it from working on _any_ possible
configuration. Then someone who is interested
in a _particular_ configuration, may take the time
to fix it there. I certainly didn't promise to fix everything.


> What you're saying is the result is different for other DOSes.
It does not depend on DOS.
Its just that there are borland-compatible and
borland-incompatible DPMI servers, and cwsdpmi
fails to the second category.
To find out if the particular DPMI server is borland-compatible,
you need to query for the "MS-DOS" extension via
int 2f, AX=168a. If the entry point is not returned,
you have the borland-incompatible DPMI server and
my patch does not help in that case.
I can't fix everything.
If the entry point is returned, you are on a right track,
but since 32rtm is very buggy, it doesn't work properly
even on some DPMI servers that support "MS-DOS"
extension. That's the life.