Why MUIRCT is so cool (aka separating Win32 resources into satellite DLLs, the easy way)

MUIRCT is a utility that Microsoft made available starting with the Windows Vista SDK.  It’s a localization utility that allows you to “split” resources from a DLL that has already been built.

Let’s give an example.  You have a large legacy app with dozens of DLLs, all using the model of code+resources in the same module.  After all, up to this point there has been really no good techniques within Visual Studio itself to use the satellite DLL approach, without doing a lot of manual work.  Things like creating dialog boxes, etc are simply easier to do with the built in wizards (class wizards, event handlers, etc) if the code and the resources reside in the same EXE/DLL.  Unfortunately this is the exact opposite of what we need from a translation/localization perspective.    The satellite DLL approach allows you to keep your code and your resources separate, but it involves a lot of manual work, especially if you have a complex app with many EXEs and DLLs.

What if there was a way to continue with the old style code+resources in the same module approach during development, but then separate out the resources after the fact, and require only minor changes to your code?  How is that possible?  When you load a resource from a handle (e.g. let’s say your app is test.exe, and you pass in the HINSTANCE of test to LoadString, how does the operating system know to look elsewhere for the resources?  A single handle can’t represent two separate modules behind the scenes can it?

Turns out, in Vista and higher, MUIRCT can separate these resources for you, and the operating system will load them automatically when you do a resource load.  And you have control at the individual resource level as to what is treated as language neutral (what stays in test.exe) and what is localizable (what goes into the satellite DLL)

Example:

Create a new MFC app, test.exe using all the defaults

Compile the app, then run the following on the output:

muirct -q test.rcconfig test.exe test2.exe test2.exe.mui

The above commmand splits up the app test.exe into two components, a language neutral part (the EXE) and a DLL named test.exe.mui which contains the localized parts. Now translating this test.exe.mui using a resource editor, your code is separate from your resources.

Then you would store for example your app in two folders:

test2.exe en-us\test2.exe.mui

When you run your app, the operating system knows to look for your resources in en-us folder (or what ever your ultimate fallback language is selected to be)

So if you have a bug fix to test.exe, you don’t need to redo all the languages because the resources and the code are separate.

I’ve only just scratched the surface on this topic, there are many more technical details you’ll need to learn, fortunately this whole process (including a full example of an rcconfig file) is provided by Microsoft in a walkthrough and sample code here:

http://archive.msdn.microsoft.com/hellomui

and

http://archive.msdn.microsoft.com/MUIIzer

Note: this approach works in Vista and higher.  if you need XP support, you’ll need much more extensive changes to your application as there is no support for this technique at the OS level, so you end up writing a lot of extra code, which makes the whole thing pointless.  So I would recommend only using this if you are able to drop XP support from your list of supported operating systems.