{"id":15693,"date":"2009-12-11T07:00:00","date_gmt":"2009-12-11T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2009\/12\/11\/the-format-of-bitmap-resources\/"},"modified":"2009-12-11T07:00:00","modified_gmt":"2009-12-11T07:00:00","slug":"the-format-of-bitmap-resources","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20091211-00\/?p=15693","title":{"rendered":"The format of bitmap resources"},"content":{"rendered":"

Another in a sporadic series on the format of Win32 resources.\n Here’s a question from a customer:<\/p>\n

I’m noticing some strange behavior: When I call LoadResource<\/code> then LockResource<\/code> on an embedded bitmap, the data being returned by LockResource<\/code> is not a properly formatted bitmap. The data is missing the BITMAPFILEHEADER<\/code>, but the rest of the file is there. SizeOfResource<\/code> also states that the bitmap resource is 14 bytes smaller than it actually is. 14 bytes happens to be equal to sizeof(BITMAPFILEHEADER)<\/code>. However, if I load the bitmap directly using LoadBitmap<\/code>, everything works fine. If I look at the resource using Visual Studio, the Bitmap displays correctly and the binary data correctly includes the BITMAPFILEHEADER<\/code>. <\/p>\n

Anyone have any ideas as to why LoadResource<\/code> is not correctly returning the BITMAPFILEHEADER<\/code>? <\/p>\n<\/blockquote>\n

Amusingly, a change to the word order changes the question to its own answer: LoadResource<\/code> is correctly<\/i> not<\/i> returning the BITMAPFILEHEADER<\/code>.\n In other words, LoadResource<\/code> is not stripping off the BITMAPFILEHEADER<\/code>: rc.exe<\/code> is.\n The format of bitmap resources are pretty simple. They are just a bitmap file with the BITMAPFILEHEADER<\/code> stripped off. Because it’s just the file header<\/i>, the thing tacked onto the front when saved as a file. It’s not part of the bitmap itself. For example, if you are using a BITMAPINFOHEADER<\/code>-formatted bitmap, then the resource format is a BITMAPINFOHEADER<\/code> followed by the pixels.\n I can’t explain why Visual Studio is showing you a BITMAPFILEHEADER<\/code> that doesn’t exist. They’re probably trying to reduce confusion for people who don’t know the format of bitmap resources and wonder why the binary data doesn’t match their .bmp<\/code> file. Of course, in so doing, they end up creating confusion for people who do know the format of bitmap resources, or—as happened here—people who don’t know the format of bitmap resources and think that the LoadResource<\/code> function is messing with their bitmaps.<\/p>\n

(For the record, the LoadResource<\/code> function doesn’t mess with bitmaps, icons, menus, or whatever. It just returns the raw binary data of a Win32 resource. It doesn’t know the internal format of those resources any more than the file system knows the internal format of a Quicken data file or a shortcut file.) <\/p>\n","protected":false},"excerpt":{"rendered":"

Another in a sporadic series on the format of Win32 resources. Here’s a question from a customer: I’m noticing some strange behavior: When I call LoadResource then LockResource on an embedded bitmap, the data being returned by LockResource is not a properly formatted bitmap. The data is missing the BITMAPFILEHEADER, but the rest of the […]<\/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-15693","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Another in a sporadic series on the format of Win32 resources. Here’s a question from a customer: I’m noticing some strange behavior: When I call LoadResource then LockResource on an embedded bitmap, the data being returned by LockResource is not a properly formatted bitmap. The data is missing the BITMAPFILEHEADER, but the rest of the […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/15693","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=15693"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/15693\/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=15693"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=15693"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=15693"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}