UTF-8 support for windows entry

[cloudwu]

WM_CHAR was not handled correctly.

1. The window is create in ANSI mode, so WM_CHAR can't received unicode code point. WideCharToMultiByte will not get the UTF-8 string.

2. _wparam is a WPARAM, it's not a 16bit (WCHAR) integer. (LPCWSTR)&_wparam has some endian problem. Of cource, Windows always run on the little-endian platform :)

3. We should handle surrogate pairs. For example, the emoji U+1F604 😀 , it is posted by two WM_CHAR message. See unicode inputChar support for imguiBeginFrame #1756

[bkaradzic]

Is it really necessary for everything to become W? Instead just those things that actually accept W string?

[cloudwu]

Windows has some strange behaviors. I debug for hours today, just because I haven’t use DispatchMessageW :(

MSG structure has no string , and DispatchMessage is for thread rather than window. We can create ANSI and Unicode windows in the same thread. DispatchMessage should convert the WM_CHAR to correct version (ansi or unicode), but it doesn’t.

So I think two version of DispatchMessage is a design error. (TranslateMessage has only one version)

If we use A version APIs (DispatchMessage, DefaultWinProc, etc), the Unicode Window would receive strange WM_CHAR. it’s not ansi code neither unicode.

You can change some W version api (not for strings) to A version, and printf WM_CHAR’s WPARAM. I am not sure which one trigger the bug , so I think the only safe way is to use W version API everywhere.

[cloudwu]

I guess at least we should use DefWindowProcW instead of DefWindowProcA, because the window is created in W mode. I will test it tomorrow, but I don’t think mixing A and W APIs is a good idea.

[cloudwu]

https://microsoft.public.win32.programmer.international.narkive.com/UXxqhL7b/mixing-ansi-and-unicode-windows-and-wm-char-issues-with-ime-bugtest-zip-0-1

FYI

[cloudwu]

I reverted the unnecessary W APIs.

Except the API accept strings, there are three W APIs are necessary.

We should use DefWindowProcW because the window is in Unicode Mode.

PeekMessageW and DispatchMessageW are necessary because Unicode is a superset of ANSI, if we use A version APIs to dispatch thread message queue, some Unicode code points would be lost.