DOS ain't dead

Detect HDPMI from RM, DOS/32A coop (recovered from Google) (DOSX)

posted by DOS386, 23.07.2007, 02:52

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 ...

Complete thread:

• Detect HDPMI from RM, DOS/32A coop (recovered from Google) - DOS386, 23.07.2007, 02:52 (DOSX)