My understanding is that TranslateMessage collates a sequence of key events and adds a WM_CHAR message to the queue if it results in a character. So on my computer what happens when I press Alt+1234 (6 relevant events/messages, including releasing the Alt) is the single character "Ê" comes out (in certain places).
Let's say I have a sequence of virtual key codes and related keypress data generated from the LL keyboard hook. Is there some way of using the Windows OS logic to translate this sequence into a real character? For example, could I construct contrived MSG structures, call TranslateMessage on them and then catch the WM_CHAR ensuing events? That seems very outside of Windows' expectations; haven't tried it yet but it seems like it could cause all kinds of subtle problems.
The cleanest solution I can think of so far is just to re-implement the logic myself to figure out the characters from the virtual codes. This is unfortunate of course since Windows internals already seem to know how to do this! Is there a better way?
I am aware of the existence of MapVirtualKeyA but this does not seem to handle a sequence of virtual key codes.
I am also aware that it is possible to do a hook on all GetMessage calls which could be used just to grab the WM_CHAR messages from every process. However this seems an extremely heavy solution: I need to make a separate DLL unlike for the WH_KEYBOARD_LL hook and then use some sort of IPC to send the characters back to my host process. Also MSDN explicitly says that you should avoid doing global hooks this for anything outside debugging and I need this to work on production machines.
I am also also aware of KeysConverter in .NET (I am fine to use .NET for this) but again this does not seem to deal with sequences of virtual keys like given above.
I'm using Notepad++ as my test case, but I was also able to replicate the exact same behavior on a program I wrote that (indirectly) uses the Win32 API, so I'm trusting at this time that the behavior is specific to Windows, and not to the individual programs.
At any rate, I'm trying to use alt-codes to transmit unicode text to a program. Specifically, I'm using the "Alt Plus" method described in the first point here. For any and all alt-codes below 0xffff, this method works perfectly fine. But the moment I try to transmit an alt-code above this threshold, the input only retains the last four digits I typed.
From notepad++ using UCS-2 Big Endian:
To generate this output, I used the following keystrokes:
[alt↓][numpad+][numpad1][numpad2][numpad3][numpad4][alt↑]
[alt↓][numpad+][numpad1][numpad2][numpad3][numpad5][alt↑]
[alt↓][numpad+][numpad1][numpad2][numpad3][numpad4][numpad5][alt↑]
Knowing that the first two bytes are encoding specific data, it's clear that the first two characters transmitted were successful and correct, but the third was truncated to only the last 2 bytes. Specifically, it did not try to perform a codepoint→UTF16 conversion; it simply dropped the higher bits.
I observed identical behavior on the program I wrote.
So my questions then are in two parts:
Is this a hard constraint of Windows (or at least the Win32 API), or is it possible to alter this behavior to split higher codepoints into multiple UTF-16 (or UTF-8) characters?
Is there a better solution for transmitting unicode to the application that doesn't involve writing a manual parser in the software itself?
To expand on that second point: In the program I wrote, I was able implement the intended functionality by discarding the "Text Handling" code and writing, by hand, a unicode parser in the "Key Handling" code which would, if the [alt] key were held down, save numpad inputs to an internal buffer and convert them to a codepoint when [alt] was released. I can use this as a solution if I must, but I'd like to know if there's a better solution, especially on the OS side of things, rather than a software solution.
I'm using the keyboard to enter multi-lingual text into a field in a form displayed by a Web browser. At an O/S-agnostic and browser-agnostic level, I think the following events take place (please correct me if I'm wrong, because I think I am):
On each keypress, there is an interrupt indicating a key was pressed
The O/S (or the keyboard driver?) determines the keycode and converts that to some sort of keyboard event (character, modifiers, etc).
The O/S' window manager looks for the currently-focused window (the browser) and passes the keyboard event to it
The browser's GUI toolkit looks for the currently-focused element (in this case, the field I'm entering into) and passes the keyboard event to it
The field updates itself to include the new character
When the form is sent, the browser encodes the entered text before sending it to the form target (what encoding?)
Before I go on, is this what actually happens? Have I missed or glossed over anything important?
Next, I'd like to ask: how is the character represented at each of the above steps? At step 1, the keycode could be a device-specific magic number. At step 2, the keyboard driver could convert that to something the O/S understands (for example, the USB HID spec: http://en.wikipedia.org/wiki/USB_human_interface_device_class). What about at subsequent steps? I think the encodings at steps 3 and 4 are OS-dependent and application-dependent (browser), respectively. Can they ever be different, and if yes, how is that problem resolved?
The reason I'm asking is I've run into a problem that is specific to a site that I started to use recently:
Things appear to be working until step 6 above, where the form with the entered text gets submitted, after which the text is mangled beyond recognition. While it's pretty obvious the site isn't handling Unicode input correctly, the incident has led me to question my own understanding of how things work, and now I'm here.
Anatomy of a character from key press to application:
1 - The PC Keyboard:
PC keyboards are not the only type of keyboard, but I'll restrict myself to them.
PC Keyboards surprisingly enough do not understand characters, they understand keyboard buttons. This allows the same hardware used by a US keyboard to be used for QEWERTY or Dvorak and for English in any other language that uses the US 101/104-key format (some languages have extra keys.)
Keyboards use standard scan codes to identify the keys, and to make matters more interesting keyboards can be configured to use a specific set of codes:
Set 1 - used in the old XT keyboards
Set 2 - used currently and
Set-3 used by PS/2 keyboards which no one uses today.
Sets 1 and 2 use make and break codes (i.e. press down and release codes). Set 3 uses make and break codes just for some keys (like shift) and only make codes for letters this allows the keyboard itself to handle key repeat when the key is pressed for long. This is good to offload key repeat processing from the PS/2 8086 or 80286 processor but rather bad for gaming.
You can read more about all this here and I also found a Microsoft specification for scan codes in case you want to build and certify your own 104 key windows keyboard.
In any case we can assume a PC Keyboard using set 2, which means it sends to the computer a code when a key is pressed and one when a key is released.
By the way the USB HID spec does not specify the scan codes sent by the keyboard it only specifies the structures used to send those scan codes.
Now since we're talking about hardware this is true for all operating systems, but how every operating system handles these codes may differ. I'll restrict myself to what happens in Windows, but I assume other operating systems should follow roughly the same path.
2 - The Operating System
I don't know exactly how exactly Windows handles the keyboard, which parts are handled by drivers, which by the kernel and which in user mode; but suffice to say the keyboard is periodically polled for changed to key state and the scan codes are translated and converted to WM_KEYDOWN/WM_KEYUP messages which contain virtual key codes.
To be precise Windows also generates WM_SYSKEYUP/WM_SYSKEYDOWN messages and you can read more about them here
3 - The Application
For Windows that is it, the application gets the raw virtual key codes and it is up to it to decide to use them as is or translate them to a character code.
Nowadays nobody writes good honest C windows programs, but once upon a time programmers used to roll out their own message pump handling code and most message pumps would contain code similar to:
while (GetMessage( &msg, NULL, 0, 0 ) != 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
TranslateMessage is where the magic happens. The code in TranslateMessage would keep track of the WM_KEYDOWN (and WM_SYSKEYDOWN) messages and generate WM_CHAR messages (and WM_DEADCHAR, WM_SYSCHAR, WM_SYSDEADCHAR.)
WM_CHAR messages contain the UTF-16 (actually the UCS-2 but lets not split hairs) code for the character translated from the WM_KEYDOWN message by taking into account the active keyboard layout at the time.
What about application written before unicode? Those applications used the ANSI version of RegisterClassEx (i.e. RegisterClassExA) to register their windows. In this case TranslateMessage generated WM_CHAR messages with an 8 bit character code based on the keyboard layout and the active culture.
4 - 5 - Dispatching and displaying characters.
In modern code using UI libraries it is entirely possible (though unlikely) not to use TranslateMessage and have custom translation of WM_KEYDOWN events. Standard Window controls (widgets) understand and handle WM_CHAR messages dispatched to them, but UI libraries/VMs running under windows can implement their own dispatch mechanism and many do.
Hope this answers your question.
Your description is more or less correct.
However it is not essential to understand what is wrong with the site.
The question marks instead of characters indicate a translation between encodings has taken place, as opposed to a misrepresentation of encodings (which would probably result in gibberish.)
The characters used to represent letters can be encoded in different ways. For example 'a' in ASCII is 0x61, but 0x81 in EBCDIC. This you probably know, what people tend to forget is that ASCII is a 7 bit code containing only English characters. Since PC computers use bytes as their storage unit, early on the unused top 128 places in the ASCII code where used to represent letters in other alphabets, but which one? Cyrillic? Greek? etc..
DOS used code page numbers to specify which symbols where used. Most (all?) of the DOS code pages left the lower 128 symbols unchanged so English looked like English no matter what code page was used; but try to use a Greek code page to read a Russian text file and you'd end up with Greek and symbols gibberish.
Later Windows added it's own encodings some of the with variable length encodings (as opposed to DOS code pages in which each character was represented by a single byte code,) and then Unicode came along introducing the concept of code points.
Under code points each character is assigned a code point identified by a generic number, i.e. the code point is identified by a number not a 16 bit number.
Unicode also defined encodings to encode code points into bytes. UCS-2 is a fixed length encoding that encodes the code point numbers as 16 bit numbers. What happens to code points with more than 16 bits, simple they cannot be encoded in UCS-2.
When translating from an encoding that supports a specific code point to one that doesn't the character is replaced with a specified character, usually the question mark.
So if I get a transmission in UTF-16 with the hebrew character aleph 'א' and translate it to say latin-1 encoding which has no such character (or formally latin-1 has no code point to represent the unicode code point U+05D0) I'll get a question mark character instead '?'
What is happening in the web site is exactly that, it is getting your input just fine but it is being translated into an encoding that does not support all the characters in your input.
Unfortunately, unlike encoding misrepresentations which can be fixed by manually specifying the encoding of the page there is nothing you can do to fix this on the client.
A related problem is using fonts that do not have the characters shown. In this case you'd see a blank square instead of the character. This problem can be fixed on the client by overriding the site CSS or installing appropriate fonts.
From what I can tell, the notion of "Shift", "Alt", and "Control" are pretty well hard coded from the keyboard itself right through the OS APIs. Sometimes I see the Windows key used as a modifier, but it doesn't seem to register as a "real" modifier key, any more than any key on the keyboard would.
But could a person add a new modifier key? Maybe in a wild and insane effort to bring back the space cadet keyboard? Aside from a physically modified keyboard (or maybe just remapping some unused keys), what else would it take? New drivers? New APIs calls? A complete rewrite of the OS?
I guess this kind of thing would be a lot easier to do on an open source OS than on Windows as well, yes?
Well, there's benefit in having a standard for keyboards and mice. It makes things "work" without needing special drivers or operating system patches. But that implies that keyboards and mice have to be standardized themselves in order to have them "just work".
So, if you wanted to add an extra key to the keyboard - whether it is a modifier key or not - you have to somehow make it useful which means that applications need to be aware of it and they need a way to be notified of this key's state. Fortunately, Windows and other operating systems Open Source or not, provide an extensible and also standard mechanism for this: drivers.
So, in short you would need to provide a driver to extend the standard functionality of the standard keyboard much like you would need a driver if you bought one of those fancy mice that come with 19 special buttons and 3 scroll wheels instead of the standard two-or-three buttons and one scroll wheel.
And finally, you would need applications that are aware of your special keyboard. What use would it be to have this modded-keyboard after all if you application were ignorant of it's superpowers? The only thing you'd be able to do with your special keyboard would be to create hot-keys that incorporate your special modifier..
I am curious about your reason. Do you actually wish to utilize and fully integrate the use of an additional modifier key in your daily computer usage? If so, in what way? (This is pure curiosity on my part; I'm fascinated by the reasons or events leading up to your query! And I will explain why.)
Let me first state that I can not fully answer the question you asked (what exactly would be involved with adding a modifier to the OS) other than to say that it would take much more work than what I believe any individual could accomplish—even within several years (except for some true computer genius); but depending on your reasons for asking, I can show you that it probably wouldn't be required for your purposes (although that's obviously speculation). And actually, technically, more modifiers actually exist but they are virtually undocumented and very rarely used.
I have had been toying with this question for quite a while now. My first meaningful introduction to using personal computers was with a Mac during their early years. Macs have always had at least two, genuine "character" modifier keys; as well as two "command" modifier keys. I think this distinction is an important one, although it is not typically, explicitly explained or mentioned. In the modern era Macs can functionally have up to 5 modifier keys; although there are some limitations on how they may be effectively utilized for various purposes. *nix OSes can support a whopping 8 modifiers, I believe. However, making use of them with a modern keyboard would require some remapping.
However, most of my personal computers have been Windows based, and when it comes down to it, Windows really only seems to support 1 true character modifier key: Shift. This is an absolutely unacceptable state of affairs for me! Why? I need to type WAY more characters than that!
Why? Because I have a strong interest and background in foreign languages, linguistics, phonetics and writing systems. I need to be able to type (without excessive difficult) many more characters and symbols than Windows seems to support. This is mostly for fun though, so it hasn't been crucially urgent. And I've been able to gain access to a Mac when I need to create/edit documents containing virtually any language besides English.
So, in Windows the Alt key is internally referred to as the Menu Key because it was initially used to access and navigate the command menus of applications in the days before Windows had adopted the use of a mouse. And it still functions in this capacity. Technically, it can only function as a modifier key if used in conjunction with Control. ISO Keyboards (European/foreign keyboards) often have a key called AltGr instead of the "right side" Alt key; it stands for Alternate Graphics and it is used to map the additional symbols and accented letters required by other languages to a "regular" keyboard by making accessible another whole layer or two of the whole keyboard, which effectively doubles (or even triples or quadruples) the number of characters that can be typed. Technically, the AltGr key is merely the one key which triggers the Alt and Control key simultaneously for the convenience of typists fingers.
You don't actually need an ISO keyboard in order to use AltGr and to access those additional characters; however, they make it much easier since they generally have have a the characters each key can produce printed on the key itself, like we do. All you really need to do is activate a keyboard layout for one of those languages (which are built into all versions of Windows). And you'll probably need to print out a diagram of the keyboard you choose to use. Or make stickers to put on your keyboard until you learn how to type all the symbols you need.
By the way, the Windows key IS a fully fledged modifier key, but its use is restricted for Microsoft to delegate as they see fit. (Actually, they designated that combinations using numbers as "free game" for OEMs to specify on their systems). It is designed as a modifier key on the hardware level.
The technology which supports most keyboards generally works just fine for standard usage of the keyboard (which typically does not include gaming) for typing, inputting text/data, research and so on. But, in order to safe costs and simplify they are designed so that the keys to be used as modifiers can be pressed together and recognized, along with at least one or two other keys. However, you quickly run into problems if you try to move modifiers to other keys on the keyboard and still hope to trigger "chorded" hotkeys (2, 3 or more keys pressed at once) because those keys weren't designed and given the hardware to function as modifier keys. The Windows key—even though it isn't used in that way in Windows (so far); it has the technical requirements.
Furthermore, Windows keyboards can be plugged into a Mac and and will work just fine. The Windows key corresponds to the Apple Command key; which is used extensively by most apps for triggering complex hotkeys/keyboard shortcuts— and it does this without issue.
So, despite the claims in another response; it is actually much easier to "add an extra key"- or several to your keyboard. Without the need for custom drivers, or even anything but the built-in OS driver. All you need to do is designate the key as one of the handful of additional keys found (and recognized natively by Windows) on various foreign keyboards.
There are three prominent keyboard types: ANSI (American), ISO (European) and JIS (Japanese); another common variant is the Brazilian keyboard; generally referred to as Abnt (which actually refers to the underlying "name" of the extra keys found on those keyboards: VK_ABNT_C1 and C2).
Technically, there are one or two unique keys found on ISO keyboards (known as VK_OEM_8, and VK_OEM_102). And Japanese keyboards can have more than 8 additional keys; however, they typically have 5-6 additional keys two of which are special keys used in the various methods of translating the few dozen key presses on a keyboard into one of several thousand complex ideograms. The other is a MODIFIER key! Korean keyboards feature it as well. It works like CapsLock, but instead of switching to upper case, it switches to the Korean alphabet or the Japanese syllabaries (because all computers still require a keyboard capable of typing Latin for passwords, etc. as far as I know). But it becomes very tedious and frustrating for users who switch writing systems constantly to have to switch the keyboard layout back and forth. So, they solved the problem with a locking modifier key that often has an LED light, just like CapsLock, to provide simple, instant visual cues as to which writing system will be produced.
Another type of Japanese keyboard was developed especially for ease and speed of typing. Although it never really took off (there were lots of different ideas and models in the 80s & 90s before anything was standardized), this keyboard by Fujitsu remains popular and a favorite for writers and anyone who much produce large amounts of text in Japanese.
Its special quality is that it has 3 large key which replace the space bar, only the smaller center key produces spaces, the other two are "thumb modifier keys" which are very convenient to use without finger acrobatics; they can even be combined with shift fairly comfortably and thus provide an extra large inventory of physically type-able characters. Technically they two modifiers are supported by Windows as well! Although, the support is scant and documentation virtually non-existent (at least outside of Japan).
However, it is still possible to make use of these keys in various ways if you remap and re-purpose a few keys on your keyboard- especially if you have a full keyboard with a number pad.
It's actually possible in Windows to have as many as 15 layers on your keyboard (including the base level) each of which must be activated by a unique combination of modifier keys. Actually, there are something like 48 possible (valid) combinations with: shift, control, Alt-Control, kana, loya and roya; so can't use anywhere near the theoretical possibility.
I've been using a special keyboard layout I developed that uses all those keys and has 15 layers which allow me to easily compose text in any language using the Latin alphabet (including any accented or modified letters), as well as the International Phonetic Alphabet (IPA) which is used to precisely document in written form any language or dialect on Earth. I also several layers dedicated to typing Ethiopic (I lived there as a kid); plus I have layers for rudimentary Greek, Hebrew and Arabic as well as a layer for symbols. Additionally, I have lots of deadkeys programmed into my keyboard—which are ideal for accented letters (first you press the key for a particular accent marking, but nothing happens until the next (or sometimes 3-5 keys) are pressed (if the deadkeys are "chained" to add several marks to a single letter, like Vietnamese does to an extreme degree); when the actual letter is typed it will have all those accents or marks stacked up/applied if possible.
What YOU need to make this possible?
A little piece of software called KbdEdit (the Premium version) which is VERY reasonably priced (IMHO).
There is a trial version you can check out for free of course; the website is PACKED with useful, fascinating and often obscure information on keyboards.
Other (free) software which allows you to do all sorts of things, including making use of all the modifier keys MUCH more freely for virtually any purpose is available as well. It is called AutoHotKey. I have been using it for years to do all sorts of nifty things (it's actually part of my system for remapping my keyboard for 3 additional modifier keys (it lets me "double use" keys so I don't lose functionality. For instance, I have physically remapped the two Japanese thumb modifiers to my Alt keys. I never use the Alt keys to access the menus in windows apps; however, I use software that does make use of keyboard shortcuts that contain Alt. However, as you may recall, Alt must always be used with Control to do anything other than navigate the menu. So, I didn't use any combinations of Control with the thumb modifiers on my custom keyboard layout (which posed no challenges). And I have AutoHotKey configured to convert simultaneous pressing of control and either thumb modifier to "control-alt" and if I happen to need just Alt by itself, pressing Windows+either thumb modifier is translated to Alt (since I've never encountered any shortcuts that required both Windows and Alt that created no conflicts.
I also DESPISE the trackpad on my laptop; trying to use to scroll is erratic and infuriating; furthermore, it is incapable of producing a middle click which I use extensively. So, I re-purposed that key that nobody uses that opens the "context menu" (because it's much easier just to "right click" to open that menu), usually called the "Application Key". If I'm holding it down (like a custom modifier), it translates arrow-key presses into scroll-wheel movement (in up-down or left-right axes), and it converts a space bar tap to a middle click. I also have some function or button programmed to be triggered by all of the other keys I can easily reach with that hand while holding that "faux" custom modifier. I'm able to control my media apps by simulating media keys that my little laptop doesn't have, and a host of other cool things.
AutoHotKey would probably be able to accommodate for most any reason you would want to add an additional modifier key to your keyboard, without actually going through all that rigmarole!
Windows W32 API defined Virtual-Key Codes. It is 8-bit, it provides 256 values and there is some gaps in table.
WM_KEYDOWN message operates on these codes.
Modern keyboards allow to detect up to 6 simultaneous key press but there are N-Key Rollover and Key Ghosting problems that you should be aware.
.Net API expose only Alt/Shift/Control as modifier.
In nutshell - many core APIs provided by Microsoft relay on Alt/Shift/Control as modifier even if modern keyboards allow near 5 simultaneous modifiers in addition to key press.
I don't know specifically about modifier keys, but many gaming keyboards now come with programmable keys and key macros, that could give you the extra functionality you're looking for.
Another possibility, if you're comfortable with programming at the level of C++, is to use the Windows Raw Input API, and plug in a second USB keyboard which your program could read a completely different set of input from.
https://learn.microsoft.com/en-us/windows/win32/inputdev/about-raw-input?redirectedfrom=MSDN
A third option might be to get a Raspberry Pi or Arduino to plug your keyboard into, and program it to read certain keys as your additional modifiers and send the desired output (as standard keyboard output) to your PC, with the Pi / Arduino acting as a "go-between" and emulating the keyboard. Maybe you could create your own Space-Cadet Keyboard this way.
I think the gaming keyboard with programmable keys will probably do what you're looking for, at the lowest cost and least time spent...
I have an application that can successfully inject keyboard input using the SendInput API with the UNICODE flag set. This causes WM_KEYUP and WM_KEYDOWN messages to be generated with the VK code of E7 (VK_PACKET), which gets appropriately translated into the correct WM_CHAR message. This works in all the applications I have tried except for Pidgin, which uses GDK. GDK seems to only look for WM_KEYUP messages. Since the ones being generated here don't actually have any indication of the input character (only the WM_CHAR does), the input is ignored. Is there a way I could get around this. I haven't had much luck if I use SendInput without the UNICODE flag.
When I had a similar problem, I used the clipboard as a workaround. A better way is to use WM_CHAR, and if I find a way to send Unicode characters with WM_CHAR, I'll update my answer. Since GTK+ is open source, you can contribute to it and help them (I'm a beginner with C).