Question

Basically I have some simple code that does some things for files and I’m trying to port it to windows. I have something that looks like this:

int SomeFileCall(const char * filename){
#ifndef __unix__
    SomeWindowsFileCall(filename);
#endif
#ifdef __unix__
    /**** Some unix only stat code here! ****/
#endif
}

the line SomeWindowsFileCall(filename); causes the compiler error:
cannot convert parameter 1 from 'const char *' to 'LPCWSTR'

How do I fix this, without changing the SomeFileCall prototype?

Answer 1

Most of the Windows APIs that take strings have two versions: one that takes char * and one that takes WCHAR * (that latter is equivalent to wchar_t *).

SetWindowText, for example, is actually a macro that expands to either SetWindowTextA (which takes char *) or SetWindowTextW (which takes WCHAR *).

In your project, it sounds like all of these macros are referencing the -W versions. This is controlled by the UNICODE preprocessor macro (which is defined if you choose the “Use Unicode Character Set” project option in Visual Studio). (Some of Microsoft’s C and C++ run time library functions also have ANSI and wide versions. Which one you get is selected by the similarly-named _UNICODE macro that is also defined by that Visual Studio project setting.)

Typically, both of the -A and -W functions exist in the libraries and are available, even if your application is compiled for Unicode. (There are exceptions; some newer functions are available only in “wide” versions.)

If you have a char * that contains text in the proper ANSI code page, you can call the -A version explicitly (e.g., SetWindowTextA). The -A versions are typically wrappers that make wide character copies of the string parameters and pass control to the -W versions.

An alternative is to make your own wide character copies of the strings. You can do this with MultiByteToWideChar. Calling it can be tricky, because you have to manage the buffers. If you can get away with calling the -A version directly, that’s generally simpler and already tested. But if your char * string is using UTF-8 or any encoding other than the user’s current ANSI code page, you should do the conversion yourself.

Bonus Info

The -A suffix stands for “ANSI”, which was the common Windows term for a single-byte code-page character set.

The -W suffix stands for “Wide” (meaning the encoding units are wider than a single byte). Specifically, Windows uses little-endian UTF-16 for wide strings. The MSDN documentation simply calls this “Unicode”, which is a little bit of a misnomer.