How ConvertDefaultLocale sorta broke backward compatibility in Vista, and why

The whole situation reminded me of some dialog from a West Wing episode, the one where some politico was complaining to President Josiah Bartlett about women wanting equal opportunities in athletics. When Jed pointed out that Title IX was passed thirty years ago, the politico responded "Yes, Mr. President. But now it looks like they want those laws enforced."

It's a world gone mad, I say.

Anyway, enforcing consistency can be quite painful at times. Especially trying to be consistent with something that never worked right anyway.

It all started with the issue I first mentioned in Change is in the cards for ConvertDefaultLocale... though its roots go way back to What is a neutral culture? What is a neutral locale? and some odd decisions made for the LCID values in the .NET Framework, specifically the one that caused the Traditional Chinese neutral culture's LCID to be 0x7c04 and the Simplified Chinese neutral culture's LCID to be 0x0004.

Now over in Windows, LCID 0x0004 is actually LANG_CHINESE and is the neutral for all of the Chinese LCIDs, both joint and severally. But that is a lame answer, based on the fact that NLS never cared about neutrals and never supported them anyway. But the .NET Framework needed (or at least wanted) unique values for Traditional and Simplified Chinese, and only one of them could be 0x0004. The decision was made to make that the Simplified Chinese LCID, and then a new one was added for Traditional.

Arbitrary, but since all of the Windows locales used 0x0004 as their neutral, it does not matter, right?

Well, no.

Because any time you passed LANG_CHINESE to an NLS function that took an LCID, it would assume you meant MAKELANGID(LANG_CHINESE, SUBLANG_DEFAULT) which also happens to return the same results as MAKELANGID(LANG_CHINESE, SUBLANG_CHINESE_TRADITIONAL), which has a comment in winnt.h and ntdef.h of "// Chinese (Taiwan)". And then the longstanding constant for PRC was SUBLANG_CHINESE_SIMPLIFIED with a comment of "// Chinese (PR China)".

So even though the neutral made no warranty and no decision as to its meaning, using the neutral in an NLS function called itself Traditional Chinese and there was no neutral that would do the same for Simplified Chinese. Which makes the decision for how to allocate LCIDs in .NET (which supposedly only existed for backcompat with Windows) in retrospect a less than stellar choice.

So, swinging back around to Windows and Vista, there are now three versions of the .NET Framework that have shipped and which actually support the notion of neutrals. And even if it was the wrong decision, the decision is out there now, and changing the values to be compatible with a platform that does not support the concept of neutral locales anyway would also be a bad decision, and a definite case of two wrongs not making a right.

So in the Vista version of ConvertDefaultLocale, 0x7c04 is converted to 0x0404 and 0x0004 is converted to 0x0804, so ConvertDefaultLocale now behaves just like the unmanaged equivalent of the managed CreateSpecificCulture.

For some, this might be a case of two wrongs making a "well, I guess it's a little better than nothing". And at least the to platforms are moving towards consistency.

Though if you are one of the many people who use to rely on LANG_CHINESE returning the same results in NLS functions as 0x0404, you will probably not even agree with that, and it is probably just better to call it a mess and leave it where it is....

Though to be honest, if you ever relied on the old behavior of 0x0004 in Windows then you were probably doomed anyway, given that from a resource standpoint that means you were wrong at least 40% of the time already. In the end it probably is better to support the crowd of people who use something correctly 100% of the time than to support the people whio use something incorrectly that only partially worked 60% of the time. :-)

This post brought to you by ꄬ (U+a12c, a.k.a. YI SYLLABLE TOP)