C++

Forum

 
Visual Studio 11 on the command line

MattJ812 (5)
Hello,

I have a quick question regarding compiling on the command line using visual studio 11.

I am going through the getting started tutorials on MSDN. http://msdn.microsoft.com/en-us/library/windows/desktop/ff381409(v=vs.85).aspx

Here is the code I am trying to compile...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
 
#include "stdafx.h"
#include <windows.h>
#include <sstream>

template <typename DERIVED_TYPE>
class BaseWindow
{
    public:
        static LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
        {
            DERIVED_TYPE *pThis = NULL;

            if(uMsg == WM_NCCREATE)
            {
                CREATESTRUCT *pCreate = (CREATESTRUCT*)lParam;
                pThis = (DERIVED_TYPE*)pCreate->lpCreateParams;
                SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG_PTR)pThis);

                pThis->m_hwnd = hwnd;
            }
            else
            {
                pThis = (DERIVED_TYPE*)GetWindowLongPtr(hwnd, GWLP_USERDATA);
            }
            if (pThis)
            {
                return pThis->HandleMessage(uMsg, wParam, lParam);
            }
            else
            {
                return DefWindowProc(hwnd, uMsg, wParam, lParam);
            }
        }

        BaseWindow() : m_hwnd(NULL), state(156){}

        BOOL Create(
                    LPCWSTR lpWindowName,
                    DWORD dwStyle,
                    DWORD dwExStyle = 0,
                    int x = CW_USEDEFAULT,
                    int y = CW_USEDEFAULT,
                    int nWidth = CW_USEDEFAULT,
                    int nHeight = CW_USEDEFAULT,
                    HWND hWndParent = 0,
                    HMENU hMenu = 0
                    )
        {
            WNDCLASS wc = {0};

            wc.lpfnWndProc   = DERIVED_TYPE::WindowProc;
            wc.hInstance     = GetModuleHandle(NULL);
            wc.lpszClassName = ClassName();

            RegisterClass(&wc);

            m_hwnd = CreateWindowEx(
                                    dwExStyle, ClassName(), lpWindowName, dwStyle, x, y,
                                    nWidth, nHeight, hWndParent, hMenu, GetModuleHandle(NULL), this
                                    );

            return (m_hwnd ? TRUE : FALSE);
        }

        HWND Window() const {return m_hwnd;}

    protected:
        virtual LPCWSTR ClassName() const = 0;
        virtual LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam) = 0;

        HWND m_hwnd;
        int state;
};

class MainWindow : public BaseWindow<MainWindow>
{
    public:
        LPCWSTR ClassName() const
        {
            return L"Simple Window Class";
        }
        LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam);
};

LRESULT MainWindow::HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch(uMsg)
    {
        case WM_CLOSE:
            if (MessageBox(m_hwnd, L"Really Quit?", L"THIS CRAP", MB_OKCANCEL) == IDOK)
            {
                DestroyWindow(m_hwnd);
            }
            break;
        case WM_DESTROY:
            PostQuitMessage(0);
            break;

        case WM_PAINT:
            {
                PAINTSTRUCT ps;
                HDC hdc = BeginPaint(m_hwnd, &ps);

                FillRect(hdc, &ps.rcPaint, (HBRUSH)(COLOR_WINDOW + 1));
                std::wstringstream SS;
                int a = state;
                SS << a;
                std::wstring S = SS.str();

                TextOut(hdc,20,20,S.c_str(),S.size());

                EndPaint(m_hwnd, &ps);
            }
            break;
        default:
            return DefWindowProc(m_hwnd, uMsg, wParam, lParam);
    }
}

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR lCmdLine, int nCmdShow)
{
    MainWindow win;

    if(!win.Create(L"Learn to Program Windows", WS_OVERLAPPEDWINDOW))
    {
        return 0;
    }

    ShowWindow(win.Window(), nCmdShow);

    MSG msg = {};
    while(GetMessage(&msg, NULL, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return 0;
}


When I build this in visual studio it works fine, but on the command line it complains about converting const wchar_t* to LPCSTR in the MessageBoxA and TextOutA. I assume then that it thinks I want to use regular characters instead of wide ones. (I am new to this).

I can remove those errors by specifying the wide versions of those functions along with the wide create window function. But the wndclass uses char_T.

I assume that there is a compiler or linker option or possibly other files that are being used behind the scenes in VS that I don't know about that I need to enter on the command line to get this to work.

Could anyone tell me what they might be?

Thanks.
Zhuge (4664)
You are passing wide strings to the Windows methods, but probably don't have UNICODE defined, causing it to call the ANSI versions that want char* (the A at the end of the functions is a hint there).

As I understand, there are a few options here:
- use TEXT() macros around literals and char_T* (I believe this is the one, didn't actually check) and use the standard function calls like you are
- use normal string literals and char* and use the A versions of functions
- use "wide" string literals and wchar_t* and use the W versions of functions
Last edited on
MattJ812 (5)
when I use #define UNICODE, I get a 'macro redefinition' warning when I build in VS and when I compile on the command line I get a string of LNK2019 ERRORS unresolved external symbol, so I took it out.

I mentioned before that everything works fine when I build in VS, the correct functions are being called, at least it appears that way.

When I specifically chose the W versions of the functions the compiler complains about this line....

wc.lpszClassName = ClassName();

lpszClassName is of type LPCTSTR I can't specify unicode or ansi here, surely something else is doing it for me.

When I build in VS I assume this type expects a wide character pointer, which is what I give it and it works fine, but when I compile on the command line it is expecting a regular character pointer and complains about the conversion.

I might be wrong but I am assuming that I have to give the compiler something else to work with when I compile on the command line but I don't know what it is.

Is VS linking or including something behind the scenes?
Zhuge (4664)
For some extra information (not a solution to your problem, but it relates to it):
http://www.cplusplus.com/forum/articles/16820/
Note specifically what the LPCTSTR and such are defined as based on your ANSI, etc. settings.

From the toolbar: Project -> Properties... -> Configuration Properties -> General -> Project Defaults -> Character Set is where you can essentially set whether you want UNICODE defined or not.

On the command line, I believe you'll just want to use either
/D "_UNICODE" /D "UNICODE" for the Unicode option
/D "_MBCS" for the multi-byte option

In any case, I'd guess the root of the issue is that you are mixing several of the options I specified above, resulting in incompatibilities when a place using wchar_t hits a char and so on.
modoran (2077)
when I use #define UNICODE, I get a 'macro redefinition' warning when I build in VS and when I compile on the command line I get a string of LNK2019 ERRORS unresolved external symbol, so I took it out.


You either define both UNICODE and _UNICODE macros, or none of them, not only one.

UNICODE is used by win32 API and _UNICODE is used by CRT functions as far as I remember.
andywestken (4087)
As you're already using wWinMain, LPCWSTR, Unicode literals, and the like, the best route would probably be to switch all Windows API functions to the -W form, e.g.

CreateWindowExW
RegisterClassW
MessageBoxW
TextOutW
...

and structs, etc

CREATESTRUCTW
WNDCLASSW
...

(i.e. the third option Zhuge listed.)

As has already been mentioned, almost all Windows "functions" which take a string are actually macros which evaluate to the ANSI (-A) or Unicode (or Wide, -W) function, depending on whether or not UNICODE is defined. e.g. TextOut is a macro which evaluates to TextOutA or TextOutW. (Functions which do not have any string parameters will only have a single form.)

Same deal with structs which have a character buffer or pointer member; and TCHAR is not a distinct type itself, it is a typedef of either char or wchar_t depending on whether UNICODE or _UNICODE is set or not (the CRT tchar.h and the Windows WinNT.h headers both typedef TCHAR.)

The 'macro redefinition' warning you get with Visual Studio is because UNICODE and _UNICODE are added automatically when the Character Set property of the project is set to Unicode.

Andy

PS Making the W- changes plus removing #include "stdafx.h", as it was unnecessary, I ended up with the code below which compiled with just a few warnings:

C:\Test>cl /nologo /W4 /EHsc /MDd -DDEBUG -D_DEBUG kernel32.lib user32.lib gdi32.lib /Fetest.exe main.cpp

main.cpp
main.cpp(119) : warning C4100: 'lCmdLine' : unreferenced formal parameter
main.cpp(119) : warning C4100: 'hPrevInstance' : unreferenced formal parameter
main.cpp(119) : warning C4100: 'hInstance' : unreferenced formal parameter
c:\Test\main.cpp(117) : warning C4715: 'MainWindow::HandleMessage' : not all control paths return a value


(HandleMessage needs to return 0 at the end. And the other warnings can be fixed as usual:

int CALLBACK wWinMain(HINSTANCE hInstance, HINSTANCE /*hPrevInstance*/, PWSTR /*lCmdLine*/, int /*nCmdShow*/)

where I'm also using CALLBACK rather than WINAPI, in line with the current signature that the MSDN entry for WinMain is giving.)

And ran ok!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
 
#include <windows.h>
#include <sstream>

template <typename DERIVED_TYPE>
class BaseWindow
{
    public:
        static LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
        {
            DERIVED_TYPE *pThis = NULL;

            if(uMsg == WM_NCCREATE)
            {
                CREATESTRUCTW *pCreate = (CREATESTRUCTW*)lParam;
                pThis = (DERIVED_TYPE*)pCreate->lpCreateParams;
                SetWindowLongPtrW(hwnd, GWLP_USERDATA, (LONG_PTR)pThis);

                pThis->m_hwnd = hwnd;
            }
            else
            {
                pThis = (DERIVED_TYPE*)GetWindowLongPtrW(hwnd, GWLP_USERDATA);
            }
            if (pThis)
            {
                return pThis->HandleMessage(uMsg, wParam, lParam);
            }
            else
            {
                return DefWindowProcW(hwnd, uMsg, wParam, lParam);
            }
        }

        BaseWindow() : m_hwnd(NULL), state(156){}

        BOOL Create(
                    LPCWSTR lpWindowName,
                    DWORD dwStyle,
                    DWORD dwExStyle = 0,
                    int x = CW_USEDEFAULT,
                    int y = CW_USEDEFAULT,
                    int nWidth = CW_USEDEFAULT,
                    int nHeight = CW_USEDEFAULT,
                    HWND hWndParent = 0,
                    HMENU hMenu = 0
                    )
        {
            WNDCLASSW wc = {0};

            wc.lpfnWndProc   = DERIVED_TYPE::WindowProc;
            wc.hInstance     = GetModuleHandle(NULL);
            wc.lpszClassName = ClassName();

            RegisterClassW(&wc);

            m_hwnd = CreateWindowExW(
                                    dwExStyle, ClassName(), lpWindowName, dwStyle, x, y,
                                    nWidth, nHeight, hWndParent, hMenu, GetModuleHandle(NULL), this
                                    );

            return (m_hwnd ? TRUE : FALSE);
        }

        HWND Window() const {return m_hwnd;}

    protected:
        virtual LPCWSTR ClassName() const = 0;
        virtual LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam) = 0;

        HWND m_hwnd;
        int state;
};

class MainWindow : public BaseWindow<MainWindow>
{
    public:
        LPCWSTR ClassName() const
        {
            return L"Simple Window Class";
        }
        LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam);
};

LRESULT MainWindow::HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch(uMsg)
    {
        case WM_CLOSE:
            if (MessageBoxW(m_hwnd, L"Really Quit?", L"THIS CRAP", MB_OKCANCEL) == IDOK)
            {
                DestroyWindow(m_hwnd);
            }
            break;
        case WM_DESTROY:
            PostQuitMessage(0);
            break;

        case WM_PAINT:
            {
                PAINTSTRUCT ps;
                HDC hdc = BeginPaint(m_hwnd, &ps);

                FillRect(hdc, &ps.rcPaint, (HBRUSH)(COLOR_WINDOW + 1));
                std::wstringstream SS;
                int a = state;
                SS << a;
                std::wstring S = SS.str();

                TextOutW(hdc,20,20,S.c_str(),S.size());

                EndPaint(m_hwnd, &ps);
            }
            break;
        default:
            return DefWindowProcW(m_hwnd, uMsg, wParam, lParam);
    }
}

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR lCmdLine, int nCmdShow)
{
    MainWindow win;

    if(!win.Create(L"Learn to Program Windows", WS_OVERLAPPEDWINDOW))
    {
        return 0;
    }

    ShowWindow(win.Window(), nCmdShow);

    MSG msg = {};
    while(GetMessageW(&msg, NULL, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessageW(&msg);
    }

    return 0;
}

Last edited on
MattJ812 (5)
Cool, I didn't see the -W version of WNDCLASS in the MSDN documentation when I was trying to change all the functions to -W.

Though my original question still remains, why does the original code build and run just fine within the Visual Studio IDE?

Here's the output I get when I try to compile on the command line.


c:\Users\Matt\Documents\Visual Studio 2012\Projects\Win32Project3\Win32Project3>
cl win32project3.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

win32project3.cpp
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xlocale(336) : wa
rning C4530: C++ exception handler used, but unwind semantics are not enabled. S
pecify /EHsc
win32project3.cpp(90) : error C2664: 'MessageBoxA' : cannot convert parameter 2
from 'const wchar_t [13]' to 'LPCSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-
style cast or function-style cast
win32project3.cpp(110) : error C2664: 'TextOutA' : cannot convert parameter 4 fr
om 'const wchar_t *' to 'LPCSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-
style cast or function-style cast

c:\Users\Matt\Documents\Visual Studio 2012\Projects\Win32Project3\Win32Project3>


Here's the output I get when I use /DUNICODE.

c:\Users\Matt\Documents\Visual Studio 2012\Projects\Win32Project3\Win32Project3>
cl win32project3.cpp /DUNICODE
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

win32project3.cpp
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xlocale(336) : wa
rning C4530: C++ exception handler used, but unwind semantics are not enabled. S
pecify /EHsc
c:\users\matt\documents\visual studio 2012\projects\win32project3\win32project3\
win32project3.cpp(118) : warning C4715: 'MainWindow::HandleMessage' : not all co
ntrol paths return a value
Microsoft (R) Incremental Linker Version 11.00.50727.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:win32project3.exe
win32project3.obj
win32project3.obj : error LNK2019: unresolved external symbol __imp__TextOutW@20
 referenced in function "public: virtual long __thiscall MainWindow::HandleMessa
ge(unsigned int,unsigned int,long)" (?HandleMessage@MainWindow@@UAEJIIJ@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__GetMessageW
@16 referenced in function _wWinMain@16
win32project3.obj : error LNK2019: unresolved external symbol __imp__TranslateMe
ssage@4 referenced in function _wWinMain@16
win32project3.obj : error LNK2019: unresolved external symbol __imp__DispatchMes
sageW@4 referenced in function _wWinMain@16
win32project3.obj : error LNK2019: unresolved external symbol __imp__DefWindowPr
ocW@16 referenced in function "public: virtual long __thiscall MainWindow::Handl
eMessage(unsigned int,unsigned int,long)" (?HandleMessage@MainWindow@@UAEJIIJ@Z)

win32project3.obj : error LNK2019: unresolved external symbol __imp__PostQuitMes
sage@4 referenced in function "public: virtual long __thiscall MainWindow::Handl
eMessage(unsigned int,unsigned int,long)" (?HandleMessage@MainWindow@@UAEJIIJ@Z)

win32project3.obj : error LNK2019: unresolved external symbol __imp__RegisterCla
ssW@4 referenced in function "public: int __thiscall BaseWindow<class MainWindow
>::Create(wchar_t const *,unsigned long,unsigned long,int,int,int,int,struct HWN
D__ *,struct HMENU__ *)" (?Create@?$BaseWindow@VMainWindow@@@@QAEHPB_WKKHHHHPAUH
WND__@@PAUHMENU__@@@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__CreateWindo
wExW@48 referenced in function "public: int __thiscall BaseWindow<class MainWind
ow>::Create(wchar_t const *,unsigned long,unsigned long,int,int,int,int,struct H
WND__ *,struct HMENU__ *)" (?Create@?$BaseWindow@VMainWindow@@@@QAEHPB_WKKHHHHPA
UHWND__@@PAUHMENU__@@@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__DestroyWind
ow@4 referenced in function "public: virtual long __thiscall MainWindow::HandleM
essage(unsigned int,unsigned int,long)" (?HandleMessage@MainWindow@@UAEJIIJ@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__ShowWindow@
8 referenced in function _wWinMain@16
win32project3.obj : error LNK2019: unresolved external symbol __imp__BeginPaint@
8 referenced in function "public: virtual long __thiscall MainWindow::HandleMess
age(unsigned int,unsigned int,long)" (?HandleMessage@MainWindow@@UAEJIIJ@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__EndPaint@8
referenced in function "public: virtual long __thiscall MainWindow::HandleMessag
e(unsigned int,unsigned int,long)" (?HandleMessage@MainWindow@@UAEJIIJ@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__MessageBoxW
@16 referenced in function "public: virtual long __thiscall MainWindow::HandleMe
ssage(unsigned int,unsigned int,long)" (?HandleMessage@MainWindow@@UAEJIIJ@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__FillRect@12
 referenced in function "public: virtual long __thiscall MainWindow::HandleMessa
ge(unsigned int,unsigned int,long)" (?HandleMessage@MainWindow@@UAEJIIJ@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__GetWindowLo
ngW@8 referenced in function "public: static long __stdcall BaseWindow<class Mai
nWindow>::WindowProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WindowPr
oc@?$BaseWindow@VMainWindow@@@@SGJPAUHWND__@@IIJ@Z)
win32project3.obj : error LNK2019: unresolved external symbol __imp__SetWindowLo
ngW@12 referenced in function "public: static long __stdcall BaseWindow<class Ma
inWindow>::WindowProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WindowP
roc@?$BaseWindow@VMainWindow@@@@SGJPAUHWND__@@IIJ@Z)
win32project3.exe : fatal error LNK1120: 16 unresolved externals


Is this a linking problem?
Veltas (450)
Yes, this is a linking problem.

You need to link with the appropriate .lib files for the components of the windows API you're using. For example, on MSDN TextOut apparently requires linking with Gdi32.lib:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd145133%28v=vs.85%29.aspx

So try CL win32project3.cpp Gdi32.lib and try again, looking up .lib files as it complains about them.

EDIT: But immediately try CL win32project3.cpp Gdi32.lib kernel32.lib user32.lib because that probably hits 'em all.
Last edited on
Veltas (450)
Let me give you some advice.

1
2
3
 
#ifndef UNICODE
#define UNICODE
#endif


Or rather, some code, not advice.
Veltas (450)
I feel somewhat obliged to explain how CL works.

CL is a compiler and linker, you give it multiple files. If those files look like source code it compiles them, .cpp are compiled as C++ and .c are compiled as 1980s C.

Source files are turned into a .obj file each by compilation, these contain the program in a manageable computer form. It retains the names of functions that were declared but not defined, and other similar stuff, in the hope that it will find them during linking.

Then linking occurs: produced .obj files, any .obj files given to CL originally, and any .lib files given are all used to try and match any referenced functions, variables, etc., and all the code required by the .obj file with an appropriate entry point (main, WinMain, etc) is copied into one big fat happy binary executable that (hopefully) gets spat out at the end, and is named after the first input file (for some reason). It ends in .exe.

.lib files work slightly differently than .obj files in linking; instead of copying the code for the used functions from a .lib into the executable, it instead sets the executable up to load a special binary file called a DLL (dynamically linked library) and get it to pretend that it's part of the program during runtime. This has the advantages that only one copy of the DLL is needed in memory even for multiple applications all running at once using that DLL, and you can update how the DLL works without rebuilding the applications that use it provided the function interfaces remain the same.
Veltas (450)
Go into C:\Windows\System32, you will find lots of DLLs (and other things) and among them will be user32.dll, kernel32.dll, and gdi32.dll. These are the binaries your system will make sure are loaded and will pretend they are part of your application so that you can call BeginPaint etc.

I don't need to tell you not to delete them.
Veltas (450)
The reason why Visual Studio's IDE doesn't produce these errors is behind its project properties.

It likely has options set that get it to tell CL about kernel32.lib, etc. and to define UNICODE automatically, to try and stop you from having to worry about that stuff. Have a look through the project properties and you'll probably see the .libs I mentioned and more.

I almost wish VS didn't do stuff like this, because it makes using CL from the command line look bad.
Veltas (450)
I believe this article may help clear some things up about this UNICODE business:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd374131%28v=vs.85%29.aspx
MattJ812 (5)
EDIT: But immediately try CL win32project3.cpp Gdi32.lib kernel32.lib user32.lib because that probably hits 'em all.


Awesome, that did it. Turns out I don't need kernel32.lib to compile, user32.lib resolved all but one of the errors and as you mentioned gdi32.lib fixed the TextOut function.

I've been using mingw up until now but I thought I'd check out visual studio because of some apparent compatibility problems with windows functions. It's gonna take a little while to get used to it.

Thanks a bunch!
Veltas (450)
Yeah mingw is a little rubbish. And it doesn't support UNICODE properly, either, it just kind of hides it from you.
modoran (2077)
It does not support wmain or wWinMain entry points and some CRT functions lack Unicode support, but it fully supports win32 API functions which uses Unicode (UTF-16).
Veltas (450)
modoran:

It has no need to support wWinMain, it's only barely even mentioned in MSDN and is described fully only in the context of Visual Studio, stating that it may or may not exist with other compilers and may or may not even be called wWinMain. So I personally never use wWinMain because it's not worth worrying about.

But I have had my fair share of trouble with mingw nonetheless.
Topic archived. No new replies allowed.