{"id":111129,"date":"2025-04-30T07:00:00","date_gmt":"2025-04-30T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=111129"},"modified":"2025-04-30T12:18:50","modified_gmt":"2025-04-30T19:18:50","slug":"20250430-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250430-00\/?p=111129","title":{"rendered":"Why does Windows have trouble finding my Win32 resource if it contains an accented character?"},"content":{"rendered":"

Maurice Kayser reported an issue with Win32 API loading of PE resources containing lowercase letters<\/a>. Maurice did some experiments adding resources named MyIcon<\/tt>, MyIc\u00d6n<\/tt>, and MyIc\u00f6n<\/tt>, then trying to load them using various names, and built up a table of results. I’ve broken it up into three tables depending on the nature of the accented character.<\/p>\n\n\n\n\n\n\n\n
Arg<\/th>\nCan load MyIcon<\/tt><\/th>\nCan load MyIc\u00d6n<\/tt><\/th>\nCan load MyIc\u00f6n<\/tt><\/th>\n<\/tr>\n
myicon<\/tt><\/td>\nYes<\/td>\nNo<\/td>\nNo<\/td>\n<\/tr>\n
MyIcon<\/tt><\/td>\nYes<\/td>\nNo<\/td>\nNo<\/td>\n<\/tr>\n
mYiCoN<\/tt><\/td>\nYes<\/td>\nNo<\/td>\nNo<\/td>\n<\/tr>\n
MYICON<\/tt><\/td>\nYes<\/td>\nNo<\/td>\nNo<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This table shouldn’t be surprising. The argument passed to LoadResource<\/code> is compared case-insensitively with the name of the resource, treating accented characters as different from their unaccented versions.<\/p>\n

Here’s the next batch.<\/p>\n\n\n\n\n\n\n\n
Arg<\/th>\nCan load MyIcon<\/tt><\/th>\nCan load MyIc\u00d6n<\/tt><\/th>\nCan load MyIc\u00f6n<\/tt><\/th>\n<\/tr>\n
myic\u00d6n<\/tt><\/td>\nNo<\/td>\nYes<\/td>\nNo (!)<\/td>\n<\/tr>\n
MyIc\u00d6n<\/tt><\/td>\nNo<\/td>\nYes<\/td>\nNo (!)<\/td>\n<\/tr>\n
mYiC\u00d6N<\/tt><\/td>\nNo<\/td>\nYes<\/td>\nNo (!)<\/td>\n<\/tr>\n
MYIC\u00d6N<\/tt><\/td>\nNo<\/td>\nYes<\/td>\nNo (!)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The first column is consistent with our previous result, namely that unaccented characters are treated as not the same as accented characters.<\/p>\n

The second column is not surprising either, since the strings do match according to a case-insensitive comparison.<\/p>\n

The third column is surprising. It seems that accented characters are case-sensitive, even though the documentation says that the comparison is case-insensitive.<\/p>\n

Okay, here’s the third block.<\/p>\n\n\n\n\n\n\n\n
Arg<\/th>\nCan load MyIcon<\/tt><\/th>\nCan load MyIc\u00d6n<\/tt><\/th>\nCan load MyIc\u00f6n<\/tt><\/th>\n<\/tr>\n
myic\u00f6n<\/tt><\/td>\nNo<\/td>\nYes (?)<\/td>\nNo (!)<\/td>\n<\/tr>\n
MyIc\u00f6n<\/tt><\/td>\nNo<\/td>\nYes (?)<\/td>\nNo (!)<\/td>\n<\/tr>\n
mYiC\u00f6N<\/tt><\/td>\nNo<\/td>\nYes (?)<\/td>\nNo (!)<\/td>\n<\/tr>\n
MYIC\u00f6N<\/tt><\/td>\nNo<\/td>\nYes (?)<\/td>\nNo (!)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The PE specification says that the resources are sorted “in ascending order”, and the names are sorted “by case-sensitive string.”\u00b9<\/p>\n

That’s all it says. The rest is left to interpretation.<\/p>\n

First of all, even though the file format specification says that the resource names can be in any case, the FindResource<\/code> function converts all names to uppercase before searching, so any names with lowercase characters are effectively unfindable. Fortunately, the Resource Compiler also converts names to uppercase before storing them in the resources, so it all cancels out, right?<\/p>\n

Well, it cancels out only if the Resource Compiler and the FindResource<\/code> function agree on how the names are converted to uppercase.<\/p>\n

The Resource Compiler uses _wcsupr<\/code> to convert the names to uppercase, and _wcsupr<\/code> uses the default C locale,\u00b2 which as we noted before, is not a very interesting locale<\/a>. It converts Latin unaccented lowercase letters a-z to Latin unaccented uppercase letters A-Z, and that’s all.<\/p>\n

Let’s update the top row of the table by converting the names to uppercase according to the C locale.<\/p>\n\n\n\n
Arg<\/th>\nCan load MYICON<\/tt><\/th>\nCan load MYIC\u00d6N<\/tt><\/th>\nCan load MYIC\u00f6N<\/tt><\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n

How does the FindResource<\/code> function convert strings to uppercase? It uses the uppercase table corresponding to the system default language. It is almost certain that \u00d6<\/tt> and \u00f6<\/tt> are uppercase and lowercase partners in the system default language. That means that the left columns are all effectively MYICON<\/tt> in the first table, and that they are all effectively MYIC\u00d6N<\/tt> in the second and third tables.<\/p>\n

With these adjustments, the tables make more sense.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Arg<\/th>\nLoaded
\nas<\/th>\n		Can load MyIcon<\/tt><\/th>\nCan load MyIc\u00d6n<\/tt><\/th>\nCan load MyIc\u00f6n<\/tt><\/th>\n<\/tr>\n
Stored as MYICON<\/tt><\/th>\nStored as MYIC\u00d6N<\/tt><\/th>\nStored as load MYIC\u00f6N<\/tt><\/th>\n<\/tr>\n
myicon<\/tt><\/td>\nMYICON<\/tt><\/td>\nYes<\/td>\nNo<\/td>\nNo<\/td>\n<\/tr>\n
MyIcon<\/tt><\/td>\n<\/tr>\n
mYiCoN<\/tt><\/td>\n<\/tr>\n
MYICON<\/tt><\/td>\n<\/tr>\n
myic\u00d6n<\/tt><\/td>\nMYIC\u00d6N<\/tt><\/td>\nNo<\/td>\nYes<\/td>\nNo<\/td>\n<\/tr>\n
MyIc\u00d6n<\/tt><\/td>\n<\/tr>\n
mYiC\u00d6N<\/tt><\/td>\n<\/tr>\n
MYIC\u00d6N<\/tt><\/td>\n<\/tr>\n
myic\u00f6n<\/tt><\/td>\n<\/tr>\n
MyIc\u00f6n<\/tt><\/td>\n<\/tr>\n
mYiC\u00f6N<\/tt><\/td>\n<\/tr>\n
MYIC\u00f6N<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Okay, so after we have accounted for how the Resource Compiler stores names and how FindResource<\/code> searches for names, the table looks less bonkers.<\/p>\n

The moral of the story, I think, is that you should just stick to ASCII characters for resource names. Everybody agrees on that subset.<\/p>\n

\u00b9 Note that the specification is incomplete: It doesn’t say what collation to use for sorting. Does it use a locale-sensitive sort, so that \u00d6<\/tt> comes before P<\/tt> in German, but after P<\/tt> in Swedish?\u00b3 Does it use a case-sensitive sort where all punctuation come before all alphabetics? The FindResource<\/code> function assumes that the resources are sorted lexicographically by code unit (not code point) numerical value. Which is a good thing, because you don’t want a file compiled on a German system to be considered corrupted by a Swedish system.<\/p>\n

\u00b2 But what about the #pragme code_page()<\/code> directive? That directive tells the Resource Compiler how to convert quoted strings to Unicode, but it does not affect character mapping or collation.<\/p>\n

\u00b3 In German dictionary sorting, the letter \u00d6<\/tt> is sorted as if it had no accent mark. But in German phone book sorting, the letter \u00d6<\/tt> is sorted as if it were two characters O<\/tt> + e<\/tt>. And in Austrian phone book sorting<\/a>, the letter \u00d6<\/tt> is sorted as if it were two characters O<\/tt> + \u00a8<\/tt>, where the \u00a8<\/tt> is treated as a character that comes after Z<\/tt>. And in Swedish<\/a>, the letter \u00d6<\/tt> is treated as one of the three accented characters that come after Z<\/tt>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Disagreements over the fine print.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-111129","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Disagreements over the fine print.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111129","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=111129"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111129\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=111129"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=111129"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=111129"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}