Hi! > 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...
> 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. 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. > why would you want to "simulate keystrokes properly"? That should be possible with the int 16 func for thatmost of the time. > 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. That could work with a suitably compressed representation, e.g. only using the start of Unicode char space, or only discontinous subsets. > 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?) 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... Eric PS: That DISPLAY could store a big Unicode font in XMS and cache a number of recently used chars, or run entirely in protected mode. ------------------------------------------------------------------------------ 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
