l0ng-aiandl0ng-ai
3ae340408b
* fix(windows): bundle Microsoft's ConPTY so panes can answer color queries
The in-box conhost swallows a pane process's OSC 11 background query: it
never reaches tty7's emulator and no reply is ever written back, so
applications that choose a light or dark UI from the terminal background
render a dark UI under a light theme.
tty7 already answers OSC 10/11/12 from the live theme, so nothing was
missing but a pseudoconsole that forwards the question. Microsoft ships one
as a redistributable, and portable-pty already prefers a sideloaded
conpty.dll over kernel32's, so this is packaging rather than code: the pair
goes beside tty7-app.exe, where the DLL search path finds it.
Measured on Windows 11 26200, same binary, only the pair added beside it:
in-box conhost: the terminal side never sees the query; the client times
out with no reply
bundled ConPTY: the terminal side sees ESC]11;?BEL and a real pane reads
back rgb:efef/f1f1/f5f5 under catppuccin_latte, which is
the preset's exact background
The two files are one supported unit, so the release verifier fails a
package that carries only one, a mismatched pair, or the MIT notice-less
DLL. They also join PORTABLE_MANAGED_ROOTS, without which the updater would
reject every portable archive that contains them; they are deliberately not
required by verify_portable_payload, since tty7 runs without them and a
packaging slip should fail the release rather than a user's update.
build.rs stages the pair beside cargo's output so a development build does
not quietly run on the in-box host, and the daemon logs which pseudoconsole
it got.
Closes #345
* fix(windows): restage the bundled ConPTY when it goes missing
Watching only the vendored sources meant a staged copy that left the target
directory stayed gone: the build script was cached, so it never ran again to
put it back, and the build silently fell back to the in-box conhost. Cargo
treats a rerun-if-changed path that does not exist as changed, so naming the
destinations makes the staging self-healing.
Found by deleting target/debug/conpty.dll and watching the next build not
bring it back.
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
Bundled ConPTY
Microsoft's redistributable pseudoconsole, shipped beside tty7-app.exe so that
Windows panes do not run on the in-box conhost.exe.
| Version | 1.24.260710001 (file version 1.24.2607.10001) |
| Source | Microsoft.Windows.Console.ConPTY on nuget.org, also a release asset of microsoft/terminal |
| License | MIT — see LICENSE.txt, staged into the package as LICENSE-ConPTY.txt |
Why it is here
The in-box conhost.exe swallows a pane process's OSC 11 background-color
query: the sequence never reaches tty7's emulator and no reply is ever written
back, so applications that pick a light/dark UI from the terminal background
(codex, Neovim's background detection, …) render a dark UI under a light theme.
That is issue #345. The redistributable forwards the query and routes the answer
back to the client, which is all tty7 needs — terminal::view already answers
OSC 10/11/12 from the live theme.
Measured on Windows 11 26200, same binary, only this pair added beside it:
in-box conhost: terminal side sees <ESC>[?9001h<ESC>[?1004h -> client: no reply
sideloaded: terminal side sees ... <ESC>]11;?<BEL> -> client: rgb:efef/f1f1/f5f5
portable-pty prefers a sideloaded conpty.dll over kernel32 on its own
(src/win/psuedocon.rs), so nothing in tty7 loads these files explicitly. They
are found through the ordinary DLL search path, which starts at the directory of
the running executable — which is why they sit beside tty7-app.exe (the daemon
is tty7-app.exe --daemon) rather than in a subdirectory, and why build.rs
copies them next to cargo's output so a development build behaves like a
packaged one.
Updating
Both files are one unit: Microsoft supports the pair, not the halves, and a
mismatched conpty.dll/OpenConsole.exe misbehaves in ways that surface as pty
bugs. Replace both, from the same package version, and update the table above.
$v = '1.24.260710001'
curl.exe -sL -o conpty.zip "https://api.nuget.org/v3-flatcontainer/microsoft.windows.console.conpty/$v/microsoft.windows.console.conpty.$v.nupkg"
Expand-Archive conpty.zip -DestinationPath conpty-pkg
Copy-Item conpty-pkg/runtimes/win-x64/native/conpty.dll x64/conpty.dll
Copy-Item conpty-pkg/build/native/runtimes/x64/OpenConsole.exe x64/OpenConsole.exe
Only x86_64-pc-windows-msvc is released today, so only x64/ is vendored. The
package also carries arm64 and x86; adding an architecture means adding the
directory here and one Copy-Item in .github/scripts/bundle-windows.ps1.