Sorting it all Out Michael Kaplan's random stuff of dubious value Be sure to read the disclaimer here first!
The other day, someone asked me for my thoughts on 'hacked' MSKLC to enable remapping CAPSLOCK.
This is the article over on the Colemak Forum from last year about the method they describe to perform the task of remapping the CAPSLOCK key in MSKLC-created keyboard layouts.
The method doesn't use hidden command line switches to MSKLC.EXE (there aren't tons of these there anyway).
It doesn't use hidden command line switches to KBDUTOOL.EXE (something several customizations I have mentioned in the past do).
It doesn't use special modifications to the .KLC file (something several other customizations I have mentioned in the past do), either.
What it does is give instructions to make specific modifications to the KBD.H header file (basically scrolling to a certain part of the file, the part for the "Type 4" keyboards, and replacing the word CAPITAL with the word BACK).
In case you ever wanted proof that a little knowledge is a dangerous thing, now you have it!
Allow me to explain.... :-)
I have talked about Keyboard Types before, in blogs like Knowing the layout doesn't mean knowing how to lay it out.... and the difficulties MSKLC and kbdutool have with it in particular in Had I known that my last release would be *the* last release..., aka hindsight is 2020.
As I mentioned in the latter blog, there is no direct way to control what keyboard type one will get when one creates a keyboard layout. So while type "4" -- IBM enhanced (101- or 102-key) keyboard -- is common, it is not the only one.
There are going to be times that this particular hack won't work at all (basically any time KBDUTOOL.EXE thinks it is another keyboard type that it is building)
And of course not all the hack's suggestions work, by the report of people there. For example, in looking specifically at the behavior of the special new CAPSLOCK that is now a backspace, Anders notes:
I tried this, while it does work... when you use the Caps Lock key repeatedly it only registers the backspace every second time.
Yes, this makes sense -- since the logic behind the key is not in the keyboard layout DLL itself; it is partly in the system's knowledge of the scan code that thinks of this key as a toggle switch (something the BACKSPACE definitely is not).
There are very few keys, in fact, that will seem like they behave properly when they have some of the "toggle key" semantic injected into their behavior. Unless they too are being used as a toggle of some sort.
Plus, I really like to avoid updating both SDK and WDK header files (KBD.H is a part of the WDK), because there can be unexpected consequences even beyond the ones I mention here if you try to build keyboards using the file.
One could use one's imagination and perhaps see programs that make CAPSLOCK/toggle key assumptions could themselves show errors, fail, or crash when they are given results that most closely resemble a Rubik's Cube that has been taken apart/had one side piece rotated 180°/put back together. You know, when you modify the cube so it can't ever be solved?
It believe it is even technically be a EULA violation, though I can't imagine it ever being enforced in this case, I mean unless someone tried to sue Microsoft for negative consequences of using a keyboard created by this means. In which case the use of the hack would be a pretty reasonable indemnification of Microsoft here, since someone delved into the land of the specifically unsupported....
So, my thoughts on 'hacked' MSKLC to enable remapping CAPSLOCK?
Clever idea, but it doesn't really solve the actual problem people want solved, which is that the CAPSLOCK key is sending information to the machine and keyboard layout DLLs are not designed to remap behavior fully (especially for the many keys that other parts of the system and other apps might try to make their own use of).
Similar problems can be seen in other keys as well, basically any key with special behavior beyond typing characters can have this kind of "baggage", and one key that just types a character yet still has special meaning (the VK_DECIMAL key, an issue I discussed previously in Who would win in a fight between VK_DECIMAL and LOCALE_SDECIMAL?.
To truly solve the full problem:
is required. A keyboard layout solution will always be incomplete since it cannot modify the scan code being sent....
Ctrl2Cap is something I've used previously.
Thank you for the explanation.
I switched CapsLock and Backspace in 2009 (before the "hack" post came out in Colemak forum).
I don't use Colemak, but love the idea of remapping CapsLock.
My method is from:
First, I used "kbdutool.exe -u -w -s kbd*.klc" to get the kbd*.c file.
Then, I modified the "static ALLOC_SECTION_LDATA USHORT ausVK" section (line 28), just switched T0E (Backspace) and T3A (CapsLock).
Finally, I got the kbd*.dlls through cl.exe/rc.exe/link.exe command lines. (The arguments in the webpage is from MSKLC 1.3, for v1.4 you should use Process Monitor to get the correct arguments.)
I have used the remapped keyboard layout for 2 years. I haven't encountered any big problems. Some games may directly manipulate Scan Codes, may lead to some problems. But I don't play games much, so I can't verify.
The only small "problem" is On Screen Keyboard (osk.exe), it assumes all control keys (Ctrl/Shift/Alt/Tab/Backspace, ect) are not changed. CapsLock is still printed "CapsLock", But this won't change key behaviors. If you press "CapsLock" on OSK, you can still get "\b", but the "CapsLock" button shows the CapsLock are toggled. This really is not a big deal. And I think the main reason is that OSK assumes all control key are not remapped.
And personally, I don't think any program will "crash" because of remapping CapsLock.
You said, "basically any time KBDUTOOL.EXE thinks it is another keyboard type that it is building".
Whether I hacked the "kbd.h" or not, I got the same "kbd*.c" files by kbdutool.exe. The arguments of cl.exe/rc.exe/link.exe didn't show anything related to KBD_TYPE. And there is no KBD_TYPE definition in "kbd*.c".
I don't know when the KBD_TYPE is defined when compling kbd*.dll files? Only one KBD_TYPE is defined in each kbd*.dll, right? My assumption is that MSKLC always assumes KBD_TYPE==4, or just leave it undefined, because its default value is 4.
And I don't think this is really a big problem. Most of us will never use other keyboards that KBD_TYPE is not 4.
Our goal is make it work for keyboards that we are using, that's enough. If in your opinion it's really a big promlem, what if we modify all the ranges of KBD_TYPE in kbd.h? Or maybe my solution of modify kbd*.c is a better solution?
My conlusion is that it's not "dangerous" at all.
MSKLC is really a great tool, but has many limitations. Yes, I know you just want to be 100% careful. But why can't MSKLC let us do something "at our own risk"? Sharewares like KBDEdit allow you to modify every key except Pause key. Another program (I forgot the name) allows you to generate dozens of Unicode characeters for each key (MSKLC has a limitation of 4).
I hope maybe in next version, MSKLC will be more flexible. (And Windows programs like OSK won't assume control keys are not remapped.)
BTW, another way of reamapping CapsLock is to modify Scan Code map (through applications like KeyTweak). But this method will affect all users of Windows, so it's not recommended if your computer is public or shared.
Also, you can use keyboard hook programs like AutoHotkey, but these programs aren't 100% stable.
So, I think modify keyboard layout is the best way of doing this, and more importantly, it doesn't require other applications.
Since I have cited examples where other people had problems when different keyboard types were chosen, why the solution won't always work has already been made pretty clear. The true solution will have to be one of the methods I mentioned.
As for new MSKLC releases, I have already given my thoughts on that both in this blog and elsewhere in other blogs.