by Michael S. Kaplan, published on 2006/05/05 04:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/05/05/590504.aspx
I have talked about the notion of the language SKU specific nature of both MS Shell Dlg and of DEFAULT_GUI_FONT, but technically I was at least partially speaking of a bygone era.
Back in the before time, in the long long ago, GDI would load its resources based on information in the registry that would never change. The information in the registry was different in several of the various language SKUs of Windows. And it never changed.
At the same time, some of the other functionality (such as GDI font linking) was based on the default system locale, a bizarre setup that no one really can explain other to say that they couldn't think of anything else to base it on, and it would help some of those legacy Win9x applications with specific code page assumptions and matching font assumptions....
Then in Windows 2000, when the Windows Multilingual User Interface (MUI) was first put out there, the notion of the UI language of the system account (which happened to match the SKU language since it could never be changed) was added, and at some point the GDI code starting using this setting during its session initialization routines. No one quite new when/why this was done, though it was suggested that convenience was the main driving factor. :-)
Of course one of the interesting features that was added in was the notion of applying Regional and Language Options choices to the "Default User Account Settings"....
I have talked before about just one of the interesting featurelets that this exposed (changing the keyboard in the logon dialog). One of the other intersting features it helped out with was applying settings such as the UI language to all of the following places:
Now that last setting had an interesting consequence on our GDI story, since changing the UI language and clicking that checkbox on the advanced tab would change many of the actual places that the code was using to get the language SKU settings -- in essence, changing many facets that were used to determine what the original install language was.
Luckily it never occurred to them to call the GetSystemDefaultUILanguage function, whose value does not change when this new notion of the "UI language of the LocalSystem account (which almost never shows UI)" does. Because if they had, then we wouldn't have this whole budding area of bizarre functionality!
I suppose this new setting needs some kind of shorter name (since saying that whole phrase over and over again would really wear me down). Maybe the .DEFAULT UI Language (pronounced dot-default-yoo-eye-language). What do you think?
Is inventing new terminology like this a linguistic issue? Or am I stretching?
In fact, there is no function to get this [somewhat interesting, though rather obscure] setting, currently. I will talk more about this setting, what it does, and what it causes to happen, in future posts.... :-)
This post brought to you by "ꃆ" (U+a0c6, a.k.a. YI SYLLABLE MUP)
# John on 22 May 2006 5:33 AM:
# Aidan Corey on 30 Jun 2006 7:47 AM:
# Michael S. Kaplan on 30 Jun 2006 9:15 AM:
2012/01/31 Sometimes things are extended in the wrong direction....
2010/08/01 It's not a localization bug; it's a core bug in the way they do their globalization and resource loading
2008/11/13 On reverting unexplained spontaneous alteration of language
2008/08/05 On describing poorly (and on not listening)
2007/10/25 Is it a Unicode issue? A non-Unicode issue? What the hell is it? (aka Beware former [Font ]Associations)
2007/09/21 If you had gotten there first, you might have staked your claim too!
2007/06/16 You don't have to trust Microsoft's choices about fonts
2006/11/29 Where'd *that* language come from?
2006/06/12 More problems with the Shell's 'ultimate font' solutions
go to newer or older post, or back to index or month or day