Date:	Sun, 30 Apr 2000 18:06:43 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
cc:	djgpp AT delorie DOT com
Subject:	Re: 3rd Try: Maybe an asm problem? (Problems linking)
In-Reply-To:	<390C39D1.D80D3FFA@mtu-net.ru>
Message-ID:	<Pine.SUN.3.91.1000430180037.1120F-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 30 Apr 2000, Alexei A. Frounze wrote:

> > Not necessarily.  Depending on the DPMI server and the underlying OS, the
> > INT instruction might be handled entirely in protected mode.
> 
> DOS Extenders don't handle BIOS stuff in PMode, though. Neither CWSDPMI nor
> DOS4GW nor WDOSX nor DOS32 nor 32RTM do that. Thay can't. Only Windows is
> capable to do that in PMode, since it has PMode drivers for almost everything
> and it can replace/hook native BIOS and DOS services.

Yes, Windows is one case I was thinking about, where the difference 
between __dpmi_int and int86 is significant.  DOSEmu is another one.
I suspect that NT and Windows 2000 are yet another such case.

Note that if you run DJGPP programs not from a DOS extender (as is mostly 
the case with DJGPP programs), it's the V86 monitor's responsibility to 
reflect the INT instruction to the real-mode handler; the DPMI host 
usually doesn't do anything with it.  (In contrast, __dpmi_int is 
handled by the DPMI host.)  The V86 monitor is usually part of the memory 
manager, such as EMM386.

- Raw text -