microsoft / microsoft/terminal
Add app-specific configuration for DefTerm handoff
- Dominant language
- C++
- Stars
- 105k
- Forks
- 9.6k
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 29
Description
In chatting with @awakecoding on Twitter, I realized that we may be able to add support for application-specific handoff configuration without servicing Windows.
When OpenConsole receives a handoff request in `ConsoleEstablishHandoff`...
https://github.com/microsoft/terminal/blob/7e47f6aab96b0f2d01309bc05cebe1c57b44a127/src/host/srvinit.cpp#L404-L424
... there's a decision point after it's read the `CONNECT` packet but before it yeets a PTY connection into Terminal ...
https://github.com/microsoft/terminal/blob/7e47f6aab96b0f2d01309bc05cebe1c57b44a127/src/host/srvinit.cpp#L566-L567
... where we can figure out which application is connecting and look up settings in the old conhost way using `RegistrySerialization` (et al) (`HKCU\Console\C:_Path_To_Whatever.exe` or reading the `LNK` file).
Returning an error from `ConsoleEstablishHandoff` (or earlier, in `CConsoleConnection`) will trigger conhost's recovery/fallback mode that hosts console applications locally.
That _should_ enable us to make a late-binding decision in OpenConsole (part of the Terminal package) on whether to continue with handoff.
### Risks
This works on the assumption that we can read the same connect packet multiple times; I believe we can, as conhost _already_ read it to figure out `wShowWindow`.
This will "waste" a megabyte of memory and a process creation on startup as OpenConsole must load and, if it determines _not_ to hand off, exit before the client application gets hooked up to the original conhost.
### Thoughts
Interesting thought exercise: OpenConsole could instead choose to host the connection itself. It would provide the same guarantees as conhost (one top-level window, owned by the process) while offering all of the console API, VT and behavioral updates we've made in the past few years that haven't yet trickled out in Windows updates. Folks who have been on the team for a while will recognize this as the effort I used to call "conhost coast to coast"¹.
¹ (we originally planned on moving just conhost to a package and updating it via the store, before Terminal was approved!)
Contributor guide
Research direction
Start in src/host/srvinit.cpp at ConsoleEstablishHandoff and the cited handoff decision point, then trace CConsoleConnection and RegistrySerialization. Determine whether the CONNECT packet can be read again and how existing conhost configuration is resolved. Done requires an agreed implementation of application-specific handoff with conhost fallback, but the issue does not name tests or a concrete scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- cli, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100