Date:	Wed, 13 Oct 1999 11:53:37 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	djgpp AT delorie DOT com
Subject:	Re: DPMI identification
In-Reply-To:	<380316cc.sandmann@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.991013115314.16702P-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

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.

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?

- Raw text -