Mail Archives: djgpp/2019/08/25/08:38:48
Воскресенье, 25 августа 2019 г получено от Rod Pemberton:
> > > 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).
So since when dos4gw, dos32a, wdosx etc stopped being the extenders and started being dpmi hosts? Care to explain the exact procedure you did for testing them with djgpp apps?
> I've tested a total of 18 DPMI hosts.
I suspect you tested nothing at all, unless you provide the exact steps of testing eg dos4gw's dpmi with djgpp apps. You probably have some wrapper app to do so?
> 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,
I rejected that speculation many times: no, I do not think so.
> > 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
No, its very different. Indeed, I do claim to run the dos extender (32rtm) under dosemu's dpmi host. But I do not claim that I can later use its dpmi services for the djgpp-built app. Instead I can use its dos extender services for borland apps.
> > >> 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,
You can read that indication in the nearby messages from djgpp devs. Or you can read it from the patch that just makes this thing optional. Or you can waste my time pretending to review the patch that was long ago absoleted by another one.
> 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?
Just look at the right patch.
> 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.
:)
"key" is redundant here.
> 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,
You are speaking for others way too much. They can and they do. And they look to the right patch.
> 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.
It always make sense to make the patch as much environment-independent as possible, than to argue on where it fixes and where breaks. Thats why I simply posted the second patch, and it obviously is environment-independent, as to not change anything at all by default.
> > 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.
Only if that matters. And likely not.
> > 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
I told you many times that the patch was re-sent.
> 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? ...
This does have to do with the sad fact that many free software projects have people who do not contribute and actively try to prevent others from. The big amount of fake arguments (like discussing long obsoleted patch, calling dos extenders a dpmi hosts etc) is a good indicator, so I had to check you profile in that project and found nothing surprising
> (i.e., non-sequitur, ad hominem attack, straw man fallacy, implied
> call-to-authority of oneself, etc ...)
May well be, but firstly that was a constatation of an undeniable fact.
> > 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,
Yep, spelled much better than I did.
So good that we agreed at least on your attitude to djgpp project.
> i.e., no changes, hence no future
Indeed. :)
(yep, taken out of context intentionally - couldnt resist :)
> think DJGPP should favor DOS and Windows consoles for 98/SE/ME, and not
> support other environments,
Wow! That's something new. Sorry, never used the aforementioned windoses myself, and, being not a windows user, cant agree with that.
> 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,
For that it is much better to write a porting layer that will allow you to compile the dos binaries under posix environment with plain gcc. That porting layer is not going to be small, but its possible.
> 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.
Os that requires the dpmi to start?
> 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.
No, my new patch requires no change to any code.
- Raw text -