Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.djgpp > #1728 > unrolled thread

Is int86() designed and implemented correctly?

Back to article view | Back to comp.os.msdos.djgpp

Contents

  Is int86() designed and implemented correctly? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-15 05:16 -0500
    Re: Is int86() designed and implemented correctly? Eli Zaretskii <eliz@gnu.org> - 2014-02-15 16:52 +0200

#1728 — Is int86() designed and implemented correctly?

For interrupts other than Int 21h, int86() calls _int86
in assembly which generates an interrupt in PM.  For
many, but not all, Int 21h sub-functions, int86() does
the same.  Supposedly, this is to allow installed PM
interrupt routines to execute.

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?

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?


Rod Pemberton

[toc] | [next] | [standalone]

#1730

> From: "Rod Pemberton" <dont_use_email@xnohavenotit.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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.msdos.djgpp

csiph-web