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.