Skip to content

Windows: Compile with the UNICODE / _UNICODE macros

Luca Bacci requested to merge lb90/glib:win32-unicode-api into main

Windows uses the UTF-16 encoding internally, but still provides functions expecting narrow strings (in either the Active CodePage or the OEM CodePage) for backward compatibility, as it was developed before Unicode. For example, user32 exports both RegisterClassW (UTF-16) and RegisterClassA (CodePage). Almost every function dealing with strings has W and A variants (some newer functions are UTF-16 only). Internally, A functions translate from the ACP to UTF-16 and then call the W variant.

The Windows SDK supports both models through conditional compilation. It defaults to narrow string definitions for backward compatibility, but gives Unicode definitions if UNICODE is defined, which is recommended (it's the default in Visual Studio).

That way we never use A functions inadvertently, as it's not always clear if a function has ACP / UTF-16 variants.

This doesn't prevent one from using A function if they want, they just have to be explicit. This is "Unicode by default, ACP only if explicit".

This is a continuation of !1848 (merged)


Edited by Luca Bacci

Merge request reports