[Bug] A Windows 11 update broke console hiding

[HebaruSan]

Operating System

Windows 11 22H2 or later

CKAN Version

v1.33.3

Game Version

1.12.5

Problem

Multiple users on Discord reported that the terminal window was appearing and not going away on Windows 11 (and the latest one stuck around long enough for us to investigate). Turns out a Windows 11 update broke GUI.Util.HideConsoleWindow by swapping out the default terminal app to one that doesn't support GetConsoleWindow:

• https://support.microsoft.com/en-us/windows/command-prompt-and-windows-powershell-for-windows-11-6453ce98-da91-476f-8651-5c14d5777c20
• https://stackoverflow.com/questions/74384519/hiding-the-new-windows-terminal

Apparently it was deprecated for a while:

https://learn.microsoft.com/en-us/windows/console/getconsolewindow

ckan.exe is built as a console app because it has command line functionality built-in, so Windows insists on opening a terminal for it. Linux has the ability to launch a console app in the background:

CKAN/debian/ckan.desktop

Line 7 in ff291b1

Terminal=false

Steps to reproduce

• Install Windows 11 22H2 or later
• Launch ckan.exe
• The terminal remains visible instead of hiding

Suggestions

• The user on Discord was satisfied with a shortcut that launches the terminal window minimized. Could we do that by default somehow?
• Build separate EXEs for GUI and console? Would be a loss of generality that has served CKAN well for many years. More confusion about what to download.
• Build only the GUI app? Would completely break the metadata validator action and be a big disruption for anyone still using cmdline.
• Build a GUI app that can still read and write from the terminal if launched from one? Don't know if this is possible, would have to investigate.

[jcotton42]

ckan.exe is built as a console app because it has command line functionality built-in, so Windows insists on opening a terminal for it. Linux has the ability to launch a console app in the background

GUI apps can still take CLI parameters. What might work here is P/Invoking AllocConsole if any CLI parameters that require CLI output work, or always if ckan just always needs that console window. I haven't tested this myself though, and I'm not sure if a GUI that does this will still block the console like a CLI-subsystem app would (my guess is it won't by default, but it's definitely possible since VSCode has that --wait parameter).

[HebaruSan]

The problem isn't the arguments, it's needing to use stdin/stdout. Allocating a console doesn't sound like the right thing to do if someone opens a terminal and types "ckan.exe install Astrogator".

[HebaruSan]

FreeConsole might be a drop-in replacement.

• https://learn.microsoft.com/en-us/windows/console/freeconsole
• Terminal window/tab is not closed when console application calls FreeConsole microsoft/terminal#14416
  (fixed issue stating that FreeConsole didn't work in the new terminal at one point)
• Add support for start /B and FreeConsole microsoft/terminal#14544
  (says FreeConsole works in the new terminal)

I tested with the old console on Win10, and it worked as expected, with one benefit over the old HideConsoleWindow approach: If I start a terminal myself and run ckan.exe, my terminal window stays open (because my shell process is still attached to it). But double clicking ckan.exe in explorer results in the window closing shortly after it appears (because no other process was attached).