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

[DHowett]

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]

/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

[zadjii-msft]

Markdown view link

[DHowett]

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]

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]

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]

@KalleOlaviNiemitalo section: interaction with existing APIs

[zadjii-msft]

surely no sense in blocking this anymore 😅

[KalleOlaviNiemitalo]

Was this implemented and merged in Windows already?

[jantari]

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]

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]

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]

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]

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]

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]

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]

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.

[lhecker]

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?

[alabuzhev]

• 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)

[lhecker]

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).