We (well, at least I) have a severe dilemma going on here.

> int 15.4f is supposed to be called from the BIOS from the INT 09
> handler, and NOBODY else.

I've done some more research regarding this, and it is never stated anywhere 
that this function can ONLY be called from the INT 09 handler.  That is merely 
an assumption on your part.  As a general rule, BIOS functions are allowed to 
be called by any program (including IRQ handlers) at any time, and as a result 
must be re-entrant.

Obviously, MS believes that INT 15.4F can be called from outside INT 09, based 
on what they've published on their web site.  If INT 15.4F is not re-entrant, 
and the user happens to press (or release) a key on the keyboard while the MS 
code is in process, the computer may hang, or do something far worse, instead 
of rebooting.  You can find various references to similar variations of this 
same "reboot code" in multiple places on the Internet.

However, IBM seems to have a different perspective.  They explicitly say in 
some of their documentation (comments in the PC/AT BIOS source code, as well as 
the PS/2 Technical Reference Manuals) that INT 15.4F is allowed to process the 
scancodes (something which up until now, I never thought was allowed).  None of 
the documentation I've found outside of IBM actually says this, though.  The 
reference I was referring to earlier that I mistakenly thought came from IBM 
actually came from somewhere else.

So, based on IBM, INT 15.4F shouldn't be called from outside INT 09, not 
because they explicitly say so anywhere, but rather because of the potential 
damage that could be caused if INT 15.4F actually processes the "unreal" 
scancode.  MS apparently disagrees.


Now comes the real dilemma.  RBIL states that IBM classifies INT 15.4F as 
"required".  I don't know where that statement came from (I didn't find it in 
any of the documentation I came across), but I do believe IBM actually stated 
this somewhere.

The problem with this is when you have a program that provides its own INT 09 
handler, and doesn't use even use the BDA to keep track of things (Windows, 
GEM?, GEOS?, many games, ...).  If these programs call INT 15.4F as is 
"required", and INT 15.4F actually processes the scancode (modifies the BDA, 
puts keystrokes in the keyboard buffer, toggles the LEDs on the keyboard, etc.) 
and then tells the INT 09 handler to ignore the scancode, there is a big 
problem.  At a minimum, the BDA will be all screwed up when the program exits 
(if you can even find a way to exit the program, because you may not be able to 
use the keyboard properly).

I think most (if not all) of these programs ignore INT 15.4F for this reason, 
though technically (at least according to RBIL) they are in violation of the 

The other issue with an INT 15.4F handler, of course, is that it won't directly 
work with the BIOS on PC's and early-model XT's and AT's.  Most people don't 
care about that kind of compatibility any more, though, and FD-KEYB has an 
option that "fixes" that problem.

> no single DOS or BIOS call is 'fully' reentrant

Actually, all DOS and BIOS functions must be re-entrant in a general sense, 
though you're correct that they don't necessarily need to be "fully" 
re-entrant.  Any resident function (BIOS, DOS, or anything else) that can 
potentially be called from both inside and outside an IRQ handler (and there 
are very few that can't be), or anything that can conceivably be called 
recursively (INT 16h calling INT 10h calling INT 16h), must be able to handle 
the possibility of re-entrancy.

Common ways of handling re-entrancy issues are to return an "I'm busy -- go 
away" error (like the InDOS Flag), provide some sort of "context-switching" 
mechanism (like the DOS Swappable Data Area), queue up the requests (which 
requires a "stack" and call-back mechanism of some sort), and full, 
unadulterated re-entrancy (where the "old" process is temporarily halted, the 
"new" one is handled, and then the "old" one is resumed).  The INT 14h handlers 
in my DOS USB Host Drivers are, in fact, fully re-entrant.

INT 15.4F is problematic right now regarding that (at least from what I see), 
because IBM indirectly says it doesn't need to be re-entrant, while MS 
indirectly says it does.  Even though IBM is technically correct here, MS 
actually has more clout in the industry.  INT 15.4F must in fact "worry" about 
the possibility of re-entrancy, at least in the case of Ctl-Alt-Del.

> that's why it was created in the first place: to free the KEYB
> implementation from the burden of supporting micro channel machines,
> where it's not as easy as 'handling INT 09'

What exactly would you do differently in the INT 09 handler for an MCA machine 
than you would on an ISA machine?  AFAIK, there is no difference -- you can 
install MS KEYB or any of the early KEYB clones (which all used INT 09 instead 
of INT 15.4F, BTW) on a PS/2 just like you can on an ISA machine, even if they 
were written before MCA even existed.

> if you show me the point in the IBM Technical Refence, I might
> consider this.

Like I said earlier, the reference I thought came from IBM actually came from 
somewhere else.  I apologize.

> otherwise I tell you that MKEYB does all of these nasty things
> mentioned above, and it works beautifully.

Works beautifully (at least works as designed) in many situations perhaps, but 
certainly not all.


Note that these dilemmas and potential conflicts and incompatibilities don't 
even exist (including the re-entrancy part) when the keyboard handler uses INT 
09 instead of INT 15.4F.  The only conceivable advantage I can see to using INT 
15.4F instead of INT 09 is that you can save a small amount of memory, but you 
do so at the risk of incompatibility with other programs (including some from 
MS).  The correct combination of programs and circumstances and timing can 
cause a system crash (one which could have been avoided).

For me, this means that I can't use INT 15.4F to "automate" my keyboard 
configuration processes any more, putting more burden on the user than would be 
necessary otherwise.

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