Very minor point: Windows applications only come with a message queue if you explicitly start one, so if you have a headless application it needs to have an invisible "window". However I agree with the author that it is a pretty nice API in general. There are some problems caused by the very limited parameter size, but it's a standard notification API for asynchronous OS events. We use it headlessly for detecting USB insertions.
And doesn't Windows have that weird distinction that every exe is either a console application or a GUI application but not both? Makes it hard to get stderr out of GUIs
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.
Yes, but after the program is started you can do anything. AFAIK the important part of the distinction is the behavior when starting the program - if you start a GUI program from the console (Ex. calc), cmd doesn't wait for it to exit. And if you start a console program from Explorer, a cmd window will pop-up (you can hide it, but it will still flicker briefly).
