Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Consider the following Windows API-level program:</p> <pre><code>#define NOMINMAX #include &lt;windows.h&gt; int main() { MessageBox( 0, "Blah blah...", "My Windows app!", MB_SETFOREGROUND ); } </code></pre> <p>Now let's build it using GNU toolchain (i.e. g++), no special options. Here <code>gnuc</code> is just a batch file that I use for that. It only supplies options to make g++ more standard:</p> <pre> C:\test&gt; gnuc x.cpp C:\test&gt; objdump -x a.exe | findstr /i "^subsystem" Subsystem 00000003 (Windows CUI) C:\test&gt; _ </pre> <p>This means that the linker by default produced a <strong>console subsystem</strong> executable. The <strong>subsystem</strong> value in the file header tells Windows what services the program requires. In this case, with console system, that the program requires a console window.</p> <p>This also causes the command interpreter to wait for the program to complete.</p> <p>Now let's build it with <strong>GUI subsystem</strong>, which just means that the program does not require a console window:</p> <pre> C:\test&gt; gnuc x.cpp -mwindows C:\test> objdump -x a.exe | findstr /i "^subsystem" Subsystem 00000002 (Windows GUI) C:\test&gt; _ </pre> <p>Hopefully that's OK so far, although the <code>-mwindows</code> flag is just semi-documented.</p> <p>Building without that semi-documented flag one would have to more specifically tell the linker which subsystem value one desires, and some Windows API import libraries will then in general have to be specified explicitly:</p> <pre> C:\test&gt; gnuc x.cpp -Wl,-subsystem,windows C:\test> objdump -x a.exe | findstr /i "^subsystem" Subsystem 00000002 (Windows GUI) C:\test&gt; _ </pre> <p>That worked fine, with the GNU toolchain.</p> <p>But what about the Microsoft toolchain, i.e. Visual C++?</p> <p>Well, building as a console subsystem executable works fine:</p> <pre> C:\test&gt; msvc x.cpp user32.lib x.cpp C:\test&gt; dumpbin /headers x.exe | find /i "subsystem" | find /i "Windows" 3 subsystem (Windows CUI) C:\test&gt; _ </pre> <p>However, with Microsoft's toolchain building as GUI subsystem does not work by default:</p> <pre> C:\test&gt; msvc x.cpp user32.lib /link /subsystem:windows x.cpp LIBCMT.lib(wincrt0.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartu p x.exe : fatal error LNK1120: 1 unresolved externals C:\test&gt; _ </pre> <p>Technically this is because Microsoft&rsquo;s linker <em>is non-standard by default for GUI subsystem</em>. By default, when the subsystem is GUI, then Microsoft's linker uses a runtime library <strong>entry point</strong>, the function where the machine code execution starts, called <code>winMainCRTStartup</code>, that calls Microsoft's non-standard <strong><code>WinMain</code></strong> instead of standard <code>main</code>.</p> <p>No big deal to fix that, though.</p> <p>All you have to do is to tell Microsoft's linker which entry point to use, namely <code>mainCRTStartup</code>, which calls standard <code>main</code>:</p> <pre> C:\test&gt; msvc x.cpp user32.lib /link /subsystem:windows /entry:mainCRTStartup x.cpp C:\test&gt; dumpbin /headers x.exe | find /i "subsystem" | find /i "Windows" 2 subsystem (Windows GUI) C:\test&gt; _ </pre> <p>No problem, but very tedious. And so arcane and hidden that most Windows programmers, who mostly only use Microsoft&rsquo;s non-standard-by-default tools, do not even know about it, and mistakenly think that a Windows GUI subsystem program &ldquo;must&rdquo; have non-standard <code>WinMain</code> instead of standard <code>main</code>. In passing, with C++0x Microsoft will have a problem with this, since the compiler must then advertize whether it's free-standing or hosted (when hosted it must support standard <code>main</code>).</p> <p>Anyway, that's the reason why g++ <em>can</em> complain about <code>WinMain</code> missing: it's a silly non-standard startup function that Microsoft's tools require by default for GUI subsystem programs.</p> <p>But as you can see above, g++ has no problem with standard <code>main</code> even for a GUI subsystem program.</p> <p>So what could be the problem?</p> <p>Well, you are probably <em>missing</em> a <code>main</code>. And you probably have no (proper) <code>WinMain</code> either! And then g++, after having searched for <code>main</code> (no such), and for Microsoft's non-standard <code>WinMain</code> (no such), reports that the latter is missing.</p> <p>Testing with an empty source:</p> <pre> C:\test&gt; type nul >y.cpp C:\test&gt; gnuc y.cpp -mwindows c:/program files/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libmingw32.a(main.o):main.c:(.text+0xd2): undefined referen ce to `WinMain@16' collect2: ld returned 1 exit status C:\test&gt; _ </pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload