DOS ain't dead

discussion - splitting MCBs again (Developers)

posted by bretjohn  , Rio Rancho, NM, 14.06.2011, 05:11

> Care to tell why ? At least I hope it's /not/ because something I wrote has
> you offended - if it were the case, I would call it a misunderstanding and
> regret, sincerely.

Well, since you've asked... No, I'm not offended. I actually find the hypocrisy amusing. You're trying to do the EXACT same thing you told me I couldn't do -- call INT 15.4F from outside an INT 09 handler.

Just as an aside, I hope you realize that doing this (and the fact that MS does it and some of my programs do it) means that your INT 15.4F handler must be fully re-entrant. It may already be without you realizing it (I haven't looked). But, if the user types a key on the keyboard at the same time INT 15.4F is being called from outside INT 09, and it's not fully re-entrant, you could have a big problem.

> Anyways out of the many many things you could tell (but won't) what I would
> find most interesting would be an answer to the question : Bret, can it
> happen that some one of your TSRs issue an int 15 with AX=4FF4 ? If it can,
> will it be spontaneous or triggered by an (which?) exterior circumstance ?
> And again if your program must issue the above call, and it consequently
> receives (from KBFR) AL=F5 and No Carry (no other modification), is it in
> any way spoiling your processing ?

I don't think any of my programs will directly issue an unprovoked INT 15.4FF4, but I have several of them could simulate a scancode of F4h, which could cause INT 15.4FF4 to be issued by the INT 09 handler or by one of my programs. It's impossible to say exactly what would/could happen in such a situation. I will admit that the simulation of an F4h scancode is unlikely, but certainly not impossible.

Also FWIW, the way the keyboard simulation works, the INT 09 handler code may not actually be called by the generation of an IRQ 1. It may actually be called simply as a "subroutine" from another IRQ handler (usually INT 70 / IRQ 8). My programs temporarily disable the real keyboard while they are doing this, so re-entrancy in either the INT 09 or INT 15.4F handlers shouldn't be an issue from that perspective.

The user can tell my "virtual keyboard" programs to simulate almost any scancode they want to send, even if it couldn't come from a "real" keyboard. MOUSKEYS will simulate scancodes based on mouse movements and buttons, JOYKEYS does the same for joystick movements and buttons, and USBKEYB of course does it for USB keyboard buttons. My SCANCODE program will do it based on various kinds of input, including absolute or relative timing, specific text on the screen, and other types of input, including even other scancodes (whether from the real keyboard or another "virtual keyboard" program, including another copy of SCANCODE). At least in the case of SCANCODE, it is actually very useful sometimes to simulate scancodes that actually can't come from the real keyboard.

I will also say this. Overloading interrupts is OK, as long as you are careful about how and why and when you do it. I've done it several times myself. My USB API overloads INT 14h, my joystick programs overload the joystick BIOS interface (INT 15.84), USBKEYB (and in the future all of the other virtual keyboard programs) overloads INT 16h, etc.

The only time you should do this, though, is when there is not an existing, suitable API that does what you need it to do. In addition, you need to be very careful about which INT's and functions and subfunctions you overload. INT 15.4F is simply not one you should be messing with, since it is effectively no more than a "subroutine" for an IRQ handler. I don't think I even need to tell you how bad of an idea it is to overload an IRQ handler, whether directly or indirectly. I haven't actually looked at what you're doing, but I suspect INT 2Dh (AMIS) is probably more than sufficient for what you're trying to accomplish, even though I know it requires more memory than you want it to.

Complete thread:

• KBFR 1.9 beta discussion opened by CM - Ninho, 13.06.2011, 12:17 (Developers)
  • discussion - ecm, 13.06.2011, 14:49
    • discussion - Ninho, 13.06.2011, 19:28
      • discussion - splitting MCBs again - ecm, 13.06.2011, 20:20
        • discussion - splitting MCBs again - Ninho, 13.06.2011, 21:52
          • discussion - splitting MCBs again - bretjohn, 13.06.2011, 22:38
            • discussion - splitting MCBs again - ecm, 13.06.2011, 23:41
              • discussion - splitting MCBs again - bretjohn, 14.06.2011, 00:17
            • discussion - splitting MCBs again - Ninho, 14.06.2011, 02:05
              • discussion - splitting MCBs again - ecm, 14.06.2011, 02:10
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 04:09
                  • ! - ecm, 14.06.2011, 05:17
                    • ! - Ninho, 14.06.2011, 05:59
                      • ! - ecm, 14.06.2011, 06:06
              • discussion - splitting MCBs again - bretjohn, 14.06.2011, 05:11
                • on overloading and AMIS - ecm, 14.06.2011, 05:50
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 13:38
          • discussion - splitting MCBs again - ecm, 13.06.2011, 23:33
            • discussion - splitting MCBs again - Ninho, 14.06.2011, 01:31
              • discussion - splitting MCBs again - ecm, 14.06.2011, 02:20
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 04:05
                  • discussion - splitting MCBs again - ecm, 14.06.2011, 05:54
                    • discussion, & "retiring" for awhile - Ninho, 14.06.2011, 12:50
                      • DOSLFN, intermediate handler issued calls; "retiring" - ecm, 14.06.2011, 18:51
                        • intermediate handler issued calls - Ninho, 15.06.2011, 15:32
                          • intermediate handler issued calls - ecm, 15.06.2011, 16:50
                            • intermediate handler issued calls - Ninho, 15.06.2011, 17:53
                              • intermediate handler issued calls - ecm, 15.06.2011, 22:37