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 Subject: Re: Is int86() designed and implemented correctly? In-reply-to: X-012-Sender: halo1 AT inter DOT net DOT il To: djgpp AT delorie DOT com Message-id: <83bny8bf7g.fsf@gnu.org> References: 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 > From: "Rod Pemberton" > 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.