Mail Archives: djgpp/1996/03/20/05:30:11
On Wed, 20 Mar 1996, A.Appleyard wrote:
> As it is, when the program has a user-writtem mouse interrupt handler, when
> the mouse is moved or clicked the PM program must go into RM to obey the mouse
> interrupt, which then calls the user's (inevitably compiled by djgpp into RM)
> mouse interrupt handler, which then goes back to PM for DOS to return him to
> the RM calling program.
If your handler indeed needs to be called every time the mouse moves, it
might indeed be tough. But if you can write your application so that the
handler is only called when a button is pressed or released, and get the
movement info by calling an appropriate function of Int 33h, then you
shouldn't be worrying about the overhead.
Another possibility is to poll the mouse (with Int 33h calls) about its
movements. If you do this fast enough, and if you turn the mouse off
when you won't be polling it for a long period of time, then you can
avoid defining a handler at all. (Look at the Emacs sources, that's how
it handles the mouse).
Personally, I don't think that writing a full-fledged mouse driver is
worth the hassle, not to mention that it too will have to suffer some
mode switches when the mouse is moved while the program is in real mode
(like when it calls some DOS service).
> I think what Martynas meant, was that he (and I also) think that it would be
> useful for djgpp to be able to be told to compile in real mode if wanted, so
You cannot produce reliable 32-bit code in real mode, AFAIK. For one
thing, the pointers will again be seg:off pair, which means we're back to
the horrors of 64KB-long segments, offset wrap-arounds and other
monstrocities that I'm so happy without.
- Raw text -