Windows keyboard restrictions

Doug Ewell doug at
Fri Aug 7 16:34:47 CDT 2015

Richard Wordingham <richard dot wordingham at ntlworld dot com> wrote:

> It's good to see he's still with us.

Still out there, just not on this list.

> What we're waiting for is a guide we can follow, or some code we can
> ape. Such should be, or should have been, available in a Tavultesoft
> Keyman rip-off.

I guess you mean that such a guide would expose the Windows
infrastructure to help explain the inner workings of the third-party
software. That would be informative only to the extent it was accurate.

> In the mean time, I notice Micha Kaplan's comment:
> "even if there were, such a keyboard layout would not be compatible
> with any prior version of Windows;"
> I think that is exactly what Marcel Schneider encountered.

Sort of. Michael was saying that IF the Windows limit had been increased
from 4 to something higher, and someone implemented a keyboard taking
advantage of that higher limit, it would not work on older versions.
Marcel implemented a keyboard that took advantage of a higher limit
which never existed on Windows, so it doesn't work on ANY version.

But wait! Didn't he say it worked some of the time, with some shift
states but not others?

Sure it did, for the same reason that a buffer overrun in C doesn't
always cause a program crash or a security hole. Sometimes, if you're
lucky, the memory being overwritten doesn't contain critical data at the
time of the overwrite. Sometimes you're not so lucky.

> Note further that Micha implied that he got the specification by
> reading a header file, exactly the sort of documentation you
> disallowed.

I wasn't looking for documentation that the well-known limit of 4
existed in the first place, or had not been changed. I was looking for
documentation that it HAD been changed. That's where the burden of proof

Michael probably has more extensive expert knowledge of the Windows
keyboard subsystem than anyone else, which is why I asked him.

> The data structure (field cbLgEntry) allows for arbitrary lengths; its
> precise semantics may have been established by experiment. It is
> possible that it may have been broken for arbitrary sizes and has now
> been fixed.

I don't know what "has now been fixed" means. I haven't seen any
evidence that anything about this has changed since the '90s.

> MSKLC doesn't seem to be liked by Microsoft. Quite possibly they would
> like to get rid of the interface its keyboards generate. Supporting
> such user-defined keyboards may just be an overhead for them.

I doubt they ever have to provide support for user-defined keyboards. I
see that MSKLC itself "is distributed 'as is', with no obligations or
technical support from Microsoft Corporation."

If we're speculating on Microsoft's intent, my guess is that the move to
TSF is some sort of attempt to consolidate desktop, tablet, and phone
keyboard behavior into a single framework. I confess I don't know much
about TSF.

> Any comment from the Microsoft employees?

Doug Ewell | | Thornton, CO ����

More information about the Unicode mailing list