Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
DOS386(R)

23.07.2007, 02:52
 

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

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 :lol: )

> 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 :lol: ) ?

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) :no:

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 :hungry:

Japheth also wrote that this HDPMI detection from RM could be dropped in future :no: but I hope this was one more joke - I consider this feature as very useful ...

Back to index page
Thread view  Board view
15112 Postings in 1359 Threads, 247 registered users, 26 users online (0 registered, 26 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum