CLI apps don't start in Windows Terminal when started minimized

[dapetcu21]

Description of the new feature/enhancement

I have Windows Terminal set as my Default terminal application and New instance behavior set to "Attach to the most recently used window". We have a tool that starts many console processes at the same time. It does so using System.Diagnostics.Process.Start(). We'd like for these processes to be started in the background as to not steal the focus from the foreground window. I noticed that if I start the processes with ProcessStartInfo.WindowsStyle == ProcessWindowStyle.Minimized, the console windows will start minimized, but they won't attach as a tab to Windows Terminal. They will just start as windows of their own. Can we have Windows Terminal handle this situation too?

[zadjii-msft]

You know, this was always by design. There's a bunch of heuristics built in to the Default Terminal handoff to try and ID a console app that "didn't wand a console window" - minimized is one of those things.

Maybe now, in the post-1.18 world where we have tear-out, we can allow for minimized defterm windows. We could just always pop the minimized defterm connection into a new window that's minimized. If someone wants to re-attach it, they always could restore it then re-attach it later.

xlinking a note from #13838

This doesn't do the same for defterm-initiated connections. This is because we don't need to! Defterm very explicitly rejects handoff for minimized console apps. This is probably for the best! I put an attempt in 66f8b25 before I forgot that it was filtered long before the Terminal. NOT doing this for /min saves us all sorts of "what happens if start /min cmd tries to glom?" or "what if someone does start /min cmd && start /max cmd and they glom together?".

[zadjii-msft]

Alrighty, so we ended up talking this over as a team. There's definitely something that theoretically could be done here. We could change the OS-side defterm handoff to still attempt the handoff even for applications that requested they be run minimized. This would require an OS-side code change¹ (since that logic happens in the inbox conhost, before the delegation console is ever invoked). We'd then also change the Terminal to be able to determine if it wants to accept a minimized handoff or not. By rev'ing the defterm interface, we could probably make sure that older terminal versions running on newer Windows builds didn't do this accidentally.

We however decided ultimately that we probably shouldn't do this. The defterm handoff itself is kinda expensive on the CPU side. The process of looking up the COM object that's registered for the handoff, and doing that handoff, is non-trivial. We've already seen some perf measures be impacted by defterm when they're trying to launch consoles that aren't hidden/minimized. This would basically then also extend that perf hit even to the minimized console sessions. And that's just not something we're gonna feel comfortable with right now 😕

Perhaps in a future Windows release, we'll further rev the defterm interface more than this. It does feel a little peculiar at this time that the OS launches a conhost, just for that conhost to hand off to a second "conhost", who then hands off to the Terminal. That aforementioned perf hit is something we do really want to address, but it isn't something immediately in the cards for now. We'll probably revisit this (defterm for minimized consoles) in the future.

In the meantime, if you (or other future readers) have some solid business justification we can use to help prioritize this scenario, feel free to share it in the comments below. We can always reopen things for shifting priorities.

Thanks!

Footnotes

1. I believe this also means we can't do it in a Moment, we have to wait for a whole OS swap. Those are less frequent. ↩