Starting PowerShell/pwsh with '-WindowStyle hidden' should not flash console window.

[Jawz84]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.17134.228]

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

I am cross-posting this issue from the PowerShell/PowerShell repository.
People are reporting that the console does not respect the -WindowStyle hidden flag. This is unexpected to them.

• Repro1:
  [win]+R then type pwsh -WindowStyle hidden -command 'start-sleep 10'
• Repro2:
  [win]+R then type powershell -WindowStyle hidden -command 'start-sleep 10'
• Repro3:
  Create a scheduled task that reflects one of the command above.

What happens: a pwsh-window is briefly displayed before it is hidden.

• What's wrong / what should be happening instead:

When starting PowerShell/pwsh with the -WindowStyle hidden parameter, no console window should be displayed.

It would be great if somehow before connecting a console window to the PowerShell/pwsh process, this -WindowStyle hidden flag gets checked. (Yes, I read the awesome blog series by @bitcrazed 👍)

[zadjii-msft]

As it's been discussed in the thread you linked, any and all Console Subsystem applications get a console window it they aren't already attached to one, full stop. They need conhost.exe to be able to service console API calls.

What you'd be asking for Windows to not create console windows for any console applications by default, and that's a feature that we're not about to add.

There really isn't a way that a parent process that's calling a commandline could know if that particular commandline intends to be hidden or not. Nor is there a way for a commandline application to manifest itself to say "I would like to be hidden by default".

A caller could pass the wShowWindow member of the STARTUPINFO struct as SW_HIDE during create process to hide the console window, but again, the caller would need to know that the commandline should be run hidden, and there'd be no good way of knowing that.

It's also kind of a pain to have a single pwsh.exe that is a Windows subsystem application that potentially re-attaches to the console it was started from (if -windowstyle hidden were not passed in). If you tried doing that, usually the launching process has returned to the "foreground" of the console, and now you'd have two processes in the foreground, which isn't what you want.

Having two executables (pwsh.exe and pwshw.exe) is really the best way to get that effect for the time being.

I'm going to close this issue for now, and defer to the discussion in the powershell thread. Feel free to reopen if there's a concrete and actionable suggestion that the console team could reasonably implement.

[Jawz84]

Thank you @zadjii-msft for taking the time to write this thorough answer, really appreciated!
Also thanks for all the hard work on console; looking forward to what other amazing things like ConPTY you guys have in store for us!

[ibex-are-goats]

There really isn't a way that a parent process that's calling a commandline could know if that particular commandline intends to be hidden or not.

Do we not have the technology to input a command into a program to cause it to be hidden? Perhaps for example "-hidden"?

[eryksun]

Do we not have the technology to input a command into a program to cause it to be hidden? Perhaps for example "-hidden"?

The initialization code in kernelbase.dll is what allocates the console. This is part of process setup, which necessarily precedes calling the application entry point and parsing the command line. There are 3 creation flags that affect this: CREATE_NEW_CONSOLE, CREATE_NO_WINDOW (i.e. a windowless console), and DETACHED_PROCESS (i.e. no console at all, which may be problematic in some cases, but should be ok if combined with setting unused standard handles to the "NUL" device). These creation flags are ultimately passed to the child as special values of ConsoleHandle in the inherited ProcessParameters. Otherwise this field is normally either the inherited console connection handle or NULL (i.e. the parent has no console to inherit). The parent process can also set STARTF_USESHOWWINDOW and a wShowWindow value such as SW_HIDE in the target STARTUPINFO, which sets WindowFlags and ShowWindowFlags in the inherited ProcessParameters. A newly allocated console receives this information from the connecting client process (i.e. SW_HIDE won't affect an existing, inherited console).

It might be useful to add a creation flag that's similar to CREATE_NO_WINDOW, except it would delay creating a window until the application reads from the console input buffer. This would let generic code (i.e. not special cased per target) in the parent avoid the ugly distraction of command-line utilities that flash a window and exit, but without breaking interactive console applications.

[ibex-are-goats]

And I consider this a high priority feature request because the .vbs script that everyone is using to make powershell work as expected MUST be a huge security risk that defeats part of the purpose of powershell!

[diogocatossiGB]

as a workaround until the feature is implemented (I hope it does) it's possible to wrap the script in a .NET executable using MScholtes PS2EXE project: https://github.com/MScholtes/PS2EXE

[sba923]

I would have expected this very issue to be the place to track the request for a pwshw.exe executable. What did I miss @zadjii-msft?