Every exe is sort-of both - a GUI program can allocate a console window using AllocConsole (https://learn.microsoft.com/en-us/windows/console/allocconso...), and a console program can create a GUI window and open a message loop. The main difference is that a console program is auto-attached to the console of the process that launched it, if any.
I'm not certain what the rules are for what the C library does, but it seems to detect the no-console case on startup and routes stderr to NUL. So printf and friends still do nothing even after allocating a console. I think you can fix around this with something like this, having allocated a console:
The canonical answer seems to be https://devblogs.microsoft.com/oldnewthing/20090101-00/?p=19... : there's a flag in the PE executable header. But as you say, the same APIs are available to both once you're running. So you can have a console application that decides it's going to open some windows.
Isn't the main practical problem also that a console program will forcibly create a console if it doesn't already have one? This is what breaks the approach everyone else uses of "write to stderr under the assumption it will be visible only if the user was prepared for it, without causing clutter otherwise".
It's not a practical problem in practice. The approach everyone else uses is fine, but everybody else is not writing GUI programs for Windows. If you are writing GUI programs for Windows, you print debug output using OutputDebugString and/or to a probably-optional log file.
Comments
Every exe is sort-of both - a GUI program can allocate a console window using AllocConsole (https://learn.microsoft.com/en-us/windows/console/allocconso...), and a console program can create a GUI window and open a message loop. The main difference is that a console program is auto-attached to the console of the process that launched it, if any.
I'm not certain what the rules are for what the C library does, but it seems to detect the no-console case on startup and routes stderr to NUL. So printf and friends still do nothing even after allocating a console. I think you can fix around this with something like this, having allocated a console:
You can probably actually arrange for stdout and stderr to go to STD_OUTPUT_HANDLE and STD_ERROR_HANDLE, if the distinction would matter, but that'd be a bit more hassle (see https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...).The canonical answer seems to be https://devblogs.microsoft.com/oldnewthing/20090101-00/?p=19... : there's a flag in the PE executable header. But as you say, the same APIs are available to both once you're running. So you can have a console application that decides it's going to open some windows.
Isn't the main practical problem also that a console program will forcibly create a console if it doesn't already have one? This is what breaks the approach everyone else uses of "write to stderr under the assumption it will be visible only if the user was prepared for it, without causing clutter otherwise".
It's not a practical problem in practice. The approach everyone else uses is fine, but everybody else is not writing GUI programs for Windows. If you are writing GUI programs for Windows, you print debug output using OutputDebugString and/or to a probably-optional log file.
This is information that I needed for my own work. Thank you for taking the time to share knowledge.