Is wchar_t needed to support unicode when using the WinApi?

Question

I am aware that normally you do not need wchar_t to support unicode for general purpose code, however, the Windows API seems to have a ASCII or Wide Character equivalent of all methods that take a string. For example:

FindWindowA(nullptr, "File Explorer");  // ASCII version
FindWindowW(nullptr, L"File Explorer"); // Wide Character version

I compile with Visual Studio 2017 using the following option in Properties > General:

Character Set: Use Unicode Character Set

The other available option is: Use Multi-Byte Character Set.

I want to be able to support filenames with unicode characters, and I am not sure if I should compile with the multi-byte character set and use all the Wide Character methods, or if I should compile with the unicode character set and use all the ASCII methods.

Answer 1

I am not sure if I should compile with the multi-byte character set and use all the Wide Character methods, or if I should compile with the unicode character set and use all the ASCII methods.

• If want to use Unicode, you must use the the wide "W" version of the functions along with wchar_t.
• If you want to use multi-byte character set (MBCS), you must use the the "A" version of the functions with char.
• The "A" version of the functions generally do not support all the Unicode characters and essentially widen their input parameter using MultiByteToWideChar(CP_ACP), call their "W" counterpart, and finally transform the result back into multi-byte using WideCharToMultiByte(CP_ACP).

Thus, I would advise you to use the "W" version of the functions assuming you are coding for Windows NT and above.

In the context of the Win32 API, Microsoft's "Unicode" generally refers to UTF-16. Also Microsoft's MBCS is essentially DBCS and for Windows 9x operating systems, the "W" version of the functions are missing.