[RFC] Standalone Windows installer + tray Manager for OVMS (install / repair / uninstall / update)

[exzile]

Summary

Propose adding a standalone, self-contained Windows installer / uninstaller / repairer plus a tray-based OVMS Manager GUI, so Windows users can install a working, version-matched OVMS stack; run, monitor, and configure it; repair a broken install; and update it — all without manual unzip/env/config steps. This complements (does not replace) the portable ovms.zip.

Reference implementation: PR #4350. The Updates workflow is detailed in #4351.

Motivation

On Windows, OVMS ships only as a portable archive. There is no guided installer, no Apps & Features uninstaller, no repair path, and no update path. Non-expert users must manually unzip, set environment variables, wire up startup, and hand-edit config to serve a model. Because OVMS is a version-matched stack (ovms.exe + OpenVINO runtime + GenAI + tokenizers + Python), mixing DLLs across releases is a frequent failure. This is a real barrier to local/desktop adoption compared to tools like Ollama.

Architecture

Keep the server headless; add a thin Windows UX layer around it:

OVMS-Setup.exe   installs the payload, writes first-run config, registers uninstaller/startup
OVMS.Manager.exe owns the tray icon + GUI; controls start/stop; edits settings; repair/update
ovms.exe         unchanged model server process

• Program files: %LOCALAPPDATA%\Programs\OVMS
• User data: %LOCALAPPDATA%\OVMS (settings.json, models\config.json, logs\, packages\, diagnostics\, runtime.json)
• Per-user, no elevation for the default flow (HKCU). Machine-wide/service mode is a follow-up requiring elevation.

Installer (Inno Setup, build-time-only dependency)

• Installs the existing python_on package as a single version-matched payload — no downloads at install time.
• Modern wizard UI with OpenVINO branding; existing-install detection with a Repair/upgrade vs. Uninstall choice page.
• Apps & Features uninstaller with a 3-way data choice (preserve all / keep models / remove all).
• Repairer: verify required files, restore from a cached pristine package (%LOCALAPPDATA%\OVMS\packages\source), re-run ovms.exe --version.
• Optional PATH entry and start-at-login; Start Menu shortcuts (Open / Start / Stop / Repair / Uninstall).

Manager GUI (.NET WinForms, tray app)

App-shell with a left nav rail and five pages (all responsive; process/HTTP work off the UI thread):

• Dashboard — status/pid, REST endpoint, gRPC, models served, health (GET /v3/models), package variant, runtime mode; Start / Stop / Restart / Open Logs / Open Model Folder; auto-refresh.
• Settings — REST/gRPC ports, bind address, log level/path, model repository (Browse), startup mode, show-tray, start-at-login; atomic save with .bak, restart prompt for command-line-affecting changes, non-local bind warning.
• Logs — tails the server log with auto-scroll, line count, open-folder/clear.
• Advanced — environment info (dirs, versions, effective command line + Copy) and maintenance actions (Repair / Validate / Export Diagnostics bundle).
• Updates (Windows Manager: Updates page and staged package upgrade workflow #4351) — installed vs. latest for Base package / Model Server / GenAI, release-note links, and a validated staged upgrade (download → verify → back up → replace → validate → rollback on failure).

Supporting scripts (packaging/windows/scripts)

configure-ovms, start-ovms/stop-ovms (process or service), set-path, ovms-env, install-service/uninstall-service, validate-install, repair-package, upgrade-package, uninstall-ovms. Atomic JSON writes, runtime ownership via runtime.json, port preflight, local-only default bind.

Non-goals (initial)

• Not turning ovms.exe into a GUI app; not replacing ovms.zip.
• Not mixing arbitrary OpenVINO/GenAI/OVMS DLL versions — the package is the unit of install/upgrade.
• Windows Service mode is scaffolded but requires elevation (follow-up); machine-wide install is a separate mode.
• Updating the Manager app itself, and background/silent auto-update, are follow-ups.

Design doc

Full architecture and phased plan: packaging/windows/OVMS_WINDOWS_INSTALLER_MANAGER_PLAN.md (in PR #4350).

Acceptance criteria

• Fresh per-user install succeeds without elevation; ovms.exe --version works afterward.
• Existing-install detection offers Repair/upgrade vs. Uninstall.
• Uninstall removes program files, PATH/startup entries, and shortcuts; honors the 3-way data choice.
• Repair restores missing files from the cached package and re-validates.
• Manager starts/stops/restarts the server and reflects live health.
• Settings persist atomically with backup; command-line-affecting changes prompt for restart.
• Diagnostics bundle exports settings/logs/versions/runtime state.
• Updates page + staged upgrade behave per Windows Manager: Updates page and staged package upgrade workflow #4351 (with rollback).
• No build artifacts committed; Inno Setup is a build-time-only dependency.

Questions for maintainers

• Is an in-repo Windows installer + manager in scope for model_server, or preferred as a separate companion project?
• Per-user (proposed default) vs. machine-wide as the primary install model?
• Ship both python_on and python_off variants, or one installer that can fetch the other variant?
• Preferred source of truth for release metadata/checksums used by the update checker?

Happy to adjust scope based on direction.