Mail Archives: djgpp/2019/08/19/22:19:22
> On Sun, 18 Aug 2019 16:54:39 +0300
"stsp (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
wrote:
> > I.e., another DPMI host is already loaded prior to performing the
> > spawn, e.g., CWSDPMI or Windows DPMI.
> >
> > You can test this like so for DOS:
> >
> > CWSDPMI -P
> > 32RTM -X
> >
The point of the above, which you seemed to have skipped, was to
demonstrate that the below claim simply doesn't work, at least, not
here for the version of MS-DOS that I use.
> > 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).
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.
What you're saying is the result is different for other DOSes.
Are you loading CWSDPMI permanently "CWSDPMI -P" prior to your tests?
BFN,
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 -