Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!uflorida!SORROW@MAPLE.CIRCA.UFL.EDU
From: sorrow@oak.circa.ufl.edu
Newsgroups: comp.os.msdos.programmer
Subject: Re: Help with mouse driver! Is Logi 5 diff from Log 4?
Message-ID: <0094995D.4EA324E0@MAPLE.CIRCA.UFL.EDU>
Date: 3 Jun 91 22:57:38 GMT
References: <00949912.601AB080@MAPLE.CIRCA.UFL.EDU>,<1991Jun3.173405.6109@amc.com>
Sender: news@uflorida.cis.ufl.EDU
Reply-To: sorrow@oak.circa.ufl.edu
Organization: University of Florida CIRCA VAX Cluster
Lines: 49

In article <1991Jun3.173405.6109@amc.com>, jwbirdsa@amc.com (James Birdsall) writes:
|>   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.

A-ha!  That could very well be it.  See, where I have a problem is that no
reference books that I have found tell you how to modify things in your
interrupt handler.  And I was under the impression that the stack for my call
back routine was part of the global stack, and that the interrupt itself had
its own.  No where is any documentation very clear on this.

|>
|>   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.

No, I am not declaring a lot.  All in all, I'd say I have less than 5 local
variables.

|>
|>   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!).

Yes, I am accessing a single global struct (my event queue).  Now, originally I
had used a friend's code which stored the address of my queue in an unused
interrupt vector, then in the interrupt routine I would grab that address and
use it as a pointer to the queue.  However, I was having some problems with it
so just tried using a global variable.  Worked wonderfully.  So this could be
the problem, huh?  Anything in particular to watch for?  Should I return to
using the indirection via vector table.

Brian
/*
Brian Hook -- MS-DOS Programmer for Contract
-----------------------------------------------------------------
"I was in the kitchen, Seamus, that's my dog, was outside....and buried
ALIVE....fritter and waste...but this one goes to 11!....anymore of that
plutonium nyborg?....SNOW TIME!....This is home...this is Mean Street..
*/