The Misadventures of Quinxy truths, lies, and everything in between!


Remapping your 101 Key Keyboards (e.g., IBM Model M) to Restore the Windows Key, Menu Key, Media / App Keys on Windows

Thought I'd share this for others using an older 101 key keyboard (like the venerable 1980s/1990s IBM Model M) on Windows.

Using this registry entry I get back my Windows and Menu key:

  • <Shift Lock> is now the <Windows> key
  • <Right Alt> is now the <Menu> key

Just save this code as .reg and double click the file to merge it into the registry, then reboot (or download the file from the link below).

Windows Registry File:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,5c,e0,3a,00,5d,e0,38,e0,00,00,00,00

You can add your own remapping by reading this Microsoft document which describes the format of this registry key and using these scan codes.

I also wrote a little Autohotkey script to make my entirely ignored number pad useful again, with media, volume, and app launching keys.

Here are some basics:

  • <Number Pad 5> is Volume Mute
  • <Number Pad 8> is Volume Up
  • <Number Pad 2> is Volume Down
  • <Number Pad 6> is Next Tab (<Ctrl> + <Tab>)
  • <Number Pad 4> is Previous Tab (<Ctrl> + <Shift> + <Tab>)
  • <Number Pad 1> is Previous Media Track (works in Spotify, Winamp, WMP, etc.)
  • <Number Pad 3> is Next Media Track (works in Spotify, Winamp, WMP, etc.)
  • <Number Pad 0> is Play/Pause Media Track (works in Spotify, WMP, etc.)
  • <Number Pad *> launches Task Manager
  • <Number Pad /> launches default browser with

AutoHotkey Script:

SetNumLockState, AlwaysOn
Numpad8::Send {Volume_Up 5} ; increase sound level
Numpad2::Send {Volume_Down 5} ; decrease sound level
Numpad5::Send {Volume_Mute} ; Mute sound
Numpad6::Send {LCtrl down}{Tab}{LCtrl up} ; Next tab (ctrl+tab)
Numpad4::Send {Shift down}{LCtrl down}{Tab}{LCtrl up}{Shift up} ; Previous tab (ctrl+tab)
NumpadMult::Send {Shift down}{LCtrl down}{Esc}{LCtrl up}{Shift up} ; Task manager
NumpadDiv::Run, ; Browser to Google
Numpad0::Send {Media_Play_Pause} ; Pause/play media track
Numpad1::Send {Media_Prev} ; Previous media track
Numpad3::Send {Media_Next} ; Next media track

You can just paste that into Autohotkey, compile it into an EXE, or download my compiled exe below.

Download (374 kb).

Instructions for Download:

Download the file, unzip it, double click the registry file to add the registry entry (reboot to activate the change), and then run the common_remaps.exe to start the number pad remapping.  I added it to my Startup folder in the Windows menu.

(The AutoHotkey script forces Num Lock on so that the hotkeys will work, you can remove that line in the script if you don't need this.)

Users on Deskthority alerted me to the tools Key Tweak and Sharp Keys, tools which lets you do much of the above automagically, through a nice GUI!  That said, the advantage of the AutoHotkey script is that you can script complex and even context-dependent interactions, which only matters if you need or want to do it.)


AutoHotKey versus AutoIt

I've been a huge fan of and user of AutoHotkey (AHK) for years, but I've got to admit (with a sense of betrayal) that I'm increasingly impressed with AutoIt. Last week I had an automation project I had to do and began to code it in AHK only to run into several major roadblocks. For the automation I needed to travel a thirdparty application's tree view UI to find a specific entry and click it. Later in the automation I had to do something similar with a list view control. I had expected to find easy mechanisms or code samples to do it in AHK. To my surprise I found relatively little, the built-in functions related to the GUI creation of those elements not the manipulation of already existing elements. And the little sample code/DLLs I found didn't seem recently updated and didn't work (with AutoHotkey_L). I accidentally stumbled across AutoIt threads on the topic and was pleased to discover it was quite easy with AutoIt, and their official support of those features in their standard include libraries. And thus began my journey into AutoIt.

Here are my impressions:

  • The language syntax of AutoIt is more consistent than AHK, and mostly for that reason I liked it more. When I first started with AHK I found it really confusing that AHK supported multiple distinct paradigms (foo = bar and foo := "bar" as well as the whole Foo(Bar) and Foo, Bar (not to mention Foo Bar, the first comma being optional!?). I still find myself making quite a few typos/errors related to these situations... Forgetting what's a normal function and what's the other style function, putting a := when I meant a =. I'm sure the explanation for all this is historical, but the lingering embrace of all the styles simultaneously is odd (why can't Foo, Bar be called as Foo(Bar) so that people can write to the new paradigm)!! Oh, not to mention the hotkey hooking/specification stuff right there mixed in with regular code, which also confused me.
  • The packaging of the setup/install of AutoIt is impressive, including the SciTe editor, example code, the extended library of functions, x86 and x64 compilers, obfuscator, build tool, auto updater, and more. I haven't installed AHK recently, so maybe AHK does just as complete an install. I was just pleased that in my testing/development I had to set this up on 4 computers and I couldn't have asked for an easier time of it.
  • AutoIt has embeddable compiler and obfuscator directives! You can embed commands in the source that will trigger obfuscation, generation of both x86 and x64 binaries in one compilation run, you can include resources, set the EXE manifest-related data including administrator elevation, PE details, etc. Very nice!
  • AutoIt Help files are almost useless when compared to their AHK counterparts. The index list and the keyword search functions seemed to miss a great deal that should be in their documentation, and it seems as though they do not include many (if not most) of their official support library functions in the help documentation. If you do find the page you need in their docs then everything is okay, they have good examples and references, but I'd swear 60-70% of the time I couldn't find what I needed and had to jump over to their forums or search with Google.
  • The AHK community is absolutely amazing, and it would be hard to top them in terms of friendliness, helpfulness, knowledge, code-sharing, etc. I have only been an observer on the AutoIt boards as I looked for other people's solutions, and so perhaps my observation is meaningless, but I saw more grumpy unfriendliness towards newbies than I'd remembered seeing on the AHK boards. (I'm not saying the AutoIt community isn't great, too, it probably is, it just might be a little less tolerant of newbies and their poorly researched questions.)
  • AutoHotKey automatically handles most UI interaction logic for you (via gGotoLabelName calling identifiers in the various GUI element creation functions) whereas AutoIt requires you to create your own windows message processing loop with switch/select message to handle every interaction to which you want to respond.
  • As mentioned earlier there's a distribution-included obfuscator, which seems pretty good. The quasi-lack of one with AHK has been an annoyance of mine; AHK_L doesn't do the password thing any more, and I never had much luck with Hotkey-Camo or anything else.
  • I was impressed with how quickly I was able to jump right into AutoIt using my AHK knowledge. I imagine it'd be harder coming the other way, because of the unusual multi-paradigm AHK language thing. Both languages are remarkably similar in their use, with many functions being identical in name and use. Example: Send, Foo in AHK is Send("Foo") in AutoIt. Within a few hours I was able to automate a relatively complicated and branched Windows dialog flow (related to driver installation, involving tree view navigation, list view navigation, support for different scenarios on different versions of Windows, etc.).

In no way am I concluding that AutoIt is better than AutoHotkey, nor can I conclude the opposite. My love of AutoHotkey isn't wavering, but I am glad AutoIt was there for a task which seemed like it would have been harder for me to do in AHK with the existing public code. So if you ever find yourself in a similar situation you needn't feel shy about trying out AutoIt.