Why doesn't MSKLC have a numeric keypad?

The other day, in response to my Who would win in a fight between VK_DECIMAL and LOCALE_SDECIMAL? post, someone by the [unlikely] name of ReallyEvilCanine asked:

Why not include the number pad in the KLC? It would let me change it to a hex keypad for entry as easily as I change keyboards now. I admit a bit of creativity is required but yes, some people actually spend a not-insignificant amount of time typing in hex values.

Quite a reasonable question, and one that is worthy of an answer, I think....

First let me point out that I myself type in a great number of hexadecimal numbers-- think of all those Unicode code points I have to type in, whether in a Unicode IME or for some other reason.

So let's just say I am sympathetic to the reasoning here. :-)

There are actually several reasons why the numeric keypad is not included though.

There are philosophical reasons, based on who initially envisioned and developed MSKLC (two PMs and a developer on the GIFT team, and that they were focused on being able to build keyboards for languages not yet covered by Windows), where changes to the numeric keypad are simply not a high priority.

There are technical reasons, such as the ones I hinted at in this post, related to the very special handling rules of the numeric keypad that from the point of view of the USER keyboarding API set duplicate scan codes (mitigated somewhat in Vista by updates to MapVirtualKey[Ex] but those updates did not exist when MSKLC was released).

And of course there are the technical reasons that cause the difficulty and complexity of the VK_DECIMAL handling I talked about in the original post that got our very bad dog to ask the question. The fact is that applications handle the numeric keypad in their own special way, and since they use different techniques it is hard to know what applications one might break if all the mappings change (even the VK_DECIMAL inclusion was heavily debated with keyboard experts before MSKLC was initially released).

There were even conservation of real estate reasons, related to trying to keep the tool able to work at lower resolutions. That made adding the numeric keypad more than a bit difficult to justify for a tool initially designed to help with better language support. This sort of thing is taken very seriously....

And it is hard to forget the historical reasons -- not a single keyboard ever developed for Windows had modified the numeric keypad (with the solitary exception of the VK_DECIMAL assignment). No one was eager to set a precedent here, you know? :-)

But to be honest there was not an explicit judgment made about the issue -- and these are sort of the excuses that someone like me talks about in retrosopect. You know, hints of truth but in the process of becoming fully formed in a blog post one realizes there were actually other reasons, and so on.

The real reason is that in the end, MSKLC is a software project with specific goals, and anything that does not fit into those goals is unlikely to make it into the deliverables (projects that are not run this way either never ship or ship way too late). Which is kind of why the numeric keypad did not make it into MSKLC....

Now this does not mean it will never end up there -- new versions have new points of focus, new goals, and then from that new deliverables. So who knows what may happen one day in the future? :-)

This post brought to you by ೮ (U+0cee, a.k.a. KANNADA DIGIT EIGHT)