X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
Date:	Sat, 15 Feb 2014 16:52:51 +0200
From:	Eli Zaretskii <eliz AT gnu DOT org>
Subject:	Re: Is int86() designed and implemented correctly?
In-reply-to:	<op.xbbitrq95zc71u@localhost>
X-012-Sender:	halo1 AT inter DOT net DOT il
To:	djgpp AT delorie DOT com
Message-id:	<83bny8bf7g.fsf@gnu.org>
References:	<op DOT xbbitrq95zc71u AT localhost>
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

> From: "Rod Pemberton" <dont_use_email AT xnohavenotit DOT cnm>
> Date: Sat, 15 Feb 2014 05:16:29 -0500
> 
> However, there are thirteen Int 21h sub-functions
> which have been extended for setting up pointers,
> transfer buffer, return values etc within int86().
> These thirteen sub-functions *do not* call the _int86
> assembly routine which generates a PM interrupt.
> Instead, int86() calls __dpmi_int() for them.
> __dpmi_int() calls the DPMI host's simulate real mode
> interrupt DPMI API call, thereby generating a RM
> interrupt, instead of a PM interrupt.  Shouldn't these
> extended Int 21h sub-functions have been designed to
> call int86() to generate a PM interrupt?

That'd be unnecessary overhead.  More importantly, it cannot work,
because these functions use memory buffers, which need to be copied to
and from low memory below 1MB mark.

'int86' is a compatibility function, it was designed to transparently
allow code ported from real-mode programs work with minimal or no
changes.  That is the only purpose of this function.  For any other
purpose, you are encouraged to prefer '__dpmi_int'.

> Using __dpmi_int() would seem to *bypass* installed PM
> ISR routines for those Int 21h sub-functions, calling
> RM instead.  Is this correct?  Since it seems these
> sub-functions can't be called in PM via DJGPP, how does
> someone call installed custom ISRs for the thirteen Int 21h
> sub-functions?  Does assembly need to be used to generate
> a PM Int 21h interrupt directly?  Or, am I missing something,
> like these get reflected back to PM somewhere, somehow?

See the DPMI Spec:

            2.4.2 Software Interrupts

            Most software  interrupts executed  in real mode will not be
            reflected to  the protected  mode interrupt hooks.  However,
            some software  interrupts are  also reflected  to  protected
            mode programs when they are called in real mode.  These are:


                       INT            DESCRIPTION

                       1Ch    BIOS timer tick interrupt
                       23h    DOS Ctrl+C interrupt
                       24h    DOS critical error interrupt

and later:

            Since most  software interrupts  that are  executed in  real
            mode are  not reflected  to protected  mode interrupt hooks,
            programs would  be required to install a real mode interrupt
            hook to monitor these interrupts.

So I think you should simply hook Int 21h in real mode.

- Raw text -