Add a spec for #7335, "console allocation policy" by DHowett · Pull Request #7337 · microsoft/terminal

DHowett · 2020-08-18T20:33:21Z

This is a specification for a way to customize console allocations.
The new manifest type consoleAllocationPolicy and the new
AllocConsoleWithOptions API were already added to the console
client library internally.

Closes #7335

DHowett · 2020-08-18T20:35:42Z

/cc @bpulliam, who was asking for something like this.
/cc @bitcrazed, who might want to see the first evolution of the console subsystem in a while

doc/specs/#7335 - Console Allocation Policy.md

zadjii-msft · 2020-08-18T21:41:44Z

Markdown view link

DHowett · 2020-08-19T05:44:50Z

Thinking about it a bit.. does always make sense? Do we need something inheritOnly for GUI applications so they don't need to AttachConsole? I don't know--i only included always because i wanted there to be more values.

KalleOlaviNiemitalo · 2020-08-19T07:23:20Z

How would these interact with Process Creation Flags CREATE_NEW_CONSOLE, CREATE_NO_WINDOW, or DETACHED_PROCESS? For example, if the parent process has no console and uses CreateProcess CREATE_NEW_CONSOLE and the consoleAllocationPolicy is inheritOnly, then does the child process get a console, and does that depend on the subsystem?

If consoleAllocationPolicy is set but Windows does not recognize the value, is that the same as not setting it? Just wondering how this will be extended in the future if other values are needed. Like dpiAware was extended and later replaced with dpiAwareness.

zadjii-msft

I'm gonna block on behalf of @KalleOlaviNiemitalo, because they raised a good question

DHowett · 2020-08-19T20:10:04Z

How would these interact with Process Creation Flags CREATE_NEW_CONSOLE, CREATE_NO_WINDOW, or DETACHED_PROCESS? For example, if the parent process has no console and uses CreateProcess CREATE_NEW_CONSOLE and the consoleAllocationPolicy is inheritOnly, then does the child process get a console, and does that depend on the subsystem?

Update pending on this.

If consoleAllocationPolicy is set but Windows does not recognize the value, is that the same as not setting it? Just wondering how this will be extended in the future if other values are needed. Like dpiAware was extended and later replaced with dpiAwareness.

This is covered in the Compatibility section. Applications will act the same way they always have contingent upon their subsystem on older versions of Windows.

DHowett · 2020-08-19T20:26:19Z

@KalleOlaviNiemitalo section: interaction with existing APIs

doc/specs/#7335 - Console Allocation Policy.md

zadjii-msft

surely no sense in blocking this anymore 😅

KalleOlaviNiemitalo · 2024-02-07T12:43:45Z

Was this implemented and merged in Windows already?

jantari · 2024-02-07T12:54:05Z

If this was already live in Windows with the spec being approved just 10 minutes ago I'd be mighty impressed ;)

That being said, I too have been looking forward to it for a long time.

KalleOlaviNiemitalo · 2024-02-07T13:15:05Z

Well there was a commit message referencing "the final shape of the API", which gives me the impression that this thing might be in the Windows operating system repository already. But even if it were I don't know whether it would be released in Windows 11 or 12 or what.

lhecker · 2024-02-07T13:30:01Z

Blast! Our evil plan is foiled!

@DHowett I've edited your PR description, but I'm holding off on merging it just in case you want to modify it further.

mjr4077au · 2024-03-17T08:39:38Z

In all seriousness (and apologies, I know its annoying to just randomly message on a closed PR like this), but is this something that's likely to make it's way into 24H2, or should it not be expected until 25H2, or later?

I come via PowerShell/PowerShell#3028 as we're all dying for a solution to the ongoing problems with -WindowStyle Hidden limitations for the end users we need to support.

lhecker · 2024-03-18T14:47:22Z

I may be mistaken, but it's probably already in the Beta and Canary insider builds, ever since this update in February: https://blogs.windows.com/windows-insider/2024/02/08/announcing-windows-11-insider-preview-build-26052-canary-and-dev-channels/

sylveon · 2024-03-22T08:54:28Z

Am I correct in assuming that using detached on a GUI subsystem app would mean that it stays attached if launched from CLI but otherwise works as normal? The spec isn't fully clear regarding that scenario.

eryksun · 2024-03-22T11:46:06Z

doc/specs/#7335 - Console Allocation Policy.md

+I am **not** proposing a change in how shells determine whether to wait for an application before returning to a prompt.
+This means that a console subsystem application that intends to primarily present a UI but occasionally print text to a
+console (therefore choosing the **detached** allocation policy) will cause the shell to "hang" and wait for it to
+exit.


I think a shell's default wait for a console app should wait on the child process handle for a second and then, if the child is still running, check GetConsoleProcessList(). If the child process ID is in the list, then continue the wait loop. Alternatively, the console API could provide a WaitForConsoleDetach() function that simplifies this into a single call. It would return as soon as the process either terminates or calls FreeConsole(). Explicit waiting until child process termination would still be possible via something like CMD's start /wait command.

alabuzhev · 2024-08-28T16:45:17Z

doc/specs/#7335 - Console Allocation Policy.md

+
+There's another risk in reattaching, too. Given that the shell decides whether to wait based on the subsystem
+field, GUI subsystem applications that reattach to their owning consoles *just to print some text* end up stomping on
+the output of any shell that doesn't wait for them:


Any chance to address this one as well?

E.g. could a shell guard its console somehow, so that any attempt to AttachConsole(ATTACH_PARENT_PROCESS) from a child IMAGE_SUBSYSTEM_WINDOWS_GUI process would do nothing and return false, as if there is nothing to attach to?

This behavior is annoying, rude, and it happens more and more often.

A shell needs to check if the application is GUI/CUI to determine if it should wait or not for the application to finish right? In that case, why not pass bInheritHandles = FALSE during CreateProcess if it's a CUI application?

That is exactly what we already do

AttachConsole overrides it anyway:

the standard handles retrieved with GetStdHandle will likely be invalid on startup until AttachConsole is called. The exception to this is if the application is launched with handle inheritance by its parent process

CreateProcess(some_gui_process) can be called opaquely from ShellExecuteEx(some_text_file)

Oh, the problem in my test was that my test ""shell"" exited before the GUI application had launched. This caused the AttachConsole call to fail.

The way ATTACH_PARENT_PROCESS works is that it gets the InheritedFromUniqueProcessId value via NT APIs, opens a handle to your process using that PID, and gets the connection HANDLE from your PEB (NtCurrentTeb()->ProcessEnvironmentBlock->ProcessParameters->Reserved2[0]).

Locking the console for new attachments is a little difficult, because on one hand the shell doesn't own the console session, and on another, in a way, there's no difference between AttachConsole and any other attachments. We could solve these issues of course (e.g. by keeping track which process requested no interference and lifting the restriction once that process is gone), but it does seem non-trivial to me. Would you like me to open an issue so we can track this as a backlog task?

Potential solutions in the meantime:

Use PROC_THREAD_ATTRIBUTE_PARENT_PROCESS and pass a handle of explorer.exe. That requires something like Process32First/NextW though which is meh.

Launch a small intermediate process that launches the target GUI application and then immediately exits. This breaks the parent/child relationship and so it can't attach anymore.

Forbid access to your process (not entirely sure what APIs one could use for that).

Add a spec for #7335, "console allocation policy"

4ae3783

DHowett requested review from miniksa and zadjii-msft August 18, 2020 20:33

DHowett added 5 commits August 18, 2020 13:36

Fix header

c3899a6

Don't be silly

e6db2cd

fix links

912c981

Document huge caveat

bb2809d

spellbot

04f9862

DHowett mentioned this pull request Aug 18, 2020

Powershell -WindowStyle Hidden still shows a window briefly PowerShell/PowerShell#3028

Open

miniksa reviewed Aug 18, 2020

View reviewed changes

doc/specs/#7335 - Console Allocation Policy.md Outdated Show resolved Hide resolved

twpol reviewed Aug 18, 2020

View reviewed changes

doc/specs/#7335 - Console Allocation Policy.md Outdated Show resolved Hide resolved

miniksa reviewed Aug 18, 2020

View reviewed changes

doc/specs/#7335 - Console Allocation Policy.md Outdated Show resolved Hide resolved

fix table headings

73390fa

This comment has been minimized.

Sign in to view

DHowett added 4 commits August 18, 2020 17:21

minor updates, security section

7ad93c5

clarify table

9c3b922

more reasons not to do a new subsystem

774a168

fine spellbot i got rid of the word malware

7e6a7fb

zadjii-msft requested changes Aug 19, 2020

View reviewed changes

ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 19, 2020

zadjii-msft assigned DHowett Aug 19, 2020

ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 19, 2020

Clarify interaction with createprocess

a8e6c1f

flags->mode and flags

ef0c8a6

This comment has been minimized.

Sign in to view

KalleOlaviNiemitalo reviewed Dec 14, 2023

View reviewed changes

doc/specs/#7335 - Console Allocation Policy.md Outdated Show resolved Hide resolved

Slight clarification, rewording

6ba31b8

This comment has been minimized.

Sign in to view

lhecker approved these changes Dec 15, 2023

View reviewed changes

Update for the new API name

0720331

This comment has been minimized.

Sign in to view

Check in the final shape of the API and the windowsSettings year

2b6505c

This comment has been minimized.

Sign in to view

speelbot

4e3f440

mklement0 mentioned this pull request Jan 28, 2024

Exiting pwsh kills the process that was started with Start-Process PowerShell/PowerShell#21149

Closed

5 tasks

zadjii-msft approved these changes Feb 7, 2024

View reviewed changes

microsoft-github-policy-service bot added Issue-Scenario Product-Meta The product is the management of the products. labels Feb 7, 2024

DHowett merged commit 71c35cf into main Feb 7, 2024

DHowett deleted the dev/duhowett/spec/console-allocation branch February 7, 2024 13:48

eryksun reviewed Mar 22, 2024

View reviewed changes

mjr4077au mentioned this pull request May 5, 2024

conhost.exe --headless doesn't exit with the child process's exit code. #17178

Closed

alabuzhev reviewed Aug 28, 2024

View reviewed changes

zadjii-msft mentioned this pull request Sep 5, 2024

WT_WINDOWID available as env variable #17863

Closed

KalleOlaviNiemitalo mentioned this pull request Jun 21, 2025

Working with command line options in Windows Forms doesn't output or return result dotnet/command-line-api#1435

Open

zadjii-msft mentioned this pull request Oct 15, 2025

determine installed version #19450

Closed

Conversation

DHowett commented Aug 18, 2020 • edited by lhecker Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DHowett commented Aug 18, 2020

Uh oh!

Uh oh!

Uh oh!

Uh oh!

zadjii-msft commented Aug 18, 2020

Uh oh!

This comment has been minimized.

This comment has been minimized.

DHowett commented Aug 19, 2020

Uh oh!

KalleOlaviNiemitalo commented Aug 19, 2020

Uh oh!

zadjii-msft left a comment

Choose a reason for hiding this comment

Uh oh!

DHowett commented Aug 19, 2020

Uh oh!

DHowett commented Aug 19, 2020

Uh oh!

This comment has been minimized.

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

zadjii-msft left a comment

Choose a reason for hiding this comment

Uh oh!

KalleOlaviNiemitalo commented Feb 7, 2024

Uh oh!

jantari commented Feb 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KalleOlaviNiemitalo commented Feb 7, 2024

Uh oh!

lhecker commented Feb 7, 2024

Uh oh!

mjr4077au commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lhecker commented Mar 18, 2024

Uh oh!

sylveon commented Mar 22, 2024

Uh oh!

eryksun Mar 22, 2024

Choose a reason for hiding this comment

Uh oh!

alabuzhev Aug 28, 2024

Choose a reason for hiding this comment

Uh oh!

lhecker Aug 28, 2024

Choose a reason for hiding this comment

Uh oh!

alabuzhev Aug 28, 2024

Choose a reason for hiding this comment

Uh oh!

lhecker Aug 28, 2024

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

DHowett commented Aug 18, 2020 •

edited by lhecker

Loading

jantari commented Feb 7, 2024 •

edited

Loading

mjr4077au commented Mar 17, 2024 •

edited

Loading