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....

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.

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.

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

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.

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....

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.

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)....

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.

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.