Unicode and ANSI functions and parameters based on WinMain and wWinMain

Question

Does anyone know when we need to use Unicode function rather than ANSI function when we use WinMain or wWinMain? Or can we use the normal generic function? And also with the usage of WinMain or wWinMain, will it affect the type of parameter used in a function?

For example in the two different tutorials of creating empty windoes, one tutorial from MSDN specifies like this:

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE, PWSTR pCmdLine, int nCmdShow)
{
   ...    
    // Create the window.

    HWND hwnd = CreateWindowEx(
        0,                              // Optional window styles.
        CLASS_NAME,                     // Window class
        L"Learn to Program Windows",    // Window text
        WS_OVERLAPPEDWINDOW,            // Window style

        // Size and position
        CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

        NULL,       // Parent window    
        NULL,       // Menu
        hInstance,  // Instance handle
        NULL        // Additional application data
        );

While another tutorial specifies like this:

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
    LPSTR lpCmdLine, int nCmdShow)
{
...
    hwnd = CreateWindowEx(
        WS_EX_CLIENTEDGE,
        g_szClassName,
        "The title of my window",
        WS_OVERLAPPEDWINDOW,
        CW_USEDEFAULT, CW_USEDEFAULT, 240, 120,
        NULL, NULL, hInstance, NULL);

Notice in the title of the window, one is using L"Title" while another is using "Title", so I assume that depending of types of WinMain it also affects type of parameters since as far as I know wWinMain is used for Unicode and WinMain is for ANSI.

Also another related question if I am using wWinMain or WinMain and then I use the generic function, such as MessageBox, will it resolve to MessageBoxW or MessageBoxA depending of WinMain type?

Thanks

Whether your program is built for Unicode or not is determined by the *Character Set* option in Visual Studio (which in turn defines the `UNICODE` and `_UNICODE` macros). — Jonathan Potter, Nov 20 '16 at 19:05
@JonathanPotter whats the difference between UNICODE and _UNICODE? — Ihsan Haikal, Nov 20 '16 at 19:18
Just legacy I think, some things use one and some things use the other. — Jonathan Potter, Nov 20 '16 at 19:20
@JonathanPotter and how about the usage of the string for title? There is one with L and another without L. Does it depend on the macros as well? — Ihsan Haikal, Nov 20 '16 at 19:22
@JonathanPotter: `UNICODE` is used for the Windows SDK header files, while `_UNICODE` controls the character set in the C runtime (see [TEXT vs. _TEXT vs. _T, and UNICODE vs. _UNICODE](https://blogs.msdn.microsoft.com/oldnewthing/20040212-00/?p=40643)). — IInspectable, Nov 20 '16 at 20:16
@IhsanHaikal `L""` defines a unicode string constant whether you are building for unicode or not. You can use the `TEXT` macro to make a string constant that turns into either ansi or unicode as appropriate, but honestly there is no reason not to build for unicode these days. — Jonathan Potter, Nov 20 '16 at 21:33
@JonathanPotter: Minor correction: `L""` defines a wide character [string literal](http://en.cppreference.com/w/cpp/language/string_literal), but doesn't make any promises about the character encoding. A Unicode (UTF-16) string literal in C++ would be `u""`. With Windows compilers, the distinction isn't important, though. In fact, you cannot even pass `u""` to any Windows API calls. — IInspectable, Nov 20 '16 at 22:26

andlabs · Answer 1 · 2016-11-20T19:11:19.857

2

WinMain() and wWinMain() don't affect whether the program runs as ANSI or Unicode or not; all it determines is how the pCmdLine parameter is encoded. (You should be using GetCommandLine() anyway because pCmdLine doesn't include the program name, and possibly other things but I've forgotten where on MSDN I found the warnings... Combining GetCommandLineW() and CommandLineToArgvW() will let you get an argc/argv pair even in a program that uses WinMain().)

What decides if your APIs are ANSI or Unicode are the _UNICODE and UNICODE macros, but you're probably better off using the W-suffixed functions explicitly (but keep the two defined anyway).

What decides if your windows are Unicode or not is whether you used RegisterClassW()/RegisterClassExW() on the window class or not.

edited Nov 20 '16 at 19:11

answered Nov 20 '16 at 19:05

andlabs

11,290
1
31
52

How can we check the macros for the program? In the tutorial it does not explicitly use the W end function, so maybe the compiler knows which specific function will be executed based on Macros? – Ihsan Haikal Nov 20 '16 at 19:24
Yes, the compiler knows. Code in the system header files uses `#ifdef` to see if the headers are defined, and `#define FunctionNameHere FunctionNameHereW` (or `FunctionNameHereA`) to do the aliasing. There is also the TCHAR system, for creating programs that could be compiled both ways. You don't need to do this anymore unless you still need to support Windows 9x or older. The best approach is to just use Unicode everywhere, and if you need ASCII, use UTF-8 and convert to/from UTF-16 when necessary (`MultiByteToWideChar()`/`WideCharToMultiByte()`). – andlabs Nov 20 '16 at 19:25
It's the `UNICODE` preprocessor symbol alone, that controls the character set used in the Windows API. `_UNICODE` controls the character set used by the C runtime header files. – IInspectable Nov 20 '16 at 20:20

score 0 · Answer 2 · answered Nov 20 '16 at 19:26

you, like many, full of confusion in terms of a lack of understanding of the fundamental things. first of all we need direct or indirect set the /ENTRY (Entry-Point Symbol) of our exe. if no direct /ENTRY:function option set, linker use defaults - say select wWinMainCRTStartup when UNICODE defined and /SUBSYSTEM:WINDOWS and WinMainCRTStartup when /SUBSYSTEM:WINDOWS but UNICODE not defined. wWinMainCRTStartup internally call wWinMain when WinMainCRTStartup internally call WinMain. so choose entry point is dependent on defined UNICODE or no, but only if /ENTRY:function not direct set. we can for example define UNICODE but set /ENTRY:WinMainCRTStartup and need be implement "ANSI" WinMain. and at all we can not use CRT at all and set as EP any own function

about using A or W version of functions in code - say MessageBox this is only macro which expanded to MessageBoxW or MessageBoxA dependent form are UNICODE is defined in compilation time. however we can not use macro but full functions names. so we can mix in same code MessageBoxA and CreateFileW, CreateProcessA and CreateWindowExW

Unicode and ANSI functions and parameters based on WinMain and wWinMain

2 Answers2