🚀 go-pugleaf

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