by Michael S. Kaplan, published on 2006/11/08 04:23 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/11/08/1032747.aspx
Now we saw the other day in MFC + Spanish version of Windows = Oops! one of the costs of MFC's localized DLL model that depends on the GetLocaleInfo LOCALE_SABBREVLANGNAME for the name of the satellite DLL to use, a problem that adds a very interesting dependency on LOCALE_SABBREVLANGNAME that means we could probably not ever change one of those values, even to fix a bug that someone really wanted us to (such as some might prefer, as I pointed out in LOCALE_SABBREVLANGNAME is more than just an ISO-639 code).
The other day someone stumbled on another example of a problem in the model....
The question from Jason went something like this:
When my customer is loading their MFC application, they notice that it looks for MFCENU.DLL. Is this a resource DLL for English resources? Is there any documentation on this DLL?
They are using Visual Studio .NET 2003. Their customer is using an English (Canada) locale. What they noticed was that MFCENU.DLL was attempted to be loaded every time their process started. When it was not found, the application worked fine anyway. The problem was that they had slow UNC paths in their PATH environment variable. The customer is asking what MFCENU.DLL is and what the effect of having it (or not having it) is going to have on the application. Our guess is that it is some type of resource DLL for localization and that if it is not present, you default to English (US)?
I’m just looking for confirmation on this what the DLL is and why MFC looks for it every time the application runs. Thanks!
Fellow Technical Lead Dave Bartolomeo had the answer here:
You’ve guessed correctly. IIRC, MFC creates a list of languages to search for based on the current UI language. In your case, it probably looks for Canadian English (MFCENC.dll), followed by US English (MFCENU.dll), and if neither of those works, it settles for whatever is built into the MFC DLL itself (which is US English). Since MFC isn’t localized into Canadian English, there is no MFCENC.dll, and since the US English resources are already baked into the MFC DLL itself, MFC doesn’t ship an MFCENU. So, the fact that MFCENU.dll is missing is expected, and shouldn’t impact the behavior of the application (other than the cost of looking for it and not finding it).
Now of course there is the problem Jason's customer was hitting with the network path being polled for a DLL that is never expected to be there, but beyond that I think it probably a bad thing that MFC decided to agree with me in its heart of hearts with my Random irreverent thoughts about the Ultimate Fallback, yet did not bother to build in the smarts to make it easy to avoid looking for DLLs that are not expected. And I mean a way that does not involve compiling one's own copy of MFC to do the work, of course. :-)
(By the way, the MUI development manager disagrees with my ultimate fallback opinions due to the serviceability problems it can cause, though given all of the effort that MUI goes to in order to avoid perf. issues with random path polling by not using the path to find resource DLLs, he might agree with me that the MFC model may not be doing the best thing there!)
I'll see if I can talk soon about the efforts we went to in custom cultures to avoid the same type of problem, and maybe even talk more about the solutions that MUI developed for the resource loader in Vista....
This post brought to you by ໜ (U+0edc, a.k.a. LAO HO NO)