X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Received: by 2002:adf:ec8e:: with SMTP id z14mr15298599wrn.269.1566716834375; Sun, 25 Aug 2019 00:07:14 -0700 (PDT) From: Rod Pemberton Newsgroups: comp.os.msdos.djgpp Subject: Re: [PATCH] exec: fix inversions in leak detection logic Date: Sun, 25 Aug 2019 03:09:52 -0400 Organization: Aioe.org NNTP Server Lines: 187 Message-ID: References: <964e3268-2f75-ee73-ab5a-b01bf1aadb98 AT yandex DOT ru> <7209026e-1f1b-e590-00a3-4ed1a424cc0d AT yandex DOT ru> NNTP-Posting-Host: +15yR2JuBIwiofOqK4kSZw.user.gioia.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse AT aioe DOT org X-Notice: Filtered by postfilter v. 0.9.2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bytes: 8858 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Tue, 20 Aug 2019 14:15:42 +0300 "stsp (stsp2 AT yandex DOT ru) [via 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.