> Returning "ignore this scancode" or returning the scancode > untranslated would not crash anything, at most drop a key.
That's true, as long as the INT 15.4F code could do that re-entrantly (i.e., not crash when it received the re-entrant request). INT 15.4F handlers are usually pretty simple, so they most (if not all) may be able to do this anyway without any "special" code. In general, however, TSR and device driver writers must at least be cognizant of re-entrancy issues and how to handle them, since it is nearly impossible to guarantee that re-entrancies can NEVER happen. Many programs (especially simple programs) are "lucky" in that they are re-entrant without the programmer ever even thinking about it. > As far as I remember, power keys could be handled by the BIOS int 9 Could be, but usually aren't. Power keys are normally ignored by the BIOS, and don't do anything at all (at least on any of my computers). > pause Normal processing of Pause does indeed use part of the BDA, but also involves pretty severe manipulation of the hardware. Pause processing involves issuing EOI to the PIC and resetting the keyboard controller, but not actually exiting the INT 09 code. Essentially, you are trapped inside a "semi-permanent INT 09 code loop", but interrupts are enabled and processed. However, because you have never actually exited the INT 09 handler (issued the appropriate IRET), foreground operations are never resumed. The INT 09 handler must then wait for at least two more IRQ's to occur (a key press and a key release) before "exiting" the semi-permanent loop (BTW, all of this requires re-entrancy in the INT 09 handler). Appropriate handling of the Pause key from INT 15.4F would be problematic, though it might be possible. All of that, of course, assumes the the Pause key is not "redirected" in some fashion (e.g., my SCANCODE program will let you turn the Pause key, or any other key, into a type of "macro" key, if you want). > windows / multimedia keys could just be stored in 40:xx as normal > ASCII 0, scancode X function keys. Could be, but there actually is no universally accepted standard for which scancodes go with which multimedia keys -- different manufacturers do it differently. Microsoft supposedly has a "standard" way they do it on their keyboards, though. So, merely throwing them into the keyboard buffer (which you could also do with the power keys, BTW) probably won't do anything useful, and could actually cause problems. With my virtual keyboard programs, I leave try to leave this totally flexible, even though I know that almost no DOS programs (at least today) use any of the "special" keys. My programs will still "type" them, and let the INT 09 handler decide whether or not they are "useful". I fully expect the standard definition of what keys are considered "useful" in DOS to change (increase) as time goes by. As mentioned earlier, my SCANCODE program can already take literally any keystroke, including the multimedia ones, and turn it into a type of "macro" key. > Of course writing to 40:xx (after asking 15.4f) would be cleaner > and easier, but as noted, MS KEYB does not follow standards here. Actually, most everybody is following the standards, including MS KEYB (I didn't think the INT 15.4F programs were following the standards, but they actually are). MS KEYB is not in defiance of the standards any more than any program that provides its own INT 09 handler is. MS KEYB merely replaces the BIOS-level INT 09 handler (which, e.g., doesn't understand anything about alternative code pages or keyboard languages, or could have compatibility problems) with an OS-level INT 09 handler. The problem is, the "standards" are sometimes merely precedents instead of standards, are not always coherent or complete and can be interpreted ambiguously, and as a result sometimes unintentionally conflict with each other. I personally think that the invention of INT 15.4F was a mistake, though I'm sure IBM thought it was a really good idea, at least at the time. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
