l0ng-ai
fa3d777c29
Release and nightly now build the desktop app for aarch64-pc-windows-msvc alongside x64, publishing tty7-<version>-windows-arm64-setup.exe and tty7-<version>-windows-arm64.zip. - Cross-compiled on the x64 Windows runner, like server-windows' ARM64 leg, and marked experimental until it has shipped once: a failure drops the ARM64 packages instead of holding up the release. - Vendors Microsoft's arm64 ConPTY pair from the same package version as the x64 one, so ARM64 panes keep the OSC 11 fix (#345). - Each Windows package bundles the WSL server for its own architecture. - The installer's architecture comes in as a define: x64compatible for the x64 build (still installable on ARM64 under emulation), arm64 for the native one. One AppId, so either upgrades the other. - The in-app updater on an ARM64 build asks for the arm64 packages; an x64 build under emulation keeps taking x64 ones. Claude-Session: https://claude.ai/code/session_011mDkkQhwx4RJJBHee3yVpq
2.8 KiB
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
Copy-Item conpty-pkg/runtimes/win-arm64/native/conpty.dll arm64/conpty.dll
Copy-Item conpty-pkg/build/native/runtimes/arm64/OpenConsole.exe arm64/OpenConsole.exe
x64/ and arm64/ match the two released Windows targets
(x86_64-pc-windows-msvc, aarch64-pc-windows-msvc). The package also carries
x86; adding an architecture means adding the directory here, one arm in
build.rs, and one entry in .github/scripts/bundle-windows.ps1's $ConptyArch.