Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uwm.edu!ogicse!milton!sumax!amc-gw!jwbirdsa From: jwbirdsa@amc.com (James Birdsall) Newsgroups: comp.os.msdos.programmer Subject: Re: Help with mouse driver! Is Logi 5 diff from Log 4? Message-ID: <1991Jun3.173405.6109@amc.com> Date: 3 Jun 91 17:34:05 GMT Article-I.D.: amc.1991Jun3.173405.6109 References: <00949912.601AB080@MAPLE.CIRCA.UFL.EDU> Reply-To: jwbirdsa@europa.amc.com (James Birdsall) Organization: Applied Microsystems, Redmond, WA Lines: 48 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 ===========