There's an unfortunate Windows Vista bug that causes keyboards to fail in ANSI applications.  Its amusing in a sad sort of way since this bug missed about a dozen checks we have to make sure this kind of thing doesn't happen.

Anyway, keyboards attached to the following locales might have this problem for some or most characters.  (I made this list with a quick script and didn't test all characters/languages, so this might not be completely accurate)

  • Romanian (Romania)
  • Ukrainian (Ukraine)
  • Serbian (Latin, Bosnia and Herzegovina)
  • Urdu (Islamic Republic of Pakistan)
  • Belarusian (Belarus)
  • Persian
  • Azeri (Latin, Azerbaijan)
  • Uzbek (Latin, Uzbekistan)
  • Welsh (United Kingdom)
  • Turkmen (Turkmenistan)
  • Irish (Ireland)
  • Uighur (PRC)
  • Upper Sorbian (Germany)
  • Hausa (Latin, Nigeria)
  • Yoruba (Nigeria)
  • Dari (Afghanistan)
  • Lower Sorbian (Germany) (no locale specific keyboards by default)
  • K'iche (Guatemala) (no locale specific keyboards by default)
  • Wolof (Senegal) (no locale specific keyboards by default)
  • Igbo (Nigeria) (no locale specific keyboards by default)
  • Chinese (Traditional, Hong Kong S.A.R.) (the IME doesn't use rely on the bug so this shouldn't be a "real" problem)

Additionally these locales are "Unicode Only" and shouldn't work with ANSI applications, however this bug could cause code pages to be used with keyboards that give the appearance of working, but could have bad mappings:

  • Kazakh (Kazakhstan)
  • Maori (New Zealand)
  • Pashto (Afghanistan)
  • Maltese (Malta) (no locale specific keyboards by default)

The bug is a broken LOCALESIGNATURE data for these locales.  (Exposed as LOCALE_FONTSIGNATURE by GetLocaleInfoEx, although Michael points out the name's confusing in "It isn't a FONTSIGNATURE, darn it!") 

The IsCsbDefault and IsCsbSupported fields of LOCALESIGNATURE have misleading information in Vista, and the ANSI keyboard code use IsCsbDefault to figure out the ANSI code page to use when mapping characters.  Presumably LOCALE_IDEFAULTANSICODEPAGE would've been a better choice here, but that wasn't used.  In general we'd recommend not using the LOCALESIGNATURE or FONTSIGNATURE values since they have historically been fairly inaccurate and change a lot between versions.

We're working on a fix for this bug, and I'll try to post a pointer when it gets posted, but it'll take a while.

As a workaround we're lucky that we introduced the Custom Locale feature in Vista.  You can use the CultureAndRegionInfoBuilder .Net class to create a custom culture with a corrected font signature.  For locales that shipped in XP you can just get the value from XP, or you could use the value from another culture that has the same LOACLE_IDEFAULTANSICODEPAGE as the target locale.  Once corrected, the custom locale will cause this data to be loaded correctly and your keyboard should work in ANSI applications.  Note that the custom locale will override any locales we may ship in the future, so you'll need to make sure to uninstall your custom locale after applying any patch.

Interestingly enough this bug was reported in an application that touted itself as being a Unicode application.  We've discovered that several "unicode" applications aren't thoroughly Unicode, and rely on ANSI input (otherwise they wouldn't hit this bug).

Hope this information is useful.