Mail Archives: djgpp/2019/08/25/03:19:25
On Tue, 20 Aug 2019 14:15:42 +0300
"stsp (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
wrote:
Sorry for the delay, I've been busy.
> > DOSBox doesn't provide DPMI. (disabled)
> > QEMU doesn't provide DPMI.
> > DOSEmu doesn't provide DPMI.
>
> Really?
> Think again. :)
Ok, confirmed.
Sorry, my recollection was that DOSemu was only V86 mode for Linux,
i.e. no DPMI.
> > 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.
No, I listed DPMI hosts (see below).
I've tested a total of 18 DPMI hosts. Some of them are not very
complete DPMI hosts, but that's another issue. They're sufficient as
DPMI hosts, albeit maybe not for DJGPP. AFAIK, only one of the hosts I
mentioned above, i.e., DOS32, has any DOS extender functions, but
DOS extender functions was not something I was testing for or checking.
The results of 12 (of 18 tested) DPMI hosts below are counted manually,
not computed ...
Windows 98/SE - DPMI 0.9 complete, DPMI 1.0 four functions
CWSDPMI - DPMI 0.9 comlete, DPMI 1.0 six functions
DPMIONE - DPMI 0.9 complete, DPMI 1.0 most of
HDPMI - DPMI 0.9 complete, DPMI 1.0 most of
QDPMI - DPMI 0.9 complete
DOS4GW - DPMI 0.9 most of, DPMI 1.0 three functions
DOS32A - DPMI 0.9 most of, DPMI 1.0 two functions
WDOSX - DPMI 0.9 most of, DPMI 1.0 one function
PRO32 - DPMI 0.9 much of
PMODEW - DPMI 0.9 much of, DPMI 1.0 one function
D3X - DPMI 0.9 minimal
DOS32 - DPMI 0.9 minimal, DOS extender functions
(DJGPP code only uses DPMI 0.9 calls, not DPMI 1.0.)
> Either you think its the same thing,
No, I don't.
> or you assume they can load the go32-compatible executables,
No, I don't.
But, you still seem to think that multiple DPMI hosts can be loaded and
used at the same time, e.g., DOSemu and 32RTM and/or CWSDPMI and
32RTM. They can't, for the reasons stated previously, only one can
control protected mode and GDT/IDT of the x86 processor, i.e., you're
likely abusing an emulation bug in DOSemu.
> 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.
I have no idea what you're talking about here.
AFAICT, this appears to be what you were claiming to be able to do with
32RTM, supposedly executing both under DOSemu (or CWSDPMI).
> >> 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.
I think a simple bugfix should not mess up other working environments,
especially the primary environments for DJGPP. That's what's important.
So far, I haven't seen any indication that your bugfix is correct, or
even tested for that matter. You've not posted any regression results
for the numerous DOSes and OS environments where DJGPP **works**, or
did. How do we know you didn't breaking something? I've not seen any
other confirmation or test results from others here that your changes
work either.
Of course, it's not my project, nor am I a key contributor to it.
DJGPP was essentially "complete" by the time I started using it. So,
I'm just a user like you, albeit a long time user. However, I do
resent you strongly pushing a patch, which apparently no one can
confirm is correct or not, and expecting others to accept it as
correct, simply based upon your word that it is.
> > 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.
I'm not sure what you mean by that.
DJGPP code - including the code you're changing - has been working
correctly for decades. You're the one claiming it isn't or doesn't
work correctly - now. That proof is up to you, but I had to "fight"
and "argue" with you just to simply get you to reveal your test
environment, i.e., DOSemu. That raises an abundance of red flags in my
mind.
> Even if you find the most capable DPMI host
> (hdpmi I suppose), it will still fail w/o my patch.
Technically, DPMIONE, but HDPMI is good too. Although, I usually use
the default DPMI host for a specific compiler, e.g., CWSDPMI for DJGPP,
or DOS4GW for OpenWatcom. as they're sufficient.
> The bug is simple: djgpp assumes the memory
> leak on the DPMI hosts where there is no any leak.
As stated previously, I think that was exclusively for Windows
consoles. Someone else will need to confirm.
> I don't understand is it really worth explaining
> such a simple bug so many times.
Because, you changed their test to the exact opposite, without
providing any proof that your "fix" is actually a fix, not a
corruption. You've only described what you believe to be correct,
specifically for your environment.
> And just in case, I checked the log of the djgpp
> sources to see what you have contributed.
What does this have to do with anything? ...
(i.e., non-sequitur, ad hominem attack, straw man fallacy, implied
call-to-authority of oneself, etc ...)
> Unless I am mistaken - [you contributed] nothing.
Maybe I think DJGPP is fine just the way it is and so doesn't need
anything. Or, maybe, I think DJGPP is better as static or dead code,
i.e., no changes, hence no future incompatibilities. Or, maybe, I
think DJGPP should favor DOS and Windows consoles for 98/SE/ME, and not
support other environments, including more recent versions of Windows,
7/Vista/XP etc, due to DPMI/NTVDM incompatibilities. Or, maybe, the
only significant purposes I foresee for DJGPP are to implement a 32-bit
Windows or 32-bit DOS, but 32-bit x86 is effectively dead nowadays. Or,
maybe, I get tired of not being able to compile FSF/GNU code out of the
box, and have it actually work as expected on DOS. Or, maybe, I think
DJGPP would be great with various changes, e.g., with ELF binaries, with
GLIBC, as 64-bit code, etc, but I see no hope of it ever getting those
things in my lifetime, so I've given up. Or, maybe, I get tired of
attempting to contribute, only to end up in arguments with key clique
contributors about the future of DJGPP. Or, maybe, I've used DJGPP to
code my own OS, and eventually, will completely bypass the need for
DJGPP at all. All true.
Except for some of the changes to V2.05, apparently to support Windows
XP/Vista/7 consoles, which seemed to break some existing DOS
functionality of V2.03, and which was discussed previously some years
ago, I like DJGPP the way it is, even thought it's imperfect. Your
changes have the potential to mean that I may need to create multiple
versions of certain programs or version specific changes to my DJGPP
code.
Rod Pemberton
--
Let me say it yet again. Reducing gun violence doesn't reduce
violence. Dead is dead, whether by gun, car, hammer, club, or knife.
- Raw text -