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>
 <bd347f78-b176-6992-291c-2e542241efa1 AT yandex DOT ru>
 <qjgf7r$1b15$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: <f864b19b-4796-6179-617b-d00afe259df0@yandex.ru>
Date: Tue, 20 Aug 2019 14:15:42 +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: <qjgf7r$1b15$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 12:43, Rod Pemberton пишет:
> On Tue, 20 Aug 2019 09:05:29 +0300
> "stsp (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
> wrote:
>
>
>> I have not tried loading it under cwsdpmi.
>> Host OSes and emulators do provide DPMI these days
> a) emulators:
>
> DOSBox doesn't provide DPMI. (disabled)
> QEMU doesn't provide DPMI.
> DOSEmu doesn't provide DPMI.

Really?
Think again. :)


> Bochs doesn't provide DPMI.
> MAME doesn't provide DPMI.
>
> I.e., all of the above emulators would use CWSDPMI by default with
> DJGPP code if emulating DOS.  They would use Windows internal DPMI
> host, if emulating Windows.
>
> So, which "emulator provides DPMI these days"? ...
>
>
> b) OSes:
>
> DOS doesn't provide DPMI.
> Linux doesn't provide DPMI.

Well, dosemu was always a default way of getting
DPMI under linux, like was ntvdm under windows.
Most distros removed it already, but I'll get it back
after working through the bugs like this one (and
1024+ to come).


> MacOS doesn't provide DPMI.
> Android doesn't provide DPMI.
> Windows /does/ provide DPMI.
>
> I.e., Windows is the only OS where CWSDPMI wouldn't be used by default,
> as Windows has it's own internal DPMI host.
>
> What OS with DPMI other than Windows are you discussing? ... ReactOS?

OS/2 also provides the very capable DPMI host.


>>> 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.
> That makes no sense to me.  That's the default for DJGPP DOS apps.
> Most people use DJGPP for DOS, but also execute them in a Windows
> console.  Are you saying you've only tested this stuff under the
> Windows console? ...
>
>
> Let's review.
>
> So, in order to bypass CWSDPMI, you must do one of the following:
>
> a) change the default DPMI host for the app under DOS from CWSDPMI to
> CWSDPR0 or PMODETSR
> b) execute under Windows integral DPMI, i.e., within a Windows console,
> or perhaps for a Windows clone OS, say ReactOS ...
> c) load a DPMI host in DOS prior to executing the DJGPP code, e.g.,
> HDPMI, DOS4GW, PMODEW, DOS32, DOS32A, WDOSX, DPMIONE, QDPMI, PRO32, or
> D3X etc.

You listed DOS extenders together with DPMI hosts.
Either you think its the same thing, or you assume
they can load the go32-compatible executables,
or you probably know some way of re-using the
optional built-in DPMI server of these DOS extenders
for the sake of the djgpp app. In the letter case please
spell that out so that I can check if it works.


> d) use an emulator with built-in DPMI and an enabled DPMI host, of
> which there currently are none, AFAIK ...
>
> Specifically, which one are you doing?
> If none of the above, then what?

dosemu


>> 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.
> Why would DJGPP code need to be modified, if the modifications won't
> allow 32RTM to work with DJGPP for either a DOS or Windows
> environment? ...

Why do you think that a simple bugfix should save the
world and fix all possible environments? Fixing several
is just a start. Other people can fix the rest. Not doing
anything at all is not the best way of getting anywhere.


> DOS and Windows are DJGPP's primary target environments.  If the
> DJGPP code works properly for DOS and Windows consoles
But currently it doesn't.
Even if you find the most capable DPMI host
(hdpmi I suppose), it will still fail w/o my patch.

The bug is simple: djgpp assumes the memory
leak on the DPMI hosts where there is no any leak.
I don't understand is it really worth explaining
such a simple bug so many times.
And just in case, I checked the log of the djgpp
sources to see what you have contributed.
Unless I am mistaken - nothing. Which goes very
much in line with the attitude you expressed. But
it doesn't mean that other people should also
contribute nothing.