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

Reply via email to