Does LoadBitMap() API creates paint issues?

I have a legacy system written in C++, MFC. I was checking a piece of code where LoadBitmap() was replaced with LoadImage() API. The comment written in the code says "LoadBitmap() uses the P开发者_如何转开发aged pool from Kernel memory and if the usage reaches the maximum limit then the paint issues would pop up. So LoadImage API should be used".

I googled a bit on this but didn't get much information. When I checked the MSDN, they say "Note that the use of LoadBitmap to load OEM bitmaps is deprecated and is supported only for backward compatibility"

My questions are: 1. Are there any issues with LoadBitmap() API? Why should we prefer LoadImage() over LoadBitmap() ? 2. What is OEM bitmaps? Is there any issue if I load normal BMP with LoadBitmap?

LoadBitmap() will only create display-compatible bitmaps, not device-independent bitmaps (DIBs). And, as the LoadBitmap() documentation itself says, right at the top, "This function has been superseded by the LoadImage function". It's almost surprising that LoadBitmap() is still around, since I think it's been superseded by LoadImage() since Windows 95! (Just goes to show how hard it is to drop backward-compatibility!)

OEM bitmaps are system-wide pre-defined images that can be requested by passing a NULL hInstance parameter and a magic lpBitmapName (like OBM_BTNCORNERS, OBM_CHECKBOXES, etc.). These used to be used by Windows to draw various parts of the UI, but this is now handled by DrawFrameControl(). Again, the OEM bitmaps are an old, old thing and the "new" behavior has been around for a long time.

Unless you have a strong reason to want to use LoadBitmap(), I'd follow the documented suggestion and use LoadImage(). To get LoadBitmap()-equivalent behavior, use:

LoadImage(hInstance, lpBitmapName, IMAGE_BITMAP, 0, 0, LR_DEFAULTCOLOR);

In new code you'd probably actually want a device-independent bitmap, in which case you have to use LoadImage(), and the last argument should be "LR_CREATEDIBSECTION". In your case of having legacy code, sticking with "LR_DEFAULTCOLOR" may be safer.