Several times, a question came up how to synthesize keyboard input to a remote system given a text string. The remote system is typically but not necessarily a VM. That sounds like something which should be trivial, yet it is anything but.
The basic problem is that keyboards send scan codes which reflect the position of the key on the keyboard, not the character which a key press generates. The compounding problem is that there is a nearly infinite number of key to character mappings, also known as keyboard layouts.
And even for the most basic alphanumeric input, the keyboard layouts are crucial, because entering something as simple as ‘abc123’ requires a different sequence of keystrokes on US, German, and French keyboards.
If the sending system runs a Windows OS, the problem scope can be greatly reduced through several APIs: OemKeyScan, VkKeyScan, VkKeyScanEx, MapVirtualKey, and MapVirtualKeyEx. These all translate characters or virtual key codes into scan codes, either using the current keyboard layout or given a specific keyboard layout. Sounds great, right? Not so fast…
The intermediate problem is that there is no link between a physical keyboard and the keyboard layout used to translate the keystrokes. But for now let us assume that the layout is known and supported by Windows.
If the host OS isn’t Windows, then those APIs mentioned above are of course no good. But even on Windows, they aren’t always usable because they can’t handle dead key sequences, for example. In other words, the reverse translation does not work if typing a character requires more than one keystroke (other than modifier keys like Shift). It also doesn’t work if the keyboard layout cannot produce the given character.
For that eventuality, Microsoft offers sage advice: This function does not provide translations for characters that require CTRL+ALT or dead keys. Characters not translated by this function must be copied by simulating input using the ALT+ keypad mechanism.
As all readers of this blog know, DOS, OS/2, and Windows all support the Alt + keypad input method. This mechanism was originally implemented in the IBM PC BIOS so that users could easily input national and graphical characters not accessible through the keyboard. The Alt input method uses ASCII codes and it is thus independent of the keyboard layout used (though for non-ASCII characters, it does depend on the code page used).
By virtue of using the BIOS for keyboard input, DOS supports this method naturally. By the time OS/2 and Windows were conceived, the Alt input method was popular enough that it was supported by the native keyboard subsystems of the newer operating systems. Recent Windows versions also extended it to support Unicode.
So that sounds totally great, right? If ASCII/Unicode characters can be synthesized directly, there is no need to worry about keyboard layouts or anything like that, it’s just going to work.
Well… one problem is that the Alt input method is not supported by all operating systems. But an even bigger problem is that to a large extent Microsoft broke it in Windows Vista and all later Windows versions!
That sounds crazy, but unfortunately it’s not. On Windows XP, the Alt input method works consistently: Command prompt, renaming desktop icons, file open dialogs, Explorer and IE location bars, browser entry fields.
On Windows 7 and Windows 10, it still works in the command prompt and also for renaming desktop icons. But it does not work in file open dialogs, Explorer or IE, or the Cortana search bar. Using the Alt num pad input either produces nothing or only garbage characters.
The Command Prompt can perhaps be considered a separate case. But why does Alt+65 produce ‘A’ when renaming an icon on the desktop, but ‘♣’ when doing the same thing in an Explorer window? Only Microsoft can answer that, but it seems nowadays that Microsoft doesn’t understand Windows much better than anyone else.
At any rate, using Alt input is unfortunately not a viable method of synthesizing keyboard input to newer versions of Windows, even though it used to work well in the pre-Vista era.
I just tried it and it seems to work on Win7 64bit here. Physical hardware with USB keyboard. This post is done in IE and Alt-65 gives me “A.” All the Alt+keypad combos with 2 or 3 digits seem to work. I am confused. Did you set up one of the alternate entry systems?
I haven’t wandered over to other systems to test on other OSes.
Interesting. Can you please try in the “Search programs and files” entry field in the Win7 start menu? The best I can say for what I’ve observed is that the behavior is inconsistent. Now I wonder if it depends on PS/2 vs. USB keyboards, but I’ve seen the same behavior with both.
Okay, that is just plain strange. Sometimes, and only in the search box, I get either nothing or a lower case ae ligature. That goes for the start menu or the Win-F search. The address field of Explorer windows still provides an “A” when entering alt-65 everytime.
Leading zeroes are sometimes significant. For example, using Firefox, and typing into this “Comment” edit box, ALT+151 produces “ù” whereas ALT+0151 produces “—”.
Windows dialogs perform a lot of input filtering by default, and then allow developers to modify that behavior, so it wouldn’t surprise me if ‘non-vanilla’ keystrokes exhibit inconsistent output across the OS shell itself, as well as third party applications.
@Dale,
ALT-151 produces character 151 under the current OEM character set, often code page 437 – loosely speaking, the legacy IBM PC behavior.
ALT-0151 produces the corresponding Unicode character instead. That’s part of “Recent Windows versions also extended it to support Unicode”.
Leading zero is used to differenciate between Windows charset (with leading zero) and DOS (“OEM”) charset (without leading zero).
As someone with both a German and a US keyboard available I can safely say that the string “abc123” works exactly the same on both, no matter if Windows’ keyboard layout is set to DE or EN …
Okay, poor example, how about “xyz123”? 🙂 Or “(A)”.
Did you check the NumLock? For many programs (e.g. Word) NumLock should be enabled for Alt + keypad to work. Other programs (e.g. WordPad) are less picky.
The “problem” programs probably interpret the keys which may explain your example (ALT+65 is interpreted as ALT-RightArrow-5, which is handled as ALT+5, ♣).
Note that I did not check this on recent Windows versions (Linux only atm).
How strange! I just tried ALT+65 in the Start menu (Windows 7) and got ᧿ the first time, and nothing afterwards.
That’s U+19FF, or in decimal, 6655. Coincidence?
Bingo! Not a coincidence, you found the bug. They probably react to both key-down and key-up events. If I do Alt+6, I end up with ‘B’, which is ASCII 66. Alt+5 produces ‘7’ which is ASCII 55. Sigh…
But it’s more confused than just that, and as you also found out, after the first time, there’s nothing whatsoever.
Windows 10; using both an external USB keyboard and a laptop’s built-in keyboard (which is PS/2 according the device manager).
In the IE address bar (and the Windows Explorer path field), it depends on the num-lock state. I get “A” when num-lock is on and “♣” when it’s off.
Just about everywhere else, num-lock doesn’t matter and I get “A”.
Further testing seems to show that it’s caused the application intercepting shortcut keys. Since Alt+Arrow, Alt+Home, etc. (i.e. the non-num-lock keys of the numeric keypad) all have meaning to IE/Explorer these are intercepted and it’s interpreted as only Alt+5, i.e. PC-ASCII 5 which is “♣”. Indeed, typing Alt+74 produces nothing, but does trigger the “go to homepage” and “back” actions which are assigned to “Alt+Home” and “Alt+Left Arrow”.
In other applications that have meanings assigned to the Alt+(non-num-lock keys) the behaviour seems inconsistent, but the character seems to be always produced.
I tried to describe the NumLock dependency but Super did a better job. On my Windows 10 machine I can reproduce the behaviour with NumLock enabled/disabled as described by the main article exactly. I tried renaming files in the Explorer, search in the Start menu, Wordpad, Internet Explorer, … It all works with NumLock enabled.
This behaviour is not Vista+ but I saw the same in XP.
I could not reproduce the behaviour as described by Octocontrabass, no matter how I tried.
Interesting! This is the first I’ve heard of this problem (my laptop’s keyboard lacks a numeric keypad, so I generally just go look up the character in question online and copy and paste it into whatever application I need it for. MAJOR PITA sometimes.)