Date: Wed, 20 Mar 1996 12:20:57 +0200 (IST) From: Eli Zaretskii To: "A.Appleyard" Cc: DJGPP AT delorie DOT com Subject: Re: mouse irq In-Reply-To: <8BC0BC7D43@fs2.mt.umist.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.