Re: Windows keyboard restrictions

On 08 Aug 2015, at 00:18, Doug Ewell wrote:

> Marcel Schneider wrote:
>
> > I just donʼt want to let the Mailing List believe that I agreed being
> > classified as «fighting the [bad] fight»
>
> And I don't think Michael implied that. I just want to get the technical
> facts, so that hopefully they can take the place of speculation and
> presumptions of buggy behavior.
>
> Please note that "bug" is not necessarily a bad word -- we developers
> create real bugs all the time, and hopefully own up to them -- but it
> rankles when someone applies the word to software that works as
> designed, when that person either doesn't understand or doesn't agree
> with the intended behavior.

Excuse me please to have referred to the phenomenon as being a bug. I got strong habits with that word at the time I was writing down my observations and sending a few of them to the Microsoft Community Answers Forum. Indeed some handled user unfriendly design limitations, like the disabling of Ctrl+A in the Formula Bar of Excel, or real bugs that have been fixed in the following version of Word, like the disabling of automatic word break when an apostrophe other than U+0027 is included, or the undue application of autocorrect after an automatic word break. But that's past. It's just to explain that the banned word was always about the first thing that came at mind to me. Well, sometimes even when the problem was that I didn't know how to use the software :-|

>
> > Thus, this blog post is biased with the authority bias.
>
> It's from someone at Microsoft with expert knowledge of the Windows
> keyboard subsystem, if that's what you mean.

Not at all... The problem is the bias, not the authority. I don't take an authority-contesting posture.
Let's take the example of somebody making a speech with a presentation about keyboards on Windows. Depending on how the topic is labelled, if it's a general outline of the whole keyboard UI, he must speak about all possible modifiers, that is Shift, Ctrl, Alt, Alt+Ctrl which is AltGr, Kana, to quote just the easiest to implement. There is also Oyayubi (Right Oyayubi, Left Oyayubi), but that was for Fujitsu terminals and I don't see how it could work on Western keyboards; perhaps it does. But Kana is so obvious it is implementable on KbdEdit. It's very useful, along with its toggle KanaLock (VK_KANA). This is why, the Help Glossary of the MSKLC cites the WDK and provides a download link. Then he must speak about chaining dead keys, because that's a Windows supported feature (you equally can implement using KbdEdit). When it comes to dead keys, he is forbidden to make hes audience believe that a dead key is just a combination of two keys, the first of which shows no effect. He may say this to take on the topic, but he mustn't end without mentioning that dead keys can be chained on Windows. Imagine the man making such a speech not in Praha but in Hanoi. Will he wait for the QA to tell that Windows allows to press two dead keys before a letter key to get letters with two diacritics, as they are used in Vietnamese and encoded in Unicode? If he does, it would be wise not to post the PowerPoint on the internet.

>
> > Iʼm not quite sure whether people are conscious that by contesting the
> > accuracy of the original actual Windows keyboard driver header file
> > (kbd.h), they are insulting the developer(s) who wrote it, as well as
> > the company that stands behind him/them.
>
> kbd.h contains exactly zero examples of keyboards with ligatures with
> more than 4 code points. I downloaded and installed the whole DDK just
> to find this out, not realizing I already had a copy in my MSKLC folder.

What did you exactly find out? That there are no examples of keyboards with ligatures? That's accurate. In the actual Windows Driver Kit (WDK), there are zero examples of keyboards with ligatures. This point is noteworthy, as it says much about the support Microsoft grants developers of keyboard layouts. Tell me what's the use of that poor samples collection, letting you alone with programming a ligatures table from scratch! Fortunately, I got around this job. But that's not the topic.

Now about what kbd.h contains. It contains a define for a ligature table with two characters, then it contains a define for a ligature table with three characters, then one for a table with four characters, than one for five. Oh what? Yes, for a ligature table containing ligatures of five whole Unicode characters. This define has been quoted in this thread, so there's nothing new. Further we know that kbd.h is not the only header file of a given keyboard layout. Each driver has its dedicated header file. To put what in? Scan code to virtual key undefines and new defines, but also all other needed defines, among which the define of a longer ligature table, which can also be inserted just before the table. I will say with all that, that the developer must look by himself. He is given a number of hints and advice in the comments, but that's roughly all. And unfortunately it isn't complete. At least not about keyboard drivers.

>
>
> > For not wanting to make anybody loose face, I didnʼt mention that a
> > copy of the cited and quoted header file is included in the MSKLC.
>
> Yep, I could have saved a lot of time if I'd noticed that.

Sorry.

>
> > The version 1.4 of which dates from Thu, Jan 25, 2007, ‏23:14:22,
> > whereas the included kbd.h shows «10-Jan-1991 GregoryW» in the file
> > history.
>
> My copy says:
>
> @@BEGIN_DDKSPLIT
> * 10-Jan-1991 GregoryW
> * 23-Apr-1991 IanJa VSC_TO_VK _* macros from oemtab.c
> @@END_DDKSPLIT

That's what my copy says too, but I focussed on the author of the biggest part, as Mr Ian Ja only added the macros from oemtab.c. And on the date, which [MSKLC]\inc\kbd.h is the only file to provide, the History in [WDK]\inc\kbd.h being empty.

>
> Looks like things have been pretty stable since 1991.
>
> > Therefore, my supposition (I hadnʼt looked up that!) 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.)» turns out to be completely wrong (except the
> > parenthesized disclaimer). I could become more explicit, but I just
> > stand away in order not to heat up the discussion with ad personam
> > conclusions.
>
> Good idea.

Objectively, we must induce that there was a briefing to limit ligature support to four characters despite of Windows being built to support far more, and so on. You know, when people invoke the hell when making assertions, I'm quite doubtful.

>
> What led you to the conclusion that this limit had been increased,
> anyway? ("On my machine the maximal length is 16 characters.") I'm still
> curious about that.

The limit being increased, was not a conclusion of mine, it was an advice I got on a web page somewhere^^
There's been a conclusion of mine, the history of which we can read up in one of my previous replies. In the archive it's all wrecked: http://www.unicode.org/mail-arch/unicode-ml/y2015-m08/0024.html
I must resend it. In the meantime, it may be quoted:

>>> 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).

>
> > I often wondered why the description page
> > [https://msdn.microsoft.com/fr-fr/goglobal/bb964665.aspx] and even
> > less the download page
> > [https://www.microsoft.com/en-us/download/details.aspx?id=22339] have
> > not been updated (no mention of Windows 8 on the former, no mention
> > even of Windows 7 in the system requirements on the download page),
> > and why thereʼs no 2.0 version of the MSKLC.
>
> Microsoft simply hasn't dedicated any resources (Michael or anyone else)
> to updating MSKLC. Michael has blogged about this many, many times in
> the past few years. Big companies make the decisions that they make, for
> the reasons they have.

I'm sorry, I didn't read Michael's blog posts about not updating the MSKLC. He must be angry. It's a pity for everybody. But I understand also the point of view of the company it depends on. To invest in free software that allows users to get more independent of charmaps and autocorrect and IMEs, may be somewhat outside the business model.

But the main reason may be that the need is already catered for, notably by Tavultesoft Keyman.

However, if the 2.0 MSKLC would have sticked with four-character ligatures........

>
> > Iʼm not here to criticize Microsoft. I ask everybody to be honest and
> > to answer for himself one single question: How on earth can I prefer
> > Bing if I were battling against Microsoft? Does anybody really believe
> > that Iʼm annoying myself to find more bugs?
>
> I apologize for my tone in this thread. See my explanation above of when
> "bug" is an appropriate conclusion to draw, and when it isn't. That got
> me started.

It's all right. I apologize again on my behalf.

>
> > Hopeful that this will end in a constructive way,
>
> Agreed.

Best regards,

Marcel
Received on Sat Aug 08 2015 - 05:58:20 CDT