[Bug 51899] 16-bit Collins Dictionary has black background.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51899

--- Comment #24 from Bruni  ---
(In reply to Nikolay Sivov from comment #23)
> Regarding selection color, it seems to be about how text color is handled,
> or maybe some issue with interpreting color value in dib engine. After
> SetTextColor(0xffffffff), color gets reset internally to 0 (black):

If you observed SetTextColor(0xffffffff) instead of SetTextColor(0x00ffffff),
most likely, this means you've discovered a bug either in SetTextColor's
implementation or in the implementation of its caller!

Explanation:

An old book "Using Visual C++ 6" by Kate Gregory states that the parameter to
SetTextColor() is a COLORREF, and you can directly specify combinations of red,
green, and blue as hex numbers in the form 0x00bbggrr, so that, for example,
0x000000FF is bright red. Most people prefer to use the RGB macro, which takes
hex numbers from 0x0 to 0xFF, specifying the amount of each color; bright red
is RGB(FF,0,0), for instance.

That book gives an example:
pointerToDC->SetTextColor(RGB(0,0,0)); //black

Wine has RGB macro and defines it as

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

https://source.winehq.org/git/wine.git/blob/ababea0fd7036ab13ec17d31afbd584c...

There is also a definition of RGB macro from Windows 3.1:

/* Color data type */
typedef DWORD   COLORREF;

/* Macros to manipulate RGB color values */
#define RGB( r, g, b ) \
    ((COLORREF)(((BYTE)(r) | ((WORD)(g) << 8)) | (((DWORD)(BYTE)(b)) << 16)))

http://www.rdos.net/svn/tags/V9.2.5/watcom/bld/w16api/include/win16.mh

Then I decided to check both Windows' macro and Wine's one just in case:

#include <stdio.h>
typedef unsigned char BYTE;
typedef unsigned short WORD;
typedef unsigned int DWORD, COLORREF;

#define RGBfromwine(r,g,b)          ((COLORREF)((BYTE)(r) | ((BYTE)(g) << 8) |
((BYTE)(b) << 16)))
#define RGBfromoldwindows( r, g, b ) \
    ((COLORREF)(((BYTE)(r) | ((WORD)(g) << 8)) | (((DWORD)(BYTE)(b)) << 16)))

int main() {
    printf("White in hex given by Wine's RGB macro: \t%#010x\n",
RGBfromwine(255,255,255));
    printf("White in hex given by Windows 3.1's RGB macro: \t%#010x\n",
RGBfromoldwindows(255,255,255));

return 0;
}

http://coliru.stacked-crooked.com/a/c9b111d5ab7f728f

Result:
> White in hex given by Wine's RGB macro: 	0x00ffffff
> White in hex given by Windows 3.1's RGB macro:	0x00ffffff

So the book told truth, seemingly.

(In reply to Nikolay Sivov from comment #23)
> get_pixel_color(0xffffffff) -> make_rgb_colorref() -> color & (1 << 24) -> 0.
> Masking out high byte at 16-bit SetTextColor, fixes selection for me,
> but I don't know what the right solution would look like.

So if dib engine gives white color for SetTextColor(0x00ffffff), this means dib
engine is ok

This narrows bug area to SetTextColor's implementation or to its callers

Trace would be useful.

I believe SetBkColor has similar problems.