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 standards. 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. 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
