MSDN states:

When specifying an explicit RGB color, the COLORREF value has the following hexadecimal form:

0x00bbggrr

The low-order byte contains a value for the relative intensity of red; the second byte contains a value for green; and the third byte contains a value for blue. The high-order byte must be zero. The maximum value for a single byte is 0xFF.

From wingdi.h

#define RGB(r,g,b)          ((COLORREF)((BYTE)(r) | ((BYTE)(g) << 8) | ((BYTE)(b) << 16)))

#define GetRValue(rgb)      ((BYTE)  (rgb) )
#define GetGValue(rgb)      ((BYTE) ((rgb) >> 8))
#define GetBValue(rgb)      ((BYTE) ((rgb) >> 16))

As windows is little endian, COLORREF is in RGBA format. This looks strange because isn't the color format that Windows use internally, BGR(A)?

The RGBQUAD structure is defined as

typedef struct tagRGBQUAD {
  BYTE rgbBlue;
  BYTE rgbGreen;
  BYTE rgbRed;
  BYTE rgbReserved;
} RGBQUAD;

which is, unlike COLORREF, BGRA.

Since the bitblt function expects an array of COLORREF values, this means that there is always an additional conversion going on from RGBA to BGRA during every call, if Windows use BGRA as its native format.

I don't remember correctly, but I also read somewhere that there is a strange mix in the pixel format used in the winapi.

Can someone please explain?