Mail Archives: djgpp/1999/10/14/08:15:59
> On Tue, 12 Oct 1999, Charles Sandmann wrote:
>
> > Things I can think of which would give hints:
> > Which DPMI calls are supported (Get page attributes is a good one to test)
> > What DPMI version is reported
> > The current IOPL, and the GDT information
> >
> > Ideally you should check for features instead of a specific DPMI provider.
>
> In practice, most cases where people need to make a distinction
> involve CWSDPMI-or-anything-else type of queries. In fact, several
> discussions in this news group indicated lately that some applications
> really need to know they run under CWSDPMI. One example that seems to
> come up frequently is programs that test memory or report other
> hardware-related system information. These need to use some of the
> DPMI v1.0 functions supported by CWSDPMI.
Which is exactly why I don't think they should test for CWSDPMI - they
should try to use the functions needed and see if they succeed. For
example, 386MAX is a full DPMI 1.0 host and implements null page
protection - crt0.s just calls the dpmi 0x507 set page attributes
call and it works. Borland has also provided VXD extensions for some
Windows releases which add some scattered DPMI 1.0 features. OS/2
also supports some DPMI 1.0 features.
> So it strikes me that if CWSDPMI would support function 0401h of Int
> 31h (Get DPMI Capabilities), it could simply return a unique ID string
> in the buffer pointed to by ES:EDI.
>
> Charles, is it possible to add support for this function in the next
> CWSDPMI release?
I'll consider it - what do all the other vendors provide for this
information? Will DPMI crash on some host if you try this call?
I hate to open a can of worms.
- Raw text -