Date: | April 20, 2007 / year-entry #138 |
Tags: | code |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070420-00/?p=74641 |
Comments: | 6 |
Summary: | The next entry in the continuing sporadic series on resource formats is the bitmap. You thought accelerator tables were simple; bitmaps are even simpler. A bitmap resource takes the same form as a bmp file, except that there is no BITMAPFILEHEADER. That's all. |
The next entry in the continuing sporadic series on resource formats is the bitmap. You thought accelerator tables were simple; bitmaps are even simpler. A bitmap resource takes the same form as a |
Comments (6)
Comments are closed. |
Simple to write an article about, perhaps. The BMP file format is simple, but it isn’t exactly trivial.
Well, the bfOffBits member of the BITMAPFILEHEADER does imply that the bitmap bits doesn’t have to follow directly after the BITMAPINFOHEADER. A bitmap resource on the other hand is strictly a packed bitmap – one where the bits follow directly after the header.
Yes, the documentation says: "A BITMAPINFO or BITMAPCOREINFO structure immediately follows the BITMAPFILEHEADER structure in the DIB file."
So the BITMAPFILEHEADER structure seems pointless. Which raises the question why its used for bitmap files at all.
Because someone thought when originally defining it that it might be a good idea if it could be extended, but it never has been?
The Windows SDK is littered with unused extension points, as are probably most large systems.
Someone’s slacking on Friday!
(Nitpicker’s corner: I know Raymond writes his entries a long time in advance. It’s a joke.)
bfOffBits refers to the beginning of the bitmap bits. That means there can be an arbitrary amount of space between the BITMAPINFO/palette and the actual bits. Which means you could put almost anything you want between the header and the bits, and not break properly written software.