Mail Archives: djgpp/2019/08/20/02:10:01
20.08.2019 5:05, Rod Pemberton пишет:
>>> 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).
I have not tried loading it under cwsdpmi.
Host OSes and emulators do provide DPMI these days
(well, yes, some host OSes no longer do that these days :)
If it doesn't work with cwsdpmi, its not my fault and
not djgpp fault. I was not promising to fix it on all
possible environments - the start should be made
from fixing the bug that prevents it from working on
_any_ possible environment. Then someone may also
fix cwsdpmi (but not me - for me things already work).
Try QDPMI, DPMIONE, HDPMI - there are plenty of modern
DPMI servers to try, most of which are compatible with
32rtm (but again, I don't use them, I use the emulator's
DPMI services).
> 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.
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.
> What you're saying is the result is different for other DOSes.
It does not depend on DOS.
Its just that there are borland-compatible and
borland-incompatible DPMI servers, and cwsdpmi
fails to the second category.
To find out if the particular DPMI server is borland-compatible,
you need to query for the "MS-DOS" extension via
int 2f, AX=168a. If the entry point is not returned,
you have the borland-incompatible DPMI server and
my patch does not help in that case.
I can't fix everything.
If the entry point is returned, you are on a right track,
but since 32rtm is very buggy, it doesn't work properly
even on some DPMI servers that support "MS-DOS"
extension. That's the life.
- Raw text -