Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU From: Ralf.Brown@B.GP.CS.CMU.EDU Newsgroups: comp.os.msdos.programmer Subject: Re: Programming the Mouse Message-ID: <26b56957@ralf> Date: 31 Jul 90 11:19:51 GMT Sender: ralf@b.gp.cs.cmu.edu Organization: Carnegie Mellon University School of Computer Science Lines: 34 In-Reply-To: <34725@ut-emx.UUCP> In article <34725@ut-emx.UUCP>, readdm@walt.cc.utexas.edu (David M. Read) wrote: }In article [abridged] gene@uokmax.uucp (Gene E. Johannsen) writes: }!> }!> I am writing a program that I want to use the mouse with. I don't }!>have a reference work to the mouse so I am using a list of interrupts. Below }!>is a small program I writing to learn how to use the mouse. All it will do is }!>set up and turn on the mouse and then print an '*' when I press the left }!>button. It prints the '*' but freezes immediately afterwards: }!> }!> [...] }!> }!>BUTTON PROC FAR }!> [...] }!> ret } ^^^ }!>BUTTON ENDP }!> }!> END }> }I may be wrong here, but shouldn't this be an 'iret' instruction? After }all, the routine *is* an interrupt service routine, called by a hardware }interrupt...If you return with a regular 'ret' call, none of the registers }are popped off the stack and restored to their state before the interrupt, }and the CPU doesn't know where to pick up, so it *should* freeze! No, because the "interrupt handler" is actually a FAR routine called by the real mouse interrupt handler in the mouse.sys or mouse.com software. The real problem is that Gene is calling INT 21h from an interrupt handler, which is a no-no unless stringent precautions are taken to avoid re-entering DOS. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain