What happens when people don't consistently preserve case? They cause bugs!

by Michael S. Kaplan, published on 2007/10/02 10:31 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/10/02/5236576.aspx

It is all well and good for me to spin theoretical advice about important issues related to internationalization and the various best practices thereof, sure.

And there are a bunch of you who seem to find it entertaining to have me blather on this way.

But having real examples seems to work better, I think. :-)

Take for example the lessons in In any CASE, it is somewhat INSENSITIVE to point out to someone how well PRESERVED they are and If you don't always preserve case, you don't always preserve meaning.

The other day, Jeffrey asked:

I am trying to use BeginUpdateResource API to bind a ReadMe.txt as resource into a Exe. But after performing the task, I find I can not use VS IDE to examine the resource of the Exe. So I assume my code corrupted the Exe. Am I doing anything wrong in the code below?

(I did not include the code he did since it was not relevant to the actual problem.)

Ace developer Jay Krell tracked down the problem after a few iterations via email:

I guessed and..

The problem is that kernel32!EnumResourceTypesW => kernel32!BaseDllMapResourceIdW  uppercases all input strings, and ntdll!LdrpCompareResourceNames_U is case sensitive with that and whatever is in the file, and UpdateResource ferries along whatever case you give it.

Therefore UpdateResource with mixed or lowercase strings leads to failure to enumerate the results, and perhaps failure to load, but I didn't try that.

So the file really isn't corrupt, at least not significantly so, just mixed up in case.

Stick to all uppercase and you'll have better luck.

Aha..poking around the docs, the "community content", says basically the same thing:

And indeed, the added community content in the FindResource function added by Matt Green says it all:

Having trouble loading resources by name?

Unfortunately, the official documentation does not mention that loading a resource by name does not work unless you specify the name in all capital letters. The resource itself must be named with all capital letters, and the argument to FindResource[Ex] must be in all capital letters. Otherwise, FindResource[Ex] will return NULL with error code 1814.

If only there were not functions that were randomly capitalizing everything except for the functions that people might use to look up resources later -- if they had just left the case alone and used RtlEqualUnicodeString or RtlCompareUnicodeString or CompareStringOrdinal allowing case insensitivity if you like, and everything will work well here.

So please preserve the case and avoid problems like this in your own code. It may not affect as many people but no one should ever have to deal with bugs like this....

This post brought to you by (U+17d6, a.k.a. KHMER SIGN CAMNUC PII KUUH)

no comments

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.

referenced by

2008/10/29 How the @#%&*! does CBS_SORT choose to sort it all out?

2007/10/24 Getting the preserved case of a file wHeN tHe uSeRs tYpE wHaTeVeR tHe hElL tHeY wAnT tO

2007/10/24 In Case you have problems that you might think are ǸȦȘȚȲ

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