by Michael S. Kaplan, published on 2009/09/02 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2009/09/02/9890204.aspx
Over in the Suggestion Box, Aaron asked:
Michael,
We noticed a problematic breaking change between Windows 7 and previous OS's around ConvertDefaultLocale and the Spanish LCIDs
LCID lcid1 = ConvertDefaultLocale(PRIMARYLANGID(1034));
LCID lcid2 = ConvertDefaultLocale(PRIMARYLANGID(3082));
On XP and Vista, these both return 1034 as the value. On Windows 7, this returns 3082.
Same happens if we wrap this call with a MAKELCID/SUBLANG_NEUTRAL call:
LCID lcid3 = ConvertDefaultLocale(MAKELCID(PRIMARYLANGID(3082), SUBLANG_NEUTRAL));
LCID lcid4 = ConvertDefaultLocale(MAKELCID(PRIMARYLANGID(1034), SUBLANG_NEUTRAL));
This obviously causes bugs when using this function as part of best-guess resource lookups based off of GetUserDefaultLangID() results.
Do you have any insight into why this changed, and more importantly, what other lcid's have changed?
Thanks,
Aaron
Interesting!
Now I have talked about ConvertDefaultLocale in the past.
Like way back in 2005 (in Change is in the cards for ConvertDefaultLocale....) when I pointed out that ConvertDefaultLocale would likely be changed to fix the inconsistency between native NLS and managed globalization classes methods of fallback.
On in 2006 when I mentioned it again (in What the hell is wrong with TranslateCharsetInfo, anyway?).
Then the kicker came a few months later in that same year when I wrote How ConvertDefaultLocale sorta broke backward compatibility in Vista, and why. In it I chronicled some though not all of the minor tweaks that ConvertDefaultLocale was using to try to make the two platforms behave more consistently.
This is not Aaron's issue, which is about a different change -- one apparently made in Windows 7.
It looks like they did the work to take on the issue I mentioned we almost fixed in Vista (in The modern solution to the problem of Traditional Spanish in Vista) but then backed out the fix due to backward compatibility problems (in They say it happens to everyone, at some point...).
And in that fix it appears they may have broken some assumptions that a developer might have made related to treating 0x040a and 0x0c0a as two different locales rather than as one locale with one alternate sort version of that locale.
Strictly speaking, the Windows 7 behavior is more correct.
However, the attempt to fix the similar bug in Vista was more correct, too (for all the good it did me and the others working on it!).
I've often suspected that the NLS team would "benefit " from having people like Julie and Cathy and me move on to other work since we wouldn't be around to make hairy nuisances of ourselves over the backcompat issues, and this appears to be another good example.
The behavior is actually better and more sensible from someone paying attention to meaning and context in figuring out behavior, but only time will tell if the ways in which this breaks other usages (like Aaron's) will be serious enough to inspire further tweaking....
Mihai on 3 Sep 2009 11:42 AM:
From a completely different direction: using GetUserDefaultLangID (used for formatting number, dates/times, sorting, etc.) is the bad one to use for "resource lookups"