Re: Windows keyboard restrictions

I've got a bug in my mailbox. While taking care to send my e-mail in plain text, I got it converted somehow to HTML with all "tags" disappearing.
So I ended up replacing all < and > by single angle quotation marks. That seems safer than converting them to HTML codes.
Perhaps I shouldn't call it a bug, but just that I don't know how to use a mailbox. Sorry to send it twice.
N.B. I'll send two others in reply to the emoji thread, I just can't do it all at once.
___________________________________________________________________

A part of the documentation you request is available:

“Download Windows Driver Kit Version 7.1.0 from Official Microsoft Download Center.” N. p., 1 Dec. 2014. Web. 1 Dec. 2014.

https://www.microsoft.com/en-us/download/details.aspx?id=11800

C:\WinDDK\7600.16385.1\inc\api\kbd.h

Line 469, and preceding.

---
Note: This file can be accessed on-line on third party websites. You may wish to try a Bing* search for "kbd.h".
* My preferred internet search engine is Bing ☐☐
[This ballot box U+2610 is on my keyboard at Shift+Kana+L.]
---
To circumvent the issues araising from the word “bug”, we may simply ban that and focus on a few comments:
* Ligature is an internal name for Wchar sequences that are 
* generated when a specified key is pressed.
*
* The ligatures are all in *one* table.
* The number of characters of the longest ligature
* determines the number replacing the ‹n› in
* static ALLOC_SECTION_LDATA LIGATURE‹n›
* and in
* ‹n›,
* sizeof(aLigature[0]),
* (PLIGATURE1)aLigature
* below in the static ALLOC_SECTION_LDATA KBDTABLES.
*
* The maximum length of ligatures is 16 characters.
* Characters from 17th on are discarded.
*
* The ligatures table must be defined for ‹n› characters, 
* whether in kbd.h, or kbdfrfre.h, or here before,
* using the following define:
* TYPEDEF_LIGATURE(‹n›) 
* For clarification, a trailing comment is added:
* // LIGATURE‹n›, *PLIGATURE‹n›
* Tables for up to 5 characters length are already defined in
* C:\WinDDK\7600.16385.1\inc\api\kbd.h.
*
* The lasting Wchar fields of each ligature that is shorter than 
* the maximum length defined, may be filled up with 0xF000, or with
* WCH_NONE as defined in kbd.h, or NONE if defined in the custom header.
* These entries may be shortened, especially when the ligatures table
* is not edited in a single spreadsheet table.
Whatʼs new for me, is that “sometimes” [scare quotes], the ligature length must not exceed four characters. I already knew whatʼs written in the MSKLC Help about this topic, and I explained in my previous e-mail that, when the MSKLC was built, Windows did not support more than four characters per ligature. (Thatʼs the only straightforward explanation of this point of the MSKLC.) As this proved to be insufficient, Microsoft must have decided to raise the limit to sixteen. Following some advice I programmed a ligature of 35 characters on Sat Feb 28, 2015; thus I've got the opportunity of seeing that 16 characters were inserted, while the overflow was discarded. Windows worked normally. The mapped virtual key was VK_OEM_COMMA, and the modification number was 8, that was Shift+AltGr+Kana (which it is still today).
After the recent event, we may add the following:
* CAUTION: THE INITIAL MAXIMUM LENGTH OF LIGATURES WAS 4 CHARACTERS.
* DEPENDING ON THE SHIFT STATE, IT MAY HAPPEN THAT LONGER LIGATURES
* CAUSE THE KEYBOARD DRIVER TO FAIL.
* IF THE FAILING DRIVER IS THE ONE OF THE DEFAULT KEYBOARD LAYOUT,
* THE SYSTEM MAY NOT WORK AS EXPECTED.
Iʼm hopeful that you will agree upon this formulation, and I hope that helps.
Best regards,
Marcel Schneider
On 03 Aug 2015, at 20:02, Doug Ewell wrote:
> Marcel Schneider wrote:
> 
> > The bug on Windows I encountered at the end of July has been
> > definitely identified and reconstructed. After ninety-five drivers
> > compiled since the bug appeared, I can tell so much as that the
> > problem is related to the length of the so-called ligatures. When the
> > MSKLC was built, they were limited to four characters on Windows (see
> > glossary in the MSKLC Help). On my machine the maximal length is 16
> > characters. The problem is that this is not equal on all shift states
> > and perhaps keys. Roughly, I can put five characters on modification
> > number three, that is normally AltGr, but not on #4 (Shift+AltGr).
> 
> As far as I can tell, the limit for a ligature on a Windows keyboard
> layout is four UTF-16 code points:
> 
> MSKLC help, under "Validation Reference":
> "Ligatures cannot contain more than four UTF-16 code points"
> 
> Presentation from IUC 23 by Michael Kaplan (author of MSKLC) and Cathy
> Wissink:
> http://tinyurl.com/o49r4bz
> 
> KbdEdit:
> http://www.kbdedit.com/
> 
> MUFI:
> http://folk.uib.no/hnooh/mufi/keyboards/WinXPkeyboard.html
> 
> I understand that there are some tools (such as Keyboard Layout Manager)
> that claim a higher limit, and it may even be possible in some cases to
> assign more than four, but the DOCUMENTED limit appears to be four. (If
> you claim that it is not, please provide a link to the relevant official
> documentation, and note that C++ code showing 16 fields is not
> documentation.)
> 
> It is not a bug for software to fail to perform BEYOND its documented
> limits.
> 
> Since you are so very eager to declare this a bug, or a collection of
> bugs, rather than a design limitation, I strongly recommend you get in
> touch with Microsoft Technical Support and express your concerns to
> them. Make sure to let them know just how certain you are that these are
> bugs. See if they'll send you a T-shirt.
> 
> --
> Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸
> 
> 
>