> I think it could "bounce off" attempts to use it recursively but > I do agree that it should not do I/O, so it can only be used in > combination with something else which does the I/O and/or buffers.
Not true. It does not ONLY need to be used in combination with something that does the I/O. In my programs, I use it to "test" the keyboard configuration to make sure it is correct or if a keystroke (scancode) should even be "typed" at all. In addition to not doing I/O, INT 15.4F cannot modify the BDA, put ASCII codes into the keyboard buffer, or anything else that the INT 09 handler proper does. In short, it cannot "replace" the INT 09 handler in whole or in part -- that is not its purpose. >From a purely practical perspective, turning an INT 15.4F handler into a >"proper" INT 09 handler is pretty trivial, and only requires a small amount of >extra code (issuing the EOI and sending some I/O to "clean up" the keyboard >controller). Small price to pay to ensure 100% compliance with the standards >and compatibility with other programs. ? As discussed earlier, there could be a DISPLAY which processes UTF8 > instead of ASCII, but it will confuse programs which assume that all > string lengths are equal to their byte lengths for the layouting... I was thinking of something different, yet a separate function (which could be part of DISPLAY). The input would be a Unicode character, and the output would be a code page character (either for the current code page, or possibly for any requested code page if there was sufficient memory). Actually displaying (or in the case of KEYB, "typing") the character is unrelated to this. ------------------------------------------------------------------------------ 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
