3 Commits

Include renames

Author	SHA1	Message	Date
l0ng-ai	a645fd33f5	fix(windows): link the Visual C++ runtime statically (#902) ... Every Windows binary tty7 has ever shipped imports `VCRUNTIME140.dll`. That file is not part of Windows; it arrives with the "Visual C++ 2015-2022 Redistributable", which Visual Studio, the GitHub runners and most developer machines install as a side effect of something else. On a machine that has never installed it the loader fails before `main` — no window, no log, no crash report, just The code execution cannot proceed because VCRUNTIME140.dll was not found. which is how 26.8.2 failed winget's install validation (microsoft/winget-pkgs#415841). Confirmed against the installed 26.x `tty7-app.exe` with `dumpbin /dependents`: `VCRUNTIME140.dll` plus nine `api-ms-win-crt-*` entries, and the same in `tty7.exe` and `tty7-updater.exe`. The UCRT half is in-box from Windows 10 on and never was the problem; VCRUNTIME140 is the one piece that has to come from the redistributable. The bundled ConPTY pair is already CRT-static, so it was never implicated — only our own three binaries are. `-C target-feature=+crt-static` for the MSVC targets, in `.cargo/config.toml` rather than in the release workflow, so CI's Windows `build & test` job compiles under the same flag a release does and a dependency that cannot link statically fails a pull request instead of a tag. The alternative — declaring `Microsoft.VCRedist.2015+.x64` in the winget manifest, or shipping the DLLs beside the exe — was rejected: it leaves the portable zip, the GitHub release and every non-winget install path broken, this repository publishes no winget manifest to carry the declaration, and the winget PR shows the declared dependency did not actually resolve the failure. Static linking removes the requirement instead of documenting it. The regression is invisible to everyone who could catch it, because every machine that builds tty7 has the redistributable, so `assert-no-vcruntime.ps1` reads the PE import and delay-load tables directly (no `dumpbin`, which would re-introduce the same "my machine has Visual Studio" assumption) and fails on any VC++ redistributable import. It runs in CI on the Windows debug build and, via `verify-windows-package.ps1`, over both shipped payloads in release and nightly. Verified on Windows 11 x86_64 with MSVC 14.44: a full `cargo build --release --locked --target x86_64-pc-windows-msvc` links cleanly, and `dumpbin /dependents` on the resulting `tty7-app.exe` shows 29 imports, all in-box — no `VCRUNTIME140.dll` and no `api-ms-win-crt-*` at all. Same for `tty7.exe` and the `--features updater` `tty7-updater.exe`. `cargo test --release -p tty7-core` under the flag: 1223 passed, 4 failed, those four being the `remote_link`/`router` tests that fail on a clean tree on this machine too. Fixes #902 Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM	2026-09-21 22:44:15 +08:00
l0ng-aiandl0ng-ai	3ae340408b	fix(windows): bundle Microsoft's ConPTY so panes can answer color queries (#360) ... * 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>	2026-08-06 11:36:02 +08:00
3 people	603bca171e	feat(updater): add windows updates and cross-platform nightly support (#330) ... * feat(updater): add windows online updates * feat(updater): support online updates for windows portable zip builds f * feat(updater): support online updates for nightly build * fix(updater): strengthen post-download update verification * feat(updater): support explicit stable and nightly channel switching * fix(i18n): localize update settings ui * fix(settings): prevent slider value labels from wrapping * feat(updater): drop the nightly channel, refuse all-users Windows installs Follow-up to the Windows updater work on this branch, applying maintainer review. Nightly is a build channel, not an update channel. The updater consults `/releases/latest` again and nothing else, so it behaves on Windows exactly as it already does on macOS: a Nightly build is offered the stable release that supersedes it and graduates out of the prerelease, and no rolling prerelease can become a source of code that gets executed on a user's machine. Removed with it: the `UpdateChannel` enum and its version-string inference, the `tags/nightly` query, the cross-channel version-ordering bypass, the Settings → About channel row, the rolling-tag `update-manifest.json` and the i18n keys that only served them. `parse_version` and `is_update_available` are byte-identical to main again. Nightly builds are untouched, and still carry tty7-updater plus the macOS update archive — a Nightly user needs a working helper to reach the stable release that replaces their build. An all-users Windows installation is no longer updated in place. Running the release Setup silently as the signed-in user cannot replace `C:\Program Files\tty7`: Inno resolves `{autopf}` to `%LocalAppData%\Programs` and installs a second copy beside the real one, or re-launches itself elevated and puts a bare UAC prompt for an unsigned executable in `%TEMP%` in front of a user whose GUI just vanished. tty7 declines both and points at the release page. Detection reads Inno's own `HKLM` state for the frozen AppId and independently probes whether the directory accepts writes, so a relocated or pruned installation is caught too; the decision is a pure function with unit tests, and it is re-checked before the download as well as during it. Release and Nightly now verify the Windows packages they just built, mirroring the macOS update-archive step: the install marker, tty7-updater.exe, the ZIP layout the updater will accept and the PE versions it will demand. Every fact the updater checks on the user's machine after downloading is checked here instead, so a packaging mistake fails the build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 10:27:37 +08:00