> send a keyboard code �
That doesn't always work work. Let me use a Star Trek analogy (I hope most
people can relate to this).
Let's say someone in the Enterprise wants to get down to a planet that the Star
Ship is circling. There are two ways they can do this. One is to use the
Transporter, where they just suddenly "appear" on the planet. This is like the
"stuff the keyboard buffer with an ASCII code" scenario. The ASCII code just
"suddenly appears" in the keyboard buffer with no intervening steps. However,
what appears in the keyboard buffer is an ASCII Code AND a Scan Code. Since
you don't know the "correct" Scan Code to use, you just make one up. In the
Transporter Scenario, this would be like the Transporter correctly transporting
the upper half of your body but always making the lower half of your body
always be that of a chimpanzee. In some (in fact, most) cases, that is "close
enough". In other cases, it isn't.
The other way you can get from the Enterprise down to the planet is with the
Shuttle. This is comparable to the SCANCODE method of "typing" -- "taking the
long way home". It is slower and more cumbersome, the end result is the same
(if it is done correctly), and you always get to the destination fully intact.
Now, let's take the analogy one step further. Let's say that instead of trying
to get down to a planet, you are needing to investigate some "space anomaly"
that is not a solid planet you can walk on. In that case, you would NEVER use
the Transporter -- that is simply the wrong tool. In such a case, you would
NEED to take the Shuttle instead. That is analogous to needing to "type"
something like Pause or Ctrl-Alt-Del or PrtScr or CapsLock which have nothing
to do with ASCII codes or the BIOS keyboard buffer.
The Shuttle (like SCANCODE) will get you to where you need to go all the time,
while the Transporter (like ASCII codes) have many more limitations on when and
how they can be used. The ASCII method will work 99% of the time, SCANCODE
will work 100% of the time. Sometimes, 99% is good enough and sometimes it
isn't.
>> 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)?
Yes, it does. As already explained, INT 2F.AD81. That's exactly what the
function is for and why MKEYB is supposed to monitor it.
We have here a similar situation as we do above with SCANCODE and the Star Trek
analogy. What FD-KEYB does is the "correct" way to do it, but it is more
complicated and cumbersome and will always work (as long as everybody "follows
the rules"). What MKEYB does will work 99% of the time (as long as the user
never needs/wants to change keyboard layouts or Code Pages). For most
users/applications, that is good enough. For others, it isn't.
> 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.
But MKEYB is wanting to display things on the screen, too, so it is the EXACT
same problem. Norton didn't do it correctly, and neither does MKEYB.
>> 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.
Yes, it is.
>> Another popular,
>> memory saving, but inconsistent manner: issue a MODE CON CP
>> SELECT. Â
> not a keyboard driver problem either.
Yes, it is.
> under
> what circumstances this is relevant so we can reproduce the problem
> and it's solution.
We've already showed you the problem and how to fix it. With MKEYB, the Euro
character is not generated correctly unless the Code Page is one where the Euro
symbol is ASCII 213. This is true for some Code Pages but not others. That's
a problem which you can easily reproduce yourself. The solution is for MKEYB
to be aware of the current Code Page instead of ignoring it, or at least
warning the user that if they use the wrong Code Page some things may be
displayed incorrectly.
This actually reminds me of another thing that has been in the back of my mind
for a long time. Normally, when the screen is in a text mode the mouse cursor
is just a block that is the reverse color that it would be if the mouse cursor
wasn't there. As you move the mouse around the screen, all that changes is the
color of a single character (the character that the mouse cursor is pointed
at). When the screen is in a graphics mode, the mouse cursor is (usually) an
arrow. In DOS programs, the size and shape and color of the mouse cursor is
(normally) controlled by the mouse driver, which for FreeDOS is usually CTMOUSE.
In the past, I've seen programs (including some later versions of the Norton
Utilities) where even in a text mode the mouse cursor was an arrow instead of
just a colored block. There weren't a lot of programs that did this, but there
were a few. I remember "reverse engineering" one of the programs that did this
and what they did was "steal" four of the ASCII codes that would appear on the
screen and change the font in "real time" as the mouse moved around the screen.
That is, the would take the font character that was being displayed on the
screen, copy it to one of the four "special" characters, mask in the
appropriate part of the arrow, and then change the ASCII code on the screen to
the new one with the arrow mask. For each mouse movement, it had do this for
four different screen characters (a complete arrow potentially takes four text
mode characters to display).
Anyway, I'm wondering if adding that capability to CTMOUSE (or at least have it
as an option) might be something that users would like? It seems like you
could do it in CTMOUSE itself, but I'm not 100% sure. It also seems like it
could potentially cause screen corruption ("mouse droppings"), especially for
programs that write directly to video memory instead of using BIOS calls to
update the screen, which is why I think it should be optional.
Just a thought to throw out there.
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
