Mail Archives: djgpp/2019/08/20/06:04:31
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.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
a) emulators:
DOSBox doesn't provide DPMI. (disabled)
QEMU doesn't provide DPMI.
DOSEmu doesn't provide DPMI.
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.
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?
> > 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.
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?
> 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? ...
DOS and Windows are DJGPP's primary target environments. If the
DJGPP code works properly for DOS and Windows consoles, there is no need
to make it compatible with some other environment, which is most likely
buggy or has a faulty emulation.
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 -