ShowWindow(GetConsoleWindow(), SW_HIDE); does not work with Terminal in Windows 11

[pmaillot]

I develop small applications using C and Win32 libraries. I typically call
ShowWindow(GetConsoleWindow(), SW_HIDE); in my programs so the console/terminal window would become hidden, leaving only the GUI application and its main loop for capturing user events. Only when/if needed, would I show again the console window under certain circumstances, such as fatal errors.
This works/worked great with all instances of Windows (at least XP and W10) but in W11, as now "Terminal" takes over the console host by default, my call to ShowWindow will no longer hide the terminal.

I can ask all users to change the default "Terminal" back to Console Host, but is there another/better way?

Thx,
-Patrick

[lhecker]

The console basically contains your debug/info log right? That's a really clever way to use it.

To give a short background for this change: We're trying to align Windows more closely to how the other major operating systems work when it comes to terminals. If you write to stdout on those platforms the output is simply discarded. The only way to see it is if you attached something to stdout prior to launching the application, like a terminal or an indirection to a file for instance. /SUBSYSTEM:CONSOLE on Windows acts a little bit like setting Terminal=true in a .desktop file under Gnome on Linux: It tells the OS to spawn a terminal for you when the application starts. But stil, there's no way to manipulate that terminal, because crucially it's not owned by the console application. It's simply attached to it. If that wasn't the case, doing a SW_HIDE on Windows Terminal would hide all tabs, even those unrelated to your application.

To circumvent this, I'd say the quick fix is to spawn your application through conhost explicitly. Basically, instead of running app.exe you'd run conhost app.exe. This will create a console window, like it used to do, even if the default terminal isn't conhost. The proper fix in my opinion would be to not abuse the terminal as a cheap ring buffer for text, if I'm entirely honest. 😅 Terminals are kind of pretty heavy applications, relatively speaking, and it would be much cheaper to use your own ring buffer for log output. Once an error occurs and if you want to show the log output you can just spawn a conhost instance or similar and print the entire buffer contents all at once. However given that you said that they're very small applications, I'd understand if that's too complex, given the overall complexity of the application...

[pmaillot]

Thx for your comments/suggestions @lhecker ; Afraid some of them will not be satisfactory for end-users. I will have trouble explaining GUI only users they should launch the GUI app using a command-line script, when all they want to know is where to click.
So far my best option has been to set the default behavior or Terminal to Console Host, which doesn't seem to prevent having different tabs etc.

I hope MS finds a way to 'trace' so to speak the terminal associated with the instance of the app it is attached to, and create a separate, single tab instance of the Terminal app for the launching application, Then a SW_HIDE should gracefully be able to hide that instance of the Terminal app, and not the others that may already exist.

As to "small apps", some of them are above 20000 lines, but some are just a few 100's. :-)

[PankajBhojwani]

Thank you for the feedback! This is a duplicate of #12464, please follow that thread for updates on this issue. (It may not seem like the exact same issue, but the solution is the same for both)

/dup #12464

[microsoft-github-policy-service]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!