> The "standard" use of FD-KEYB, with lesser memory footprint, does use > INT 15h, 4Fh for its function (as I think mkeyb) does.
In fact, most of the KEYB replacements I've seen use INT 15.4F, which is precisely why they are incompatible with KEYB. I recently had a rather lengthy, though incomplete, discussion with some others about this on the BTTR forum, including the author of MKEYB. The basic problem is that INT 15.4F is a BIOS function that can be called by any program at any time. It's true that it is always supposed to be called by the INT 09 handler (though even that doesn't necessarily always happen, such as in Windows or certain other programs that provide their own INT 09 handler). For a long time, people have assumed that INT 15.4F can ONLY be called by INT 09, and that is simply not true. MS itself gives an example of issuing an INT 15.4F from outside the INT 09 handler here: http://support.microsoft.com/kb/67929 Because it can be called from outside the INT 09 handler, there are all kinds of issues that must be taken into account in the implementation, including the fact that it must be fully-re-entrant and it must never issue any I/O requests to the keyboard controller or the PIC or anything else. In short, INT 15.4F must only do what the IBM Technical Reference (and RBIL) say it should do: translate one scan code to another, or return a flag indicating that the scancode should be ignored. INT 15.4F is not supposed to actually "process" any scancodes at all (modify the BDA, insert keys into the keystroke buffer, issue INT 05 if <PrintScreen> is pressed, handle the <Pause> key, handle Power/Sleep/Wakeup and multimedia keys (Volume Controls, Play/Pause/etc.) for keyboards that have them, etc.). Only the INT 09 handler proper is supposed to do that. > But you can install an alternative int 9h interrupt handler if you > use the /9 option. It does NOT do all that the BIOS does, as in > order to save space, it only handles keystrokes that differ from the > standard BIOS (assumed "US") keyboard does. Again, that is why it is not a fully compatible replacement for MS-KEYB. That particular type of implementation may work for many programs and hardware configurations, but it won't work for all of them. > I am also curious to know, because I was thinking that by 3.0, I > would remove all the pre-AT stuff (for easier maintainance), and > leave only INT 15h, 4Fh stuff, but why would you want to "simulate > keystrokes properly"? I think removing the pre-AT stuff is probably not a bad idea at this point in time. I'm starting to make many of my programs require at least an 80386 CPU for the same reason (easier maintenance). The programs mentioned are all "virtual keyboards", and are actually very necessary with today's hardware. Many modern computers don't have "real" PS2 keyboards (or even PS2 ports) any more, but only USB. All USB keyboards are virtual. If you let the BIOS control the USB keyboard, the BIOS will use SMM (System Management Mode) to virtualize the USB keyboard so that it "looks like" a PS2 keyboard. The problem with letting the BIOS control the USB keyboard, though, is that you must then also let the BIOS control all of the other USB devices attached to that same USB controller. BIOS virtualization of USB devices is always incomplete, and will at best support some subset of keyboards, mice, disk drives, and hubs. If you want to use any other type of USB device (printers, joysticks, cameras, sound systems, ...), you can't let the BIOS control them, which usually means you can't let the BIOS control the keyboard, either. Depending on your specific hardware configuration this isn't always true, but in general USB is an "all or nothing" type of arrangement -- either the BIOS must control everything, or it must control nothing. I'm not even convinced trying to use SMM from a DOS driver is feasible, so the best I think anyone may be able to do is what I've done with my "keystroke simulation". But, even it needs some help sometimes. *************** Regarding FD-KEYB 3.0, I've been think of some ways that it could be improved. I think one thing that would help immensely is to turn the "translation" into a two-step process. The first step would be to translate the input scancodes to Unicode, rather than trying to translate them directly to a code page character as is done now. The second step would then be to translate Unicode to a code page character. By "isolating" the scancodes from the code pages, you can literally map any keyboard layout to any code page without needing to build special translation tables for each possible combination. This may also be the first step towards getting Unicode somewhat integrated into DOS, which I know people have been talking about for a long time. The second step of the process (Unicode -> Code Page) could even be implemented as a separate API (perhaps an INT 16h extension, or something related to DISPLAY?) so that other applications could use the same translation tables. I should also state that I'm not a real big fan of Unicode for various reasons, but it seems to be the only/best alternative available for something like this. Also, I'm sure you're worried about the amount of memory this may end of taking, but there are ways to get that down to a "manageable" size. ------------------------------------------------------------------------------ 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
