<p>How do I create a windows application that does the following:</p>

<ul>
<li>it's a regular GUI app when invoked with no command line arguments</li>
<li>specifying the optional "--help" command line argument causes the app to write usage text to stdout then terminate</li>
<li>it must be a single executable.  No cheating by making a console app exec a 2nd executable.</li>
<li>assume the main application code is written in C/C++</li>
<li>bonus points if no GUI window is created when "--help" is specified.  (i.e., no flicker from a short-lived window)</li>
</ul>

<p>In my experience the standard visual studio template for console app has no GUI capability, and the normal win32 template does not send its stdout to the parent cmd shell.</p>

[{'answer_id': 113032, 'author': 'Hugh Allen', 'author_id': 15069, 'author_profile': 'https://Stackoverflow.com/users/15069', 'pm_score': 5, 'selected': False, 'text': '<p>Microsoft designed console and GUI apps to be mutually exclusive.\nThis bit of short-sightedness means that there is no perfect solution.\nThe most popular approach is to have two executables (eg. cscript / wscript,\njava / javaw, devenv.com / devenv.exe etc) however you\'ve indicated that you consider this "cheating".</p>\n\n<p>You\'ve got two options - to make a "console executable" or a "gui executable",\nand then use code to try to provide the other behaviour.</p>\n\n<ul>\n<li>GUI executable:</li>\n</ul>\n\n<p><code>cmd.exe</code> will assume that your program does no console I/O so won\'t wait for it to terminate\nbefore continuing, which in interactive mode (ie not a batch) means displaying the next ("<code>C:\\&gt;</code>") prompt\nand reading from the keyboard. So even if you use AttachConsole your output will be mixed\nwith <code>cmd</code>\'s output, and the situation gets worse if you try to do input. This is basically a non-starter.</p>\n\n<ul>\n<li>Console executable:</li>\n</ul>\n\n<p>Contrary to belief, there is nothing to stop a console executable from displaying a GUI, but there are two problems.</p>\n\n<p>The first is that if you run it from the command line with no arguments (so you want the GUI),\n<code>cmd</code> will still wait for it to terminate before continuing, so that particular\nconsole will be unusable for the duration. This can be overcome by launching\na second process of the same executable (do you consider this cheating?), \npassing the DETACHED_PROCESS flag to CreateProcess() and immediately exiting.\nThe new process can then detect that it has no console and display the GUI.</p>\n\n<p>Here\'s C code to illustrate this approach:</p>\n\n<pre><code>#include &lt;stdio.h&gt;\n#include &lt;windows.h&gt;\n\nint main(int argc, char *argv[])\n{\n    if (GetStdHandle(STD_OUTPUT_HANDLE) == 0) // no console, we must be the child process\n    {\n        MessageBox(0, "Hello GUI world!", "", 0);\n    }\n    else if (argc &gt; 1) // we have command line args\n    {\n        printf("Hello console world!\\n");\n    }\n    else // no command line args but a console - launch child process\n    {\n        DWORD dwCreationFlags = CREATE_DEFAULT_ERROR_MODE | DETACHED_PROCESS;\n        STARTUPINFO startinfo;\n        PROCESS_INFORMATION procinfo;\n        ZeroMemory(&amp;startinfo, sizeof(startinfo));\n        startinfo.cb = sizeof(startinfo);\n        if (!CreateProcess(NULL, argv[0], NULL, NULL, FALSE, dwCreationFlags, NULL, NULL, &amp;startinfo, &amp;procinfo))\n            MessageBox(0, "CreateProcess() failed :(", "", 0);\n    }\n    exit(0);\n}\n</code></pre>\n\n<p>I compiled it with cygwin\'s gcc - YMMV with MSVC.</p>\n\n<p>The second problem is that when run from Explorer, your program will for a split second\ndisplay a console window. There\'s no programmatic way around this because the console is\ncreated by Windows when the app is launched, before it starts executing. The only thing you can\ndo is, in your installer, make the shortcut to your program with a "show command" of\nSW_HIDE (ie. 0). This will only affect the console unless you deliberately honour the wShowWindow field of STARTUPINFO\nin your program, so don\'t do that.</p>\n\n<p>I\'ve tested this by hacking cygwin\'s "mkshortcut.exe". How you accomplish\nit in your install program of choice is up to you.</p>\n\n<p>The user can still of course run your program by finding the executable in Explorer and\ndouble-clicking it, bypassing the console-hiding shortcut and seeing the brief black flash of a console window. There\'s nothing you can do about it.</p>\n'}, {'answer_id': 1098259, 'author': 'gabeiscoding', 'author_id': 68535, 'author_profile': 'https://Stackoverflow.com/users/68535', 'pm_score': 2, 'selected': False, 'text': '<p>I know my answer is coming in late, but I think the preferred technique for the situation here is the ".com" and ".exe" method. </p>\n\n<p>This may be considered "cheating" by your definition of two executables, but it requires very little change on the programmers part and can be done one and forgot about. Also this solution does not have the disadvantages of Hugh\'s solution where you have a console windows displayed for a split second.</p>\n\n<p>In windows from the command line, if you run a program and don\'t specify an extension, the order of precedence in locating the executable will prefer a .com over a .exe.</p>\n\n<p>Then you can use tricks to have that ".com" be a proxy for the stdin/stdout/stderr and launch the same-named .exe file. This give the behavior of allowing the program to preform in a command line mode when called form a console (potentially only when certain command line args are detected) while still being able to launch as a GUI application free of a console.</p>\n\n<p>There are various articles describing this like "How to make an application as both GUI and Console application?" (see references in link below).</p>\n\n<p>I hosted a project called <a href="http://code.google.com/p/dualsubsystem/" rel="nofollow noreferrer" title="dualsubsystem">dualsubsystem on google code</a> that updates an old codeguru solution of this technique and provides the source code and working example binaries.</p>\n\n<p>I hope that is helpful!</p>\n'}, {'answer_id': 26087606, 'author': 'Dmitry Markin', 'author_id': 1675481, 'author_profile': 'https://Stackoverflow.com/users/1675481', 'pm_score': 4, 'selected': False, 'text': '<p>You can use <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms681944(v=vs.85).aspx" rel="noreferrer"><code>AllocConsole()</code></a> WinApi function to allocate a console for GUI application. You can also try attaching to a console of a parent process with <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms681952(v=vs.85).aspx" rel="noreferrer"><code>AttachConsole()</code></a>, this makes sense if it already has one. The complete code with redirecting <code>stdout</code> and <code>stderr</code> to this console will be like this:</p>\n\n<pre><code>if(AttachConsole(ATTACH_PARENT_PROCESS) || AllocConsole()){\n    freopen("CONOUT$", "w", stdout);\n    freopen("CONOUT$", "w", stderr);\n}\n</code></pre>\n\n<p>I found this approach in the <a href="https://www.pidgin.im/" rel="noreferrer">Pidgin</a> sources (see <code>WinMain()</code> in pidgin/win32/winpidgin.c)</p>\n'}]
['https://Stackoverflow.com/questions/54536', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/5429/']