Test the actual Windows release executable on Windows. A successful macOS build or cross-compile does not verify Windows keyboard input, rendering, accessibility, or window behavior.
Use Windows 11 Arm in Parallels Desktop, with a Parallels version that supports your host macOS. Parallels provides a Windows installation assistant and virtualized graphics. Windows licensing is separate.
Windows 11 Arm can run x64 applications through emulation, so you can test the same x64 executable distributed by Programa. This is useful for local iteration; also verify releases on an x64 Windows PC before claiming native x64 hardware coverage.
Sources: Parallels Windows 11 guide, Microsoft x64 emulation documentation.
UTM is another VM option, but validate its Windows graphics support before using it as a UI test environment. Its newer Triton graphics work is evolving; a VM without a working accelerated graphics stack is a poor reference for terminal rendering or latency. See the UTM graphics development notes.
- For unreleased changes, download the Windows artifact from the relevant GitHub Actions run. Use the build from the commit under review.
- For a published release, download
programa-windows.exefrom the rolling release. - Copy it into the Windows VM and run it there. Record the release version, build number, commit, Windows version, CPU architecture, graphics driver, and display scaling with the test results.
- Keep a Windows terminal open to capture diagnostic output when a launch or shell session fails. Use the same executable for every comparison.
The WinUI build bundles the Windows App SDK, .NET runtime, and Rust libraries.
Test the single downloaded EXE in a fresh folder on a clean Windows VM, with
no developer runtime or adjacent DLLs. Check first-launch extraction, a second
launch, and --version/--verify-native-libraries before testing the UI.
Also run programa-windows.exe --smoke, which drives the real WinUI startup
(window creation, resource loading, one terminal spawn) the same way CI's
windows-build job does and exits non-zero on failure -- this is the
closest automated proxy to "does a window actually appear," and it is worth
running on a clean machine even though CI already runs it on windows-latest.
If any of these fail, or if the app produces no window with no error, read
%LOCALAPPDATA%\Programa\launch.log, which records every launch attempt and
its outcome, success or failure.
The rolling aliases are programa-macos.dmg and programa-windows.exe.
Retained candidate releases contain the build-specific filenames, allowing
the exact tested bytes to be recovered after rolling advances.
| Area | Check |
|---|---|
| Window frame | Alt+Space system menu, minimize/maximize/restore/close, caption double-click, resize borders, Windows 11 snap layouts, taskbar and Alt+Tab |
| Displays | 100%, 125%, 150%, and 200% scaling; move between monitors with different scaling; reconnect a display |
| Tabs | Create, select, close, reorder first/middle/last, cancel a drag, reject another workspace's drop, preserve the terminal session and split layout |
| Splits | Create both orientations, resize, focus each pane, preserve terminal dimensions and input routing |
| Keyboard | Windows shortcuts, terminal Ctrl+C/D/W, navigation keys, function keys, US and AltGr layouts; no interception of Windows-reserved shortcuts |
| Text input | Japanese/Chinese/Korean IME composition, candidate placement, committed text, dead keys, accents, emoji, wide and combining characters |
| Clipboard | Selection, copy, paste, multiline paste, bracketed paste, context menu, clipboard sharing with the Mac |
| Appearance | Windows light/dark mode, contrast themes, readable selection/cursor, font fallback, theme changes while running |
| Accessibility | Keyboard-only navigation, visible focus, Narrator labels and terminal text, selection/cursor announcements, usable control sizes |
| Lifecycle | Shell startup failure, normal shell exit, app close with live sessions, repeated tab open/close, no orphaned child processes |
Use Accessibility Insights for Windows and Narrator alongside manual input checks. Microsoft's accessibility testing guidance describes the relevant tools and test methods.
GitHub Actions should build the executable and run Windows unit/integration tests. Release tests must reject missing platform assets, mismatched versions or commits, and aliases whose bytes differ from their build-specific payloads. Interactive checks above need a Windows desktop session; passing a headless build does not establish UI parity or accessibility compliance.
Record actual results and unresolved failures. Do not mark a check as passed because the underlying UI framework supports it: Programa must connect and exercise that behavior itself.
Windows CI (the windows-build job) builds the executable and runs the Rust tests, including a
real ConPTY lifecycle and the focused terminal read regression, the managed tests, WinUI
compilation and single-file publishing, the exact version check, --smoke, and extraction and
loading of both native libraries. The stable and build-numbered EXEs in a build are byte-identical.
The EXE is unsigned; no Windows publisher-signing certificate is configured.
No CI job launches the desktop UI. GPU rendering, drag behavior, IME, Narrator, and clean-machine deployment need the interactive checks above. Full macOS feature parity remains incomplete; the macOS app does not use the shared core.