Repository navigation
Starting PowerShell/pwsh with '-WindowStyle hidden' should not flash console window. #249
Description
-
Your Windows build number: (Type
verat 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]+Rthen typepwsh -WindowStyle hidden -command 'start-sleep 10' - Repro2:
[win]+Rthen typepowershell -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 Rich Turner (@bitcrazed) 👍)
Activity
zadjii-msft commentedon Sep 4, 2018
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
wShowWindowmember of theSTARTUPINFOstruct asSW_HIDEduring 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 hiddenwere 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 commentedon Sep 5, 2018
Thank you Mike Griese (@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 commentedon Oct 11, 2018
Do we not have the technology to input a command into a program to cause it to be hidden? Perhaps for example "-hidden"?
eryksun commentedon Oct 11, 2018
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), andDETACHED_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 ofConsoleHandlein the inheritedProcessParameters. Otherwise this field is normally either the inherited console connection handle orNULL(i.e. the parent has no console to inherit). The parent process can also setSTARTF_USESHOWWINDOWand awShowWindowvalue such asSW_HIDEin the targetSTARTUPINFO, which setsWindowFlagsandShowWindowFlagsin the inheritedProcessParameters. A newly allocated console receives this information from the connecting client process (i.e.SW_HIDEwon'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 commentedon Oct 12, 2018
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 commentedon Oct 22, 2021
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 commentedon Aug 21, 2023
I would have expected this very issue to be the place to track the request for a
pwshw.exeexecutable. What did I miss Mike Griese (@zadjii-msft)?v0.9.1 hot-fix: hidden-console launcher (kb-mcp-svc.exe) for Task Sch…