by Michael S. Kaplan, published on 2007/04/29 17:59 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/04/29/2330455.aspx
You may have seen part 1 and part 2 of this series. Here we are with part 3!
Pavel S. Tsarevskiy asked last month over in the microsoft.public.win32.prograsmmer.international newsgroup:
I have a problem with using LoadMUILibrary() function and MUI technology under Windows XP.
I tried to use Vista MUI technology which is supposed to work under previous version of Microsoft OS.
I want to solve the problems with localization my application.
I want to make one project which contain neutral resources for example icons, bitmaps, etc. And projects which contain language specified resources for each language. So, The main benefit, we can use LoadMUILibrary which make HMODULE which contain handle to both neutral and language specified resources. Then we change default resource handle using AfxSetResourcesHandle(). There're no resources in exe module. And therefore it's not necessary to indicate HMODULE for some load resource functions which load neutral resources. Otherwise, it's not necessary to duplicate all neutral resources in each language dll library. So, for all load functions resource handles would be clear.
But, when I did test version of my application I saw that It's working under Windows Vista, but under Windows XP, HModule didn't indicate neutral resources, so it's impossible to load both neutral and language specified resources using one HModule under WinXP.
Does anybody know about it?
Microsoft says that this technology is working under XP.
Pavel is correct here-- the LoadMUILibrary documentation does imply that it will properly redirect a needed to pick up resources in either the language neutral or appropriate language specific directory.
Unfortunately, in downlevel situations, it does not provide an HINSTANCE that will magically find the resource when it is used in other, later resource function calls. In the words of MUI tester Mike McAdams:
I agree with the person's post. You can not expect to get at both the LN and LD using LoadMUILibrary on down-level (meaning pre-Vista). You can however get at resources in both binaries using that API on Vista. ...this is because of the resource redirection being done by the RL [Resource Loader].
This particular "by design" is one that I consider to be rather unfortunate -- there is very little point (in my opinion) to doing all the work to provide a function downlevel that nevertheless behaves differently between the >= Vista and the downlevel case.
The goal here was clearly to make sure that no special case code is needed, but if you want to use LoadMUILibrary downlevel, you end up having to use it differently....
Given that, there is very little point to including the function downlevel!
In my opinion, they should have found a way in the downlevel case and done the extra work here to make sure that DLLs loaded via LoadMUILibrary can behave the same way they do in Vista. Like by hooking the low level Resource Loader functions and redirecting as needed.
Of course, only a team that owns the resource loader would really have a fair chance to accomplish such a thing, but as luck would have it, the MUI team owns the Resource Loader. :-)
I think they should try to address this -- in an effort to make the suggested "best practices" more accessible to developers.
It would be a much better model for supporting the pleanned feature, in any case!
This post brought to you by ଊ (U+0b0a, a.k.a. ORIYA LETTER UU)
# KJK::Hyperion on 30 Apr 2007 11:42 AM:
Ha! The funny thing is, the downlevel loader *does* have MUI hooks (see: LdrLoadAlternateResourceModule) - you know, to support the older "flavor" of MUI; don't know if it could support this scenario, though.
Or they could just have hooked one, maybe two functions, that are only accessed through DLL exports, hence fairly trivial to hook
[runtime hooking is a non-trivial issue in general, and you end up depending on either a statically linked library like Detours, or system facilities like Shim Layer that aren't as downlevel as some would like (Windows 2000 SP2 and later, I think?); there's also the issue of hooking "early enough" - Shim Layer has the luxury of doing its thing inside the loader's startup sequence - and hairy multithreading issues you *don't* want to hear about]
Ted. on 5 Jan 2011 12:05 PM:
The one thing I discovered about the "old way" on XP is that it only gets triggered if your UI language is different from your main (system OS) language. So the old way assumes your main language resources are stored in your main (non .mui) DLL. Another thing that's annoying is that XP only has support for application MUI if MUI is actually installed (a completely separate installer from MSDN that is 5 CDs). For non-MUI XP, it doesn't even take into account your MUI files even if you have them in the right location (e.g. .\mui\040c\mydll.dll.mui)
So the old way is basically a non-starter for 3rd party apps, that coupled with no way to set the thread's preferred UI language, kills this approach dead on XP. So MUI is basically useless for those wanting to still support XP since you have to write all your own resource loading whereas on Vista+ it just works magically.