🚀 go-pugleaf

In article <00949912.601AB080@MAPLE.CIRCA.UFL.EDU> sorrow@oak.circa.ufl.edu writes:
>Hi all.  I have been using my own mouse routines and installed my own mouse
>interrupt handler.  Here is the problem:
>
>1.  I am using a 386/33 using Borland C++ (BC /X, not BCX).
>2.  When running Logitech Mouse Driver 5.00 I have found that when I run my
>program I get a "Stack Overflow!" error.  I have stack checking enabled.
>This happens on my 386 but not on a 286.
>3.  This does not happen using Logitech Mouse 4.00.
>4.  The stack overflow occurs the SECOND I TOUCH THE MOUSE after my routines
>to install my mouse handler (call back function) are executed.
>5.  The machine will work inconsistently with stack checking off.
>
>Is there a bug with Logitech 5.00 that I am not aware of?  If so, why do
>my other mouse programs (Eye of the Beholder, Windows 3.0, BC++, etc.) work
>with the driver and my programs die?  Is there something that I am missing
>here fundamentally?

   It sounds like you have two separate problems. Stack checking, and
something else. A fact that is mentioned in passing in the manual under
setvect(): interrupt routines won't work if you have stack checking
turned on. Which makes sense; the stack checker assumes that the current
stack is your program's stack. Since an interrupt handler can be called
from anywhere, the current stack may be anything, causing the stack
checker to freak out. The mouse call-back routine is called from inside
the mouse driver's hardware interrupt, so the call-back occurs
asynchronously.

   Actually, that suggests a couple more ideas. Other things that could be
happening:

   1) Are you declaring a lot of local variables? You may be intermittently
overflowing somebody else's stack, munging whatever was below the stack.

   2) Are you accessing global variables, or calling other functions in
your program which do? Since it's being called asynchronously, DS may
not be pointing to your data segment, in which case you will be reading
garbage and writing over somebody else's data (or code!).

Both of these problems would cause intermittent crashes. As to why it
works under the older driver and not the newer, I don't know. The
problem may be entirely different, but this gives you someplace to start.

-- 
James W. Birdsall   WORK: jwbirdsa@amc.com   {uunet,uw-coco}!amc-gw!jwbirdsa
HOME: {uunet,uw-coco}!amc-gw!picarefy!jwbirdsa OTHER: 71261.1731@compuserve.com
"The OS shouldn't die every time the controller drools on a sector." -- a sysop
=========== "For it is the doom of men that they forget." -- Merlin ===========