Hallo Herr Aitor Santamaría, am Samstag, 9. Oktober 2021 um 19:01 schrieben Sie:
>>> codepage is a display thing, essentially it's the table how to >>> convert 8-bit bytes into a visable character set, and mostly >>> unrelated to the way the keyboard driver converts scancodes into >>> bytes. >> The Code Page and the Keyboard layout are not unrelated at all -- -- they >> are HIGHLY related. > nope. > I'm afraid they are. Because when a user presses the key (or key > combination) to produce Á, what the user expects is to see Á on the > screen, and not just send a scancode where you may or may not be send a keyboard code Á > able to see Á depending if you are lucky with the codepage. > And that's why the aforementioned door from DISPLAY to KEYB goes: > the actual "intelligence" for that is in KEYB, not in DISPLAY. do you suggest to change the codepage if a user hits Á ? if yes, does FD-KEYB do this? on what conditions? does it make sure that all characters on screen (which were typed before and looked ok) still look ok after codepage change? actually, even accepting your argument (that I don't) that hitting € should either automatically switch to the best loaded codepage with '€' available, or be supressed (as Bret suggests), how is a keyboard driver supposed to be able to determine if there is a proper display representation for '€' at whatever 'ASCII' position? > The key stuff here (what you were wondering about) is whether the > user may want to switch the codepage (not the keyboard layout) > dynamically or not. Because if you don't (as maybe the case in > Germany, or Spain), MKEYB will suffice, but if you do, then you need > this dynamic codepage switch on keyboard that MKEYB does not implement > (afaik). it doesn't. Does FD-KEYB? if so, on what conditions (as explained above)? > I myself find a good reason to be able to issue a hot switch > codepage: there used to be some dumb ancient programs that > implemented a TUI that was heavy cp-437 dependent: they used to mix > bix characters that mixed single-lined, and double-lined borders, > which is NOT available in 850/858. They actually looked horrible > under 850/858, and you may want to sacrifice the extended european > symbols (such as Á) in order to have a better viewing of those programs. you are right. Norton Commander and friends look horrible in codepages different from 437. but this should be the problem of Norton (who wants to display something), not the keyboard driver. > When will the hot codepage change happen? The preferred way: the > user issues a CHCP DOS call and NLSFUNC is loaded. so not a keyboard driver problem. > Another popular, > memory saving, but inconsistent manner: issue a MODE CON CP SELECT. not a keyboard driver problem either. > How often will this happen? I suggest to look at the sources of > KEYBOARD.SYS. Henrique used to implement lots of lots of different > codepages for the same keyboard distribution. I guess in many of > such cases, a hot codepage switch would be a popular issue. just try to explain what,why and how Henrique tried this. and under what circumstances this is relevant so we can reproduce the problem and it's solution. Tom _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
