Skip to content

OpenBox 1.13.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 20 Sep 10:12
v1.13.0
71d75ec

OpenBox 1.13.0 — Windows

OpenBox now runs natively on Windows alongside Linux: the same library and the
same UI in a real WebView2 window, installed from a signed portable release with
verified updates. The Linux channels are unchanged.

What's New

A native Windows window

native_host_win.c is a full WebView2 host: it spawns the same web_app.py
loopback server, waits for the token and port, and renders the one UI in a
WebView2 window with the same window.openboxNative bridge the page already
speaks — remembered window geometry, tray icon and minimize-to-tray,
openbox:// deeplinks, and one instance per data directory that focuses the
window already open. On close it stops the server gracefully (CTRL_BREAK) and
force-kills the tree through a job object if the server does not exit.

The release workflow builds native_host.exe on windows-latest from
native_host_win.c (Visual Studio Build Tools with the C++ workload, plus the
WebView2 SDK from the NuGet cache or nuget.org), refuses to publish a zip that
does not contain it, and the windows-latest CI job compiles the same host on
every push — so the released zip runs the native window out of the box. Source
checkouts build it with scripts/build_native_host_windows.ps1; when the binary
is absent the launchers open the same UI in a browser app window.

The same binary is attached to this release as
OpenBox-x86_64-windows-native-host.exe — attested and signed with the release
key, exactly like the zip it also ships inside — so a source checkout that does
not want to install MSVC and the WebView2 SDK can save it beside web_app.py as
native_host.exe (or point OPENBOX_NATIVE_HOST at it) and get the native
window. It is the window host only: the rest of the tree stays the source
checkout's, and without the WebView2 runtime --web runs the browser UI.

Launchers and a verified install

openbox.cmd, openbox.ps1, and openbox-native.ps1 follow the same ladder as
the shell scripts: native host first, then the browser app window, then a plain
tab; openbox --web forces the browser. scripts/install.ps1 verifies the
release key anchor, the SHA-256 sidecar, and the Ed25519 signature before
extracting anything, installs to %LOCALAPPDATA%\OpenBox\share\openbox, keeps
the previous tree at share\openbox.previous, adds the bin root to your user
PATH, and registers both a Start Menu shortcut and the openbox:// protocol
handler. The in-app updater verifies and swaps the installed tree the same way,
and refuses to overwrite anything that is not an installed copy.

Windows-aware library behavior

Every bundled emulator definition carries its Windows executable name, so
adapter detection, resume state, and Launch Doctor work with Windows builds of
Dolphin, RetroArch, PCSX2, RPCS3, Cemu, melonDS, PPSSPP, Vita3K, xemu, Xenia,
and the rest. Library state lives in %LOCALAPPDATA%\openbox-game-launcher\,
and stored references keep POSIX separators so a library stays portable between
platforms. Windows builds of Steam libraries are discovered through the same
import path as Linux.

Still no dependencies

The runtime stays stdlib-only, ctypes included: file locking, process
liveness/suspend/terminate, /proc equivalents, command quoting, path openers,
browser launching, and data-directory resolution all live behind
pkg/platform_compat.py, the single platform seam (ADR 0048). The AppImage,
Flatpak, and system-install paths are untouched.

Fixed

  • A liveness check that killed games. os.kill(pid, 0) is not a probe on
    Windows — CPython maps it to TerminateProcess, so reattaching to a running
    game or requesting shutdown could kill it. Liveness now goes through
    platform_compat.process_alive.
  • Stored references use POSIX separators everywhere. SBOM symlink targets,
    {EmulatorDir} token parents, resume-state metadata, and the runtime-module
    manifest are written with / on Windows instead of backslashes, so artifacts
    and state compare correctly across platforms.
  • SQLite handles before an atomic swap. The metadata database closes its
    cached thread-local connections before replacing the file, so a live resync
    cannot fail with a locked metadata.db on Windows.

Windows boundaries

Linux remains the primary target for distro integration: AppImage and Flatpak
packaging, gamescope/Game Mode, XDG desktop entries, and Flathub-aware emulator
management are Linux-only. Windows ships x86_64 and the released zip includes the
compiled WebView2 host, so the native window works as installed; the WebView2
runtime is required (present on Windows 11 and most Windows 10 systems), and
--web runs the browser UI if it is missing.

Download

Asset Architecture Type
OpenBox-x86_64.AppImage x86_64 AppImage
OpenBox-aarch64.AppImage ARM64 AppImage
OpenBox-x86_64.flatpak x86_64 Flatpak
OpenBox-x86_64-windows.zip x86_64 Windows portable (signed)
OpenBox-x86_64-windows-native-host.exe x86_64 WebView2 window host (signed)

Windows: download install.ps1 and OpenBox-x86_64-windows.zip from this
release and run the installer in Windows PowerShell 5.1; it needs no curl and
no OpenSSL. Running from a checkout instead? Take
OpenBox-x86_64-windows-native-host.exe and save it beside web_app.py as
native_host.exe. Linux: pick the AppImage that matches your CPU, or
install the Flatpak for a sandboxed desktop setup. AppImages are signed and
include SHA-256 checksums, zsync metadata for delta updates, and SBOMs. Verify
with openbox-release.pub and install.sh.

Already running OpenBox? Use the built-in updater or download the matching artifact from the release page.

Full Changelog: v1.12.1...v1.13.0

Assets 22
Loading