Key Mapper Developer Blog

User Mappings and Windows 7

Windows 7 (the RC build, 7100) no longer implements per-user key mappings: as Microsoft never documented it anyway, removing it is their perogative. This is unfortunate, as it's back to the days of Windows 2000 where key mappings apply to all users without possibility of exception and require administrative privileges to be created or removed. I can only speculate whether they were dropped because they were unsupported, or because they just wouldn't work with Fast User Switching, or accidentally, or they were in some way incompatible with the Windows 7 code.

 

It's a pain for me as KeyMapper expects Windows 7 to behave like Vista (*) and Windows Server 2008 and to implement scancode mappings in HKEY_CURRENT_USER\Keyboard Layout and so the program sets the mappings, we log off and on again, and Windows 7 then ignores the scancode mappings, and the key remapping fails and I get a very polite support email with 'broken' or 'doesn't work' in the subject line.

 

It's still possible to set mappings, though, in Key Mapper but you have to tell the program to 'show / boot mappings' from the Mappings menu and then authorise the Registry change and then reboot your computer.

 

So it looks like some new behaviour for KeyMapper under Windows 7 will be required. I might maybe just try and get a recent build of Windows 7 just to see if just maybe the RTM code will implement per-user key mappings before I even think about what to do (and how to deal with UAC).

 

(*) Because it's 'later' than Vista: Windows 7 was only a gleam when Key Mapper 1.0 was released.

If you find yourself using a keyboard without an Insert key (eg recent Mac keyboards) but Overtype mode has enabled itself somehow, then it's useful to remember that the 0 key on the Numberpad is a surrogate Insert key, but only when Num Lock is turned off. If you have NumLock set On and the NumLock key disabled, though, this is a small problem: KeyMapper lets you toggle the value of Num Lock from the Toggle Lock Key menu, so you can set it off temporarily, switch back to Insert mode using Numberpad/0, then toggle Num Lock on again.

Remapping Pause and Num Lock

The Num Lock key (along with the Insert key) is one of the keys most likely to be disabled by any scancode mapping program: it is hardly ever used and the effects of accidental pressing it are confusing and annoying, to users and support teams. There are 133 637 results when searching the Microsoft support site for Num Lock. Keyboard design is staunchly conservative, though, and the 101/102 keyboard keys have remained essentially unchanged since introduced by IBM in 1984.

 

One of the reasons for the conservatism is that keyboards use numeric codes - scancodes - to identify which physical key has been pressed. These scancodes include one bit to identify the key itself, and an extra bit to show if the key is extended. This derives from the extension of the original 83/84 PC/AT keyboard to the 101 key keyboard: in some cases where the functionality was the same, rather than assign a whole scancode to the extra keys, an extra bit was added. For example the Enter and Return keys both have a scancode of 28 (0x1C), while the Enter key (the one on the numeric keypad) has the extended bit set; similarly the Left arrow key and the number 4 on the numeric keypad (which is Left with Num Lock set off) both have a scancode of 75 (0x4B), but the arrow key has the extended bit set. This was presumably for backward compatibility with systems which didn't expect the extra extended bit.

 

Keyboard drivers can change or interpret these codes themselves - and often do: although keyboard power and standby keys have been assigned specific scancodes, the actual operations are controlled by the keyboard driver; this means that a) the power keys usually can't be disabled using scancode mapping and b) it isn't possible to assign an existing key to these functions. Scancode mapping programs like KeyMapper usually allow the selection of the key to be disabled by reading the keypress: Num Lock, unlike all other keys, reports itself differently on different keyboards. Most keyboards use the usual code - 69 (0x45) - to identify the key with the extended bit set off, but some set the extended bit on. This can cause confusion, as systems expect the code of 69 with extended on to represent the Euro symbol, on keyboards which have that. Using that key code in a scancode mapping also fails to correctly map Num Lock: scancode of 69 without the extended bit set must be used in mappings no matter what the keyboard reports as the scancode.

 

The Num Lock key is also involved in the most complicated remapping scenario, the Pause key. At first I couldn't figure out how to remap the Pause key at all, and thought that it couldn't be done. Then I stumbled across a blog post which indicated it was possible and provided me with enough information to work out how to implement it.

 

When the Pause key is pressed, internally this generates multiple keystrokes, specifically Ctrl and Num Lock. This is explained by another blog post, coincidentally posted within two days of the other one.

in the original PC/XT keyboard layout, there was no Break key. The key sequence for Break was Ctrl+ScrollLock. (And for completeness, the key sequence for Pause was Ctrl+NumLock.) Even though the enhanced keyboard moved the Pause and Break functions to their own key, pressing the Pause key internally generated scan codes that simulated a press of Ctrl+NumLock. In other words, when you pressed Pause, the keyboard hardware actually tells the computer, "The user pressed the Ctrl key and then pressed the NumLock key."

 

That's not quite the whole story, though - so systems can distinguish this from a regular Ctrl-NumLock, a different extended value is used - instead of 224 (0xe0) the keyboard will report 225 (0xE1). This is as far as I know the only time this extra extended value is used.

 

This complicated the UI for KeyMapper: should a user want to disable or remap the Pause key, then Num Lock will still fire each time it's pressed: to remap Pause to a single keystroke, Num Lock must be disabled as otherwise Num Lock will be toggled each time Pause is pressed.

 

However, it also introduced an interesting new possibility: if Num Lock is remapped to another key then that key will also be 'pressed' when the remapped Pause is pressed: this means the Pause key can be remapped to a keyboard command which requires two key strokes, for example Windows-L (the shortcut to Lock Computer), or Right-Alt and 4 for the Euro symbol. These require the Pause key to be remapped to the first key in the sequence and Num Lock to be remapped to the second.

User Key Mappings

One thing that distinguishes Key Mapper from other scancode mapping programs is that it lets you map or disable keys on a per-user basis: when Microsoft originally implemented scancode mappings in Windows 2000, they stated in the "disadvantages" section:

The mappings stored in the registry work at system level and apply to all users. These mappings cannot be set to work differently depending on the current user.

This is because the mappings are stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout which needs Administrative access to change and is only loaded at boot time.

 

In Windows XP, though, per-user mappings were quietly introduced, with no fanfare or documentation: scancode mappings set in the HKEY_CURRENT_USER\Keyboard Layout key are recognised, and apply to an individual user profile. This means that mappings can be added or removed by logging off and logging back on again - still inconvenient, but less so than a full reboot: it also means that mappings can be set up users without Administrative rights. (Mappings set in HKEY_LOCAL_MACHINE are overridden by those in HKEY_CURRENT_USER).

 

It's possible that Microsoft kept this quiet because user mappings are incompatible with Fast User Switching: when you switch to an account that's already logged on, the mappings are not reloaded. It's also possible that because they kept it quiet, the Fast User Switching development team didn't realise that user mappings should be reloaded when switching users. Boot mappings persist through Fast User Switching.

 

While this is a possible disadvantage to using user mappings, most people probably don't use more than one account on their computer anyway, and in computers attached to a domain (i.e. corporate PCs) which may often be used by different people Fast User Switching isn't available anyway.

 

There are some other advantages to user mappings:

  • They don't require Administrative rights to be set or removed.
  • Different users can have different mappings - one can have Caps Lock disabled but Num Lock enabled, another can have them the other way round
  • Keys can be mapped on shared computers without affecting all users


There is yet another place scancode mappings can be set - in the HKEY_USERS\.DEFAULT\Keyboard Layout key. These apply at the login prompt, but are then removed when logged in.