diff --git a/docs/WINDOWS.md b/docs/WINDOWS.md index 37ca748..9cb8346 100644 --- a/docs/WINDOWS.md +++ b/docs/WINDOWS.md @@ -1,19 +1,28 @@ # PeerSpeak on Windows -Current status: the Windows port cross-compiles to `x86_64-pc-windows-gnu` and the `.exe` -launches under Wine. A real Windows/WASAPI host is still needed for the final audio-device -checks listed below. +Current status: PeerSpeak cross-compiles to `x86_64-pc-windows-gnu` from Linux and +has passed an older native Windows 11 VM smoke test for launch, GUI render, call +join, and audio flow. The build environment is **not** the Windows VM; current +Windows binaries are built from Linux, normally inside the `peerspeak-win` +distrobox or with the same GNU target environment. + +The Windows runtime still trails Linux in a few important areas. See the Claude +handoff file `windows-parity-audit.md` for the full audit and task breakdown. ## What works today | Area | Status | |---|---| -| GUI | Iced/wgpu builds and renders under Wine. | -| Networking | Iroh QUIC transport and gossip compile on Windows. | +| GUI | Iced/wgpu builds for Windows and rendered in the Windows 11 VM. | +| Networking | Iroh QUIC transport and gossip compile on Windows; VM call reached two peers. | | Audio backend | `cpal` drives WASAPI capture/playback behind `AudioBackend`. | +| Device selection | cpal enumerates input/output devices; see caveat below about stable IDs. | +| Resampling/remap | WASAPI devices can run non-48 kHz formats; PeerSpeak converts at the backend boundary. | | Codec | Opus remains 48 kHz mono, 20 ms frames. | -| Identity | `ring` identity generation/load is platform-neutral. | +| Identity/config | Stored through `dirs` under the Windows profile. | | Chimes | Windows uses PowerShell `System.Media.SoundPlayer` for WAV playback. | +| Game detection | Steam registry `RunningAppID` plus Toolhelp process-scan fallback compile on Windows. | +| File dialogs | `rfd` uses the native Win32 dialog backend. | Windows paths are resolved through `dirs`: @@ -23,55 +32,72 @@ Windows paths are resolved through `dirs`: ## Building -### Native Windows +### Cross-compile from Linux -Install MSVC Build Tools and CMake, then build normally: +Preferred local path: -```powershell -cargo build --release +```sh +distrobox enter peerspeak-win -- bash -lc ' + cd ~/git/butter/peerspeak && + RUSTC_BOOTSTRAP=1 ./win-cross-build.sh -Z build-std=std,panic_abort +' ``` -If CMake is 4.x or newer, the vendored `opus`/`libopus` build may need: +Equivalent direct command when the host has the GNU target, MinGW, `rust-src`, and +CMake available: + +```sh +CMAKE_POLICY_VERSION_MINIMUM=3.5 RUSTC_BOOTSTRAP=1 \ + cargo build --release --target x86_64-pc-windows-gnu --bin peerspeak \ + -Z build-std=std,panic_abort +``` + +`CMAKE_POLICY_VERSION_MINIMUM=3.5` is required with host CMake 4.x because the +vendored Opus build used by `audiopus_sys` still declares an old minimum CMake +version. Without that env var, the Windows build/check fails during Opus configure. + +### Native Windows + +A native MSVC build is not the active development path. If used, install MSVC Build +Tools and CMake, then build normally: ```powershell $env:CMAKE_POLICY_VERSION_MINIMUM = "3.5" cargo build --release ``` -### Cross-compile from Linux - -The current dev path cross-compiles from an Arch environment to the GNU Windows target: - -```sh -rustup target add x86_64-pc-windows-gnu -sudo pacman -S mingw-w64-gcc cmake -CMAKE_POLICY_VERSION_MINIMUM=3.5 cargo build --release --target x86_64-pc-windows-gnu --bin peerspeak -``` - -Wine is useful for launch/render smoke tests, but it is not a substitute for a real -Windows audio-device pass. The deeper migration plan (phases, decisions, the opus build -spike) lives in the maintainer's handoff docs, outside the repo. - ## First run and networking -Expect a Windows Firewall prompt the first time the app opens network sockets. Allow it: -PeerSpeak uses UDP for QUIC, plus relay traffic when direct NAT traversal is not available. +Expect a Windows Firewall prompt the first time the app opens network sockets, or +use the Inno installer option that pre-adds a firewall allow rule. PeerSpeak uses +UDP for QUIC plus relay traffic when direct NAT traversal is unavailable. -The default network mode keeps the n0 relay available for NAT traversal without publishing -presence to n0 DNS. Direct peer-to-peer paths may work when both networks allow them; relayed -connections are expected and valid. +The default network mode keeps the n0 relay available for NAT traversal without +publishing presence to n0 DNS. Relayed connections are expected and valid. ## Known gaps | Item | Status | |---|---| -| Echo cancellation | Linux-only PipeWire feature. The Windows UI shows it disabled as unavailable. | -| Screen share | Requires a Windows `pixelpass.exe` on `PATH` or a configured override. | -| Chimes | Now routed through Windows `SoundPlayer`; needs a real Windows host to audibly verify. | -| Resampling/device format | Cross-compiled. cpal/WASAPI now chooses native 48 kHz when available and otherwise resamples/remaps at the device boundary; needs real Windows hardware audio verification. | -| Device persistence | Open. WASAPI friendly names may duplicate or change across driver/profile changes. | -| Playback pacing | Cross-compiled. The fixed playback target under WASAPI shared mode still needs real-hardware verification with `audio_probe`. | +| Echo cancellation | Linux-only today. The Windows UI shows it disabled as unavailable. | +| Screen share | Blocked by PixelPass, which is currently Linux-only in practice. PeerSpeak can spawn `pixelpass.exe`, but there is no Windows PixelPass host/viewer parity yet. | +| Device persistence | Uses cpal friendly names as keys. These can duplicate or change across Windows driver/profile changes; stable WASAPI endpoint IDs are still needed. | +| Release hygiene | Keep `.iss` and installer output in sync with `Cargo.toml`; rebuild Windows artifacts during each release. | +| Runtime coverage | The Windows VM smoke test proved an older tester build. Current `main` needs a fresh VM smoke matrix before calling parity current. | -Before calling Windows support done, verify a real Windows machine can create/join a room, -capture mic audio, hear remote audio, select devices, restart with selections preserved, and -play notification chimes. +## Current smoke checklist + +Before calling a Windows build current, verify on the Windows VM or real Windows +hardware: + +- Launch current `peerspeak.exe`; GUI renders and settings open. +- Run `audio_probe.exe 440 30`; listen for glitches and inspect `playout-health`. +- Create/join a Linux <-> Windows room; confirm mic and playback both directions. +- Select input/output devices, restart, and confirm selections persist or fall back clearly. +- Play chimes and custom chime paths. +- Send chat, image/file attachments, and save an attachment through the native dialog. +- Import/play/share/listen to music from Windows file paths. +- Record mixed/stems/both and inspect the WAV output path. +- Exercise friends/presence/recents and the clock-skew banner. +- Test Steam and non-Steam game detection on a real Windows Steam install. +- Install/upgrade/uninstall through the Inno installer, including firewall rule cleanup. diff --git a/packaging/PKGBUILD b/packaging/PKGBUILD index 9d714e4..6952315 100644 --- a/packaging/PKGBUILD +++ b/packaging/PKGBUILD @@ -1,7 +1,7 @@ # Maintainer: mollusk pkgname=peerspeak-git _pkgname=peerspeak -pkgver=0.6.1.r310.g660261a +pkgver=0.6.1.r315.ga78860d pkgrel=1 pkgdesc="Decentralized peer-to-peer voice chat (Rust/iroh/PipeWire/Opus/iced)" arch=('x86_64') diff --git a/packaging/windows/INSTALL.md b/packaging/windows/INSTALL.md index 5a5f56d..f24b1d1 100644 --- a/packaging/windows/INSTALL.md +++ b/packaging/windows/INSTALL.md @@ -8,7 +8,7 @@ it once, then you and I connect directly to each other. ## 1. Install it -1. Double-click **`peerspeak-0.4.0-setup.exe`** (the file I sent you). +1. Double-click **`peerspeak--setup.exe`** (the file I sent you). 2. **Windows will probably show a blue "Windows protected your PC" warning.** This is normal — it shows up for any app that isn't from a big company with a diff --git a/packaging/windows/README.md b/packaging/windows/README.md index cef8ce9..eb3cab5 100644 --- a/packaging/windows/README.md +++ b/packaging/windows/README.md @@ -11,8 +11,9 @@ runtime, so there are no extra DLLs to bundle. The installer payload is just the ## Version compatibility -The installer version tracks the crate version in `Cargo.toml` (currently -**0.4.0**) — keep `MyAppVersion` in `peerspeak.iss` in sync when it changes. +The installer version tracks the release version in `Cargo.toml` — keep +`MyAppVersion` in `peerspeak.iss` in sync when cutting a release. Do not reuse an +old installer filename after a crate-version bump. Per `VERSIONING.md`, a **MINOR** bump in `0.x` is a **breaking wire change**: peers on different MINOR versions can't connect (they fail fast at the diff --git a/src/game/scan.rs b/src/game/scan.rs index 7005ced..37a2fe9 100644 --- a/src/game/scan.rs +++ b/src/game/scan.rs @@ -97,14 +97,12 @@ fn windows_toolhelp_executables() -> Vec { #[cfg(test)] mod tests { - use super::*; - #[cfg(target_os = "linux")] #[test] fn enumerates_at_least_this_process() { // The test runner itself is a process, so /proc enumeration must be // non-empty and include something that normalizes to our own exe basename. - let exes = running_executables(); + let exes = super::running_executables(); assert!( !exes.is_empty(), "expected to see running processes via /proc"