The role of documentation in implementation (was: Re: Windows keyboard limitations)

On 08 Aug 2015, at 15:01, Richard Wordingham wrote:

> On Sat, 8 Aug 2015 14:05:17 +0200 (CEST)
> Marcel Schneider wrote:
>
> > 2. Supposed that Windows supported more than four characters per
> > ligature:
>
> > 2.1. Why has the MSKLC been limited to four characters per
> > ligature?
>
> Because that was believed to be the architectural limit. Note however,
> that it isn't 4 *characters* that is the limit, but 4 UTF-16 code units.

Richard (be it allowed to use first name to conform to the usage) turned out to be the only person to answer one of my listed questions. Thanks again and my apologies for the tone of my reply, which finally has been influenced by the tone of the blog post, when I were talking about his author—but this too Iʼm sorry about and ask Michael to forgive me as we forgive his value lowering.**

Remembering that I presumed that the limit was really four in old Windows versions and that it has been changed, I can now go a step further admitting that the fundamental limit has always been sixteen since ligatures were implemented, and that lowering it to four in one single application was triggered by a cluster of circumstances that produced a belief.

To assess the effects of a lack of documentation, we may cross-reference the situation with two quotations from the same header file [MSKLC]\inc\kbd.h, lines 731 sqq and 751 sqq:

// There is no documented way to detect the manufacturer of the computer that
// is currently running an application. However, a Windows-based application
// can detect the type of OEM Windows by using the return value of the
// GetKeyboardType() function.

// Application programs can use these OEM IDs to distinguish the type of OEM
// Windows. Note, however, that this method is not documented, so Microsoft
// may not support it in the future version of Windows.

May we conclude that whenever documentation is missing, we are allowed to rely on test results and other observations?

About ligatures support, Andrew Glass and previously Michael Kaplan assure that there will be no major change. Given that on Windows 7, sixteen code units are supported on all** current (tested) shift states, this allows to conclude that stability must not necessarily rely on documentation (unlike it is suggested in the second quotation above).

Thanks to the parent thread, I take notice however that when documentation is missing, unusual behavior of software must not be referred to as bug.

If this thread, which spins off from a closed thread, is not followed up, we may take these statements for granted and build development policies upon.

Best regards,

Marcel

** Note: More than four code units per ligature works now on *all* tested shift states.
The reason why the unexpected behavior is now eliminated, seems to be (in my belief) that VK_OEM_PA1 has been replaced with VK_OEM_AX. To map KBDKANA (the Kana modifier key) to Left Alt, I had redefined scan code T38 as VK_OEM_PA1, found in kbd.h. Now on Sun Aug 09, 2015, 23:16 (yesterday in the evening) I found in “WINUSER.H” (named in capitals) that VK_OEM_AX is far more obvious, as its default scan code stands between two that are actually used on the default French keyboard and are mapped to VK_OEM_8 and VK_OEM_102.
I believe that the presence of the less usual VK_OEM_PA1 (part of «Nokia/Ericsson definitions») made Windows more sensitive.

Iʼm happy that this issue is so appeasingly and gratifyingly resolved. I present my apologies for the trouble it has made, as well as my thanks for the many pieces of information it has brought up.

Marcel
Received on Mon Aug 10 2015 - 06:09:56 CDT