I wrote:
> Based on the interesting discussion in other thread (thanks N.K.),
> following problem came up:
> Is it possible to call INT $31/$401 from real mode or detect for HDPMI32 /
> find out the DPMI host's name without too bad hacks ?
Japheth wrote (contains an intentional test bug  )
> int 31h is not possible in real-mode, but int 2fh, ax=1687h might be used.
> if ax is 0, one can use the address for initial entry in ES:BX to detect hdpmi.
> The string "HDPMI" should be found at offset 0 (ES:0). After this 5 byte
> string comes the version (2 bytes), then 1 byte which tells if it is the
> 16-bit or 32-bit host (16-bit == 0, 32-bit == 1)
I wrote:
> What additional ways to switch RM <-> PM are available in DPMI besides the
> "official" minimum - "client" initialization and termination (dropping
> directly to DOS without any possibility to execute RM code then) ?
Japheth wrote:
> int 31h, ax=030xh and the raw-mode switches. See DPMI documentation.
I wrote:
> Is there a way to execute RM code after DPMI app has terminated ?
Japheth wrote:
> Yes, if you install a hook for int 22h. This is slightly advanced stuff,
> so I wish you good luck!
I wrote:
> How to jump to RM temporarily (as Rayer does ... OK, was not the best idea
> for his purpose ) ?
Japheth wrote:
> Best way is to use the int 31h, ax=030xh functions.
I wrote:
> Also, I understand the motivation for the 9.xx version changes
> to some degree ... and see the dilemma when developing such an
> extender ... DPMI spec wants to cooperate with ANY existing
> DPMI kernel ... OTOH most of them are crappy or bad so there
> is a good reason to bypass them. Unfortunately, 99% of "DOS" users
> use NTVDM or DOS-EMU where also DOS/32A 9.xx fails with
> INT15h/XMS/VCPI attempts and must cooperate (could abort also) 
NK wrote:
> INT15h/XMS/VCPI/DPMI
I wrote:
> I think it's rather DOS32A/INT15h/XMS/VCPI/DPMI 
> There is no bug, but space for an optimization:
> DOS32A/HDPMI32/INT15h/XMS/VCPI/DPMI 
> As revealed by Japheth and verified ^^^ by me, there is a very
> good way to detect for HDPMI32 from real mode ... thus DOS/32A
> *could* cooperate with it (most universal and reliable DPMI host,
> 4 GB RAM, no swap) *without* being "pushed" to do so
> using hacks like "NOVCPI".
NK wrote:
> The current order of system detection is INT15h/XMS/VCPI/DPMI,
> that is the *reverse* of the order mandated by the DPMI spec.
> This was introduced after discussions with DOSBox devs, there
> was an open beta going on for a while, nobody objected and hence
> the changes went into production builds. The exact details
> are in the readme file in one of DOS/32A releases.
> The changes are a serious deviation from the DPMI spec
> (not that there ever have been claims of DOS/32A being standard
> compliant ). If this causes problems, submit a detailed
> bug report, and I'll try to find a way to fix it.
> Cheers, - NK
I wrote:
> If there is an update to DOS/32A planned, following suggestions:
> - Add support for the INT $31/$401 call into DOS/32A DPMI kernel (the
> "vendor-specific" call $21/$FF8A works ... but is vendor-specific  )
> - Do not try to bypass HDPMI32 (using VCPI, XMS or whatever),
> consider both itself AND HDPMI32 as good 
Japheth also wrote that this HDPMI detection from RM could be dropped in future but I hope this was one more joke - I consider this feature as very useful ... |
Thread view
Board view