by Michael S. Kaplan, published on 2010/04/29 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/04/29/10003565.aspx
I fully admit that once upon a time, MUI would make me bipolar.
But thankfully, that all ended in Windows 7. With two specific changes.
The first change is the obvious one: the bug I mentioned in that blog that existed for Vista and Server 2008 for SetThreadPreferredUILanguages? They fixed it so that in Windows 7 and Server 2008 R2, you can set a custom locale to be the thread preferred UI language!
Now that was a bug fix. While very cool, there is something cooler.
It has to do with the model here
MUI was something that would work as the UI language for an entire session or per thread. And nothing in between.
This is great if you were following the UI language being used by Windows (what the session level setting would have) or if you had one application where you had a limited number of threads and could set this information for each one that might be loading resources.
Obviously there is a whole sheaf of scenarios for ISVs and occasionally even IHVs where having only these two levels of support was simply terrible.
You can probably think of many of these on your own, like applications using thread pools for a big one.
Now this architectural limitation bleeds over into managed code as well (by the way), where the CurrentUICulture is a per-thread setting.
How many languages can you say that sucks in? :-(
But in Windows 7 and Server 2008 R2, a new function was added: SetProcessPreferredUILanguages!
It works the same way as its thread-based cousin, but all newly created threads from this process will pick up this default! In fact, if you change the function names in that sample and remove the MUI_THREAD_LANGUAGES constant from the call (obviously that flag makes no sense when getting the process UI languages!), it works as is.
Simply amazing!
There are perhaps a few places in the docs that call this a Vista feature -- it was not. New in Windows 7!
Now .Net of course could choose in the future to pick this up, and use it -- perhaps even extend it to the AppDomain level if that makes sense, but if not make it work in all of the applications that currently have less-than-ideal behavior for their thread-level dependencies.
So now I can set the UI language at the appropriate place -- the PROCESS level; and I can set it to any locale that is available on the system -- including one I might have just made myself!
I really do feel that this "therapy" that Erik Fortune and the whole MUI team provided for me in Windows 7 and Windows Server 2008 R2 have mostly nursed me back to health of all of the problems inspired by previous versions.
By the way, I verified that .Net never picks up the process default, either in an initial thread for a process if set right away or in any later thread you create within that process (I did not check what happens with processes created from a process after calling the function, so there may be a workaround to make it work?
This behavior in .Net seems like something they are over-optimizing ("since the UI language couldn't ever change even though it could before in native contexts and now can in a very feature-driven way that .Net really ought to pick up. Note to Josh!!!!
As soon as .Net can pick up this work too, I will officially be cured.... :-)
referenced by