> 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).
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.
Freedos-user mailing list