Xref: news-dnh.mv.net comp.os.msdos.djgpp:2133
Path: news-dnh.mv.net!mv!news.sprintlink.net!in2.uu.net!comp.vuw.ac.nz!waikato!not-for-mail
From: jpg AT cs DOT waikato DOT ac DOT nz (J P Griffiths)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: int86() in V2
Date: 21 Sep 1995 23:05:14 GMT
Organization: The University of Waikato
Lines: 50
Sender: jpg AT waikato DOT ac DOT nz
References: <43mnib$iec AT newsbf02 DOT news DOT aol DOT com>
Reply-To: jpg AT waikato DOT ac DOT nz
Nntp-Posting-Host: lucy.cs.waikato.ac.nz
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

Hardgeus (hardgeus AT aol DOT com) wrote:
: 
:     I have some mouse handler functions that use in86() calls.  In V1.x
: they
: work fine.  Then when I compile them in V2, either button presses get lost
: or the xy coordinates get scrambled.  All of the code is pretty
: straightforward.
: Is there some change in the way int86() behaves that I should know about?

I had this problem when moving my code to version two.  From memory it 
was a casting or alignment problem.  Assuming that you get the register 
values back into an int or unsigned int variable,  then you should and
it with 0xffff to retain just the lower 16 bits of the value.  This fixed 
it for me - email me if you have any further problems.

:     Also, I use interrupt handlers a lot in my current project (keyboard,
: serial,
: timer) and I am following the guidelines of the faq...but they still seem
: very 
: unstable even in V2.  Recently I have seen people talking about locking
: memory
: for interrupts to prevent page faults.  Now this is something I have not
: heard of
: at all.  What is it exactly, how do I do it, and why?

This entails using DPMI functions to tell the DPMI provider (windoze, 
cwsdpmi,dosemu etc) that the memory section containing the interrupt code 
shouldn't be paged out to disk.  If the code is paged out when an 
interrupt occurs then your machine will lock up and die (possibly taking 
the HD with it,  as some unfortunates have found out).  The problem is
that every bit of memory touched by your interrupt handler must be locked,
including any stack space or global variables it uses.  If you use the 
built in functions to allocate wrappers,  they are not locked either,  so 
the path is fraught with danger.

Now I have a few questions about this topic...

1.   My interrupt functions don't read anything off the stack.  Do I still 
    need to lock it?

2.   What is the problem with locking a wrapper as it is created?  Is it 
    possible?


Good luck with your projects,

                        Jon.

p.s  Try to keep your posts to less than 80 characters per line - its 
     much easier to read.