A resource segue, #2 (architecting the wheels off the wagon, a bit)

by Michael S. Kaplan, published on 2011/03/11 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/03/11/10139662.aspx

Yesterday in A resource segue, #1, I talked about the "stealth" nature of MUI from the point of view of callers.

This time I'm going to explore more than just the view from Visual Studio of the resources....

Let's look at some of the consequences of the design....

One of the interesting resources that ends up in the 'split off' *.MUI if the version resource.

So here is the Shell view of NOTEPAD.EXE's resources, under English and the two Norwegians:


Of course the different translations of the property names are not interesting for our purposes -- they come from Windows itself, not from the resource file.

But the strings themselves, like the copyright string and the product name?

Those come from the localizer, making changes (or not) for that particular file.

To prove this to yourself, simple copy one of these files from the WINDOWS directory to the desktop and look at the file again -- it will lose its "localization" characteristics and look like the English file again.

The general principle would I suppose be that MUI causes Explorer to tell targeted almost truths asbout the identity of a file, whose oublic face might be subsumed by the underlying resource DLL. You can code around it if you want to, but the original developer is in cahoots with thisds idea, more often than not.

Fascinating little tap dance, huh? :-)

Though of course this leads to a fascinating consequence, one that seriously impacts every single localizable file in Windows.

Can you spot it?

You see, in a service pack, lots of files are updated.

And in order for customers, or product support, or whoever to see if a file is updated, they have to be able to check the version number.

And that means service packs have to update both files, even if you did not change any of the resources -- or else the default view in Explorer will appear to be lying about the majority of files in a service pack.

Again, if you don't believe this, feel free to copy .MUI files out of the language specific directories, rename them to look at them in Explorer or follow the more complicated VS-based instructions from Cracking the binary (aka How to open .MUI files?). You'll see they appear to have updated a lot more files than they made actual substantive changes in.

This is a huge price to pay though, just to be able to translate a few strings.

Perhaps too huge?

Personally I'd go in and make changes to the way the Shell shows the version number -- perhaps to show both versions, maybe? I think that would probably be cheaper, all things considered.

Now note that this is really a Microsoft-specific problem; the problem everyone else has is the fact that the dates do not appear to update when the binary is updated but they appropriately avoided resource changes in the update. The bug that Microsoft apparently avoids with the extra file updates....

And there's more. Well, a little more at least.

I'll talk about the rest tomorrow, in #3 of this short series....

carlos on 11 Mar 2011 9:54 AM:

According to the GetFileVersionInfo docs, the VS_FIXEDFILEINFO comes from the main binary and is merged with the strings from any MUI files.  If the Shell displayed the version from VS_FIXEDFILEINFO and version strings were deprecated there would never be any confusion nor need to update the MUI files.  If the version string contains essential information missing form the version number, you're doing it wrong.

Michael S. Kaplan on 11 Mar 2011 10:34 AM:

But tracking the two things (updated resources, updated core binary) separately would be useful for a whole host of reasons. And you can verify that both were updated by viewing them when they are moved and thus not able to be "combined" (I don't trust the "combined" view for thayt very reason)....

carlos on 11 Mar 2011 11:44 AM:

You're right, that would be useful.

The Windows XP version property page displays the binary version at the top and the string version in the list of string properties.  Unfortunately, XP doesn't handle the mui merging for version info so this never shows the mui version.

The Windows 7 property page only displays the string mui version.

If you could run the Windows XP file properties dialog on Windows 7 we'd both be happy.

referenced by

2011/03/12 A resource segue, #3 (how'd they manage to screw this one up?)

go to newer or older post, or back to index or month or day