Date: Sun, 30 Apr 2000 18:06:43 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Alexei A. Frounze" 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.