[System.Reflection.Assembly]::LoadFile($pwshExe) will throw for pwsh.exe because it’s not a managed assembly in typical builds; this will fail the test before the fallback logic runs. Wrap this in try/catch (e.g., BadImageFormatException) and fall back to mt.exe/source-manifest extraction when the load fails.

The fallback path uses Split-Path $PSHOME to locate assets/pwsh.manifest, but $PSHOME points to the built/published output, not the repo root, so this path will almost always be missing and the test will be skipped. Use a repo-relative path (for example based on $PSScriptRoot) or a known build variable instead.

After calling Set-ItResult -Skipped, the test should return to prevent any further execution in the It block (Pester guidance) and to avoid future edits accidentally running assertions after the skip.

AllocateHiddenConsole() now returns true whenever TryAllocConsoleNoWindow() returns true, without verifying that a console was actually allocated/attached. Previously the code validated by checking GetConsoleWindow() after allocation and returned false if it was still zero. To preserve the method’s contract, consider validating console allocation after the NoWindow call and falling back (or returning false) if no console is present.

TryAllocConsoleWithMode treats any HRESULT >= 0 as success and discards the AllocConsoleResult. If the API can succeed while returning NoConsole (for example in Default mode when respecting DETACHED_PROCESS), callers may need to distinguish “API succeeded but no console was allocated” from “console allocated/attached”. Consider returning the AllocConsoleResult (or a richer result type) so call sites can make the right decision.

In EarlyConsoleInit, the Hidden path assumes TryAllocConsoleNoWindow() implies usable console I/O, but doesn’t verify that a console was actually created/attached. If the call returns success while allocating no console, later code that opens CONOUT$/CONIN$ can still fail. Consider verifying allocation (or using the AllocConsoleResult out value) and falling back when no console was created.

The top-level Describe is tagged only as "Feature". CI test runs exclude the 'Feature' tag by default (tools/ci.psm1 sets ExcludeTag to Slow/Feature/Scenario for TagSet=CI), so these tests likely won’t run in CI and won’t protect this change. Consider tagging as CI (or CI + Feature) so the coverage runs in standard CI.

The new code doesn't try restoring the foreground windows before return. Could it be possible that the foreground window focus changes even if GetConsoleWindow returns IntPtr.Zero?

Is the xmlns="urn:schemas-microsoft-com:asm.v3" attribute required for the <application> node? We have the xmlns="urn:schemas-microsoft-com:asm.v1" at the <assembly> node above.

I'd say in this case, we leave -WindowStyle to be handled in its original code path (within SetConsoleMode), and in this method, we only deal with the scenarios where existingConsole == nint.Zero.

I guess this can happen on old Windows when the current process is created by CreateProcess with either the CREATE_NO_WINDOW or DETACHED_PROCESS flag.

Currently (without changes in this PR), when pwsh starts with the DETACHED_PROCESS flag, it silently crashes because it uses the stdin/stdout which doesn't exist in that case. I'd say we stick to that behavior to keep the code simple.

However, with the new manifest change, we cannot tell the difference between "it's a normal start and OS doesn't automatically allocate console session for pwsh" and "it's started by CreateProcess with DETACHED_PROCESS flag". For the latter case, on build 26100 or later, we will end up creating a console session if -WindowStyle hidden is specified, but no console session is created otherwise (TryAllocConsoleDefault will respect DETACHED_PROCESS), which seems inconsistent.

we cannot tell the difference between "it's a normal start and OS doesn't automatically allocate console session for pwsh" and "it's started by CreateProcess with DETACHED_PROCESS flag".

That's what AllocConsoleWithOptions(... DEFAULT ...) does. It gives you a console if you were started in a way where you would have gotten a console on previous versions, and it does not give you a console if you were started DETACHED.

e.g. AllocConsoleWithOptions literally lets you detect whether "earlier versions of windows" would have given you a console.

When EarlyCheckForHiddenWindowStyle(args) returns true, ideally, we only want to call AllocConsoleWithOptions(No_Window) if the currently process starts normally (not by CreateProcess with DETACHED_PROCESS). But if we need to call AllocConsoleWithOptions(Default) to determine if it's a "DETACHED_PROCESS" situation, the Console Window would already show up in the normal startup case and there will be no point to call AllocConsoleWithOptions(No_Window), right?

Ah, I see what you mean. Yes, AllocConsoleWithOptions(... NO_WINDOW ...) will create a console session if the parent requested a detached session.

However: I think that fulfills the contract just fine. The user gave conflicting information: "Spawn powershell with no console and a hidden console window"? The ambiguity should resolve in favor of the thing-hosted-within-PowerShell having access to console APIs.

(In my opinion, somebody calling CreateProcess("powershell", ... DETACHED_PROCESS) who chooses to pass -WindowStyle is only harming themselves. They chose this. They did that.)

Can we check on the build number of Windows here to simply do nothing for build prior to 26100? Let PowerShell fall back to the original code path for WindowStyle handling on old Windows.

Version checks are always the wrong choice.

APIs can be backported--and this one very nearly was!--to earlier versions. The only correct way to handle this is to check whether it is available either by calling it and having it fail or by looking it up at runtime.

@DHowett If the process is started by CreateProcess with the CREATE_NO_WINDOW flag, it may inherit the existing console session but have no console window created for it, right?

If so, existingConsole would be nint.Zero in that case, and we will call AllocConsoleWithOptions in the new code path. I guess AllocConsoleWithOptions(Default) will return that existing console session, but what will AllocConsoleWithOptions(No_Window) do in that case?