Build the Windows installer in a container, and run it under Wine

docs/windows.md specified it; this is §9 steps 1, 2 and 4 run, and the
report in §10. A Debian trixie image with rustup, the MinGW cross
compiler, NSIS and Wine; a build.sh in the shape of the Android one;
a package.sh that stages the executable and the seven models behind
the same LFS-pointer guard every other packager carries, then runs
makensis; and the .nsi itself — per-user, no elevation, an uninstaller
that leaves the library alone.

Measured: the executable links first time once the link flags were
right, imports only Windows system DLLs, prints its version under
Wine, and the installer installs and uninstalls silently under Wine
with the registry key and the models where §5.2 says. What Wine
cannot show is the Start Menu shortcut: CreateShortcut is IShellLink
and does nothing headless.

Four claims in the spec's first draft were wrong and are corrected in
place with the reasoning kept: the whole-archive winpthread flag
breaks the link and was never needed; build scripts need a host gcc;
bookworm's Wine lacks the bcryptprimitives.dll rustc's std imports,
so the image is trixie; and NSIS's default stub is 32-bit, so the
installer says amd64-unicode and needs no i386 Wine.
This commit is contained in:
2026-09-12 00:54:11 +02:00
parent fa4dca327f
commit 2836ec2881
6 changed files with 536 additions and 27 deletions
+107
View File
@@ -0,0 +1,107 @@
# DarkRoom — reproducible Windows cross-build environment
#
# Everything docs/windows.md §2 names: Rust with the GNU Windows target, the
# MinGW-w64 cross compiler it links with, NSIS to build the installer, and Wine
# to smoke-test the result. Both CI and local builds use this image, so "works
# on my machine" and "works in CI" are the same machine — the same argument
# docker/android makes, and the same shape.
#
# Build: docker build -t darkroom-windows:latest docker/windows
# Use: ./docker/windows/build.sh cargo build --release --target x86_64-pc-windows-gnu -p darkroom-desktop
# trixie rather than the Android image's bookworm, for Wine: rustc's std
# imports bcryptprimitives.dll for its random source, and bookworm's Wine 8.0
# does not have it, so the smoke test dies at load with c0000135 before a
# single instruction of the application runs. Wine 10 does. trixie also ships
# Node 20 itself, so the NodeSource step the Android image needs is not here.
FROM docker.io/library/debian:trixie-slim
# ---------------------------------------------------------------------------
# Versions — pinned deliberately, like the Android image.
# ---------------------------------------------------------------------------
ARG RUST_VERSION=1.92.0
ENV DEBIAN_FRONTEND=noninteractive \
CARGO_HOME=/opt/cargo \
RUSTUP_HOME=/opt/rustup \
PATH=/opt/cargo/bin:$PATH
# ---------------------------------------------------------------------------
# System packages
# ---------------------------------------------------------------------------
RUN apt-get update && apt-get install -y --no-install-recommends \
ca-certificates curl git git-lfs \
# A *host* C compiler as well as the cross one: build scripts and
# proc-macros are compiled for Linux and linked with `cc`, whatever
# the target. Without it the very first build script fails with
# "linker `cc` not found" before any Windows code is reached.
gcc libc6-dev \
# The cross compiler, binutils and the MinGW runtime headers/libs. This
# is the one C toolchain the target needs: bundled SQLite, ring's asm
# and anything else the cc crate builds for the target go through it.
gcc-mingw-w64-x86-64 binutils-mingw-w64-x86-64 \
# The installer compiler. A native Linux binary; NSIS has always built
# its installers on POSIX hosts.
nsis \
# Runs the .exe and the installer for the smoke tests (windows.md §6).
# Not needed to build anything. Both packages: `wine64` is the
# loader under /usr/lib/wine, `wine` is the wrapper on PATH.
wine wine64 \
# `file` reports PE32+; `xz-utils` because the mingw packages are
# compressed with it.
file xz-utils \
# Gitea runs JavaScript actions (checkout, cache) from inside the job
# container, and current actions want Node 20 or newer.
nodejs \
&& rm -rf /var/lib/apt/lists/* \
&& node --version
# ---------------------------------------------------------------------------
# Rust + the Windows target
#
# The component list must be a superset of rust-toolchain.toml's, for the
# reason the Android Dockerfile gives: rustup reconciles that file on the
# first cargo invocation and downloads anything missing inside the job.
# ---------------------------------------------------------------------------
RUN curl -fsSL https://sh.rustup.rs | sh -s -- \
-y --no-modify-path --profile minimal --default-toolchain ${RUST_VERSION} \
&& rustup target add x86_64-pc-windows-gnu \
&& rustup component add rustfmt clippy rust-analyzer \
&& chmod -R a+rwX ${CARGO_HOME} ${RUSTUP_HOME}
# ---------------------------------------------------------------------------
# Linker configuration
#
# Debian ships the cross compiler in two thread models and the bare name is an
# alternatives symlink. `-posix` is stated: it is the one whose libstdc++ and
# libwinpthread the Rust target's own MinGW pieces were built against, and
# picking the other produces link errors that read as if std were missing.
#
# The runtime is linked statically (docs/windows.md §2) so the installer
# carries one file. `-static-libgcc` is all it takes: rustc's windows-gnu
# target links its own copy of winpthread in self-contained mode, so nothing
# imports libwinpthread-1.dll — the smoke test's objdump step is what checks
# that. The `--whole-archive -lwinpthread` incantation the spec first named is
# wrong here: it forces in unused winpthread objects whose kernel32 and
# msvcrt references come after those libraries on the link line, and the
# link fails on a hundred undefined `__imp_` symbols.
# ---------------------------------------------------------------------------
ENV CARGO_TARGET_X86_64_PC_WINDOWS_GNU_LINKER=x86_64-w64-mingw32-gcc-posix \
CARGO_TARGET_X86_64_PC_WINDOWS_GNU_RUSTFLAGS="-C link-args=-static-libgcc -C link-args=-static-libstdc++" \
CC_x86_64_pc_windows_gnu=x86_64-w64-mingw32-gcc-posix \
CXX_x86_64_pc_windows_gnu=x86_64-w64-mingw32-g++-posix \
AR_x86_64_pc_windows_gnu=x86_64-w64-mingw32-gcc-ar-posix \
WINDRES=x86_64-w64-mingw32-windres
# Wine writes its prefix under $HOME and refuses a directory it does not own.
# The caller passes --user, so nothing baked into the image can be owned by
# that user; build.sh bind-mounts a host directory here instead, which also
# keeps the prefix (and its slow first `wineboot`) across runs.
ENV HOME=/tmp/home \
WINEDEBUG=-all
VOLUME ["/opt/cargo/registry"]
WORKDIR /work
CMD ["/bin/bash"]
+56
View File
@@ -0,0 +1,56 @@
# Windows cross-build environment
Reproducible container for building the Windows executable and its installer from Linux. The
specification is [docs/windows.md](../../docs/windows.md); this directory is what it turned into,
and every departure from the spec's first draft is recorded in the Dockerfile's comments.
## Use
```bash
# Cross-compile the desktop application
./docker/windows/build.sh cargo build --release --target x86_64-pc-windows-gnu -p darkroom-desktop
# Lint the cfg(windows) branches, which the Linux job never sees
./docker/windows/build.sh cargo clippy --target x86_64-pc-windows-gnu -p darkroom-desktop -- -D warnings
# Build the installer from that binary
./docker/windows/build.sh docker/windows/package.sh
# Smoke-test under Wine (docs/windows.md §6)
./docker/windows/build.sh wine target-windows/x86_64-pc-windows-gnu/release/darkroom-desktop.exe --version
./docker/windows/build.sh wine target-windows/installer/DarkRoom-0.12.0-x86_64-setup.exe /S
# Interactive shell
./docker/windows/build.sh
# After editing the Dockerfile
./docker/windows/build.sh --rebuild
```
Prefers `podman`, falls back to `docker`. The cargo registry, the target directory and the Wine
prefix persist under `~/.cache/darkroom-windows/`, so a warm rebuild is minutes and the first
`wineboot` happens once.
## What is verified here, and what is not
Measured on the first build, 2026-09-12:
| Check | Result |
|---|---|
| `cargo build --target x86_64-pc-windows-gnu -p darkroom-desktop` | Links. 115 MB, `PE32+ … (GUI)` |
| DLL imports | 26 Windows system DLLs; **no** `libwinpthread-1.dll`, `libgcc_s`, `libstdc++` |
| `wine darkroom-desktop.exe --version` | `darkroom-desktop 0.12.0`, exit 0, 0.1 s |
| `makensis` | 105 MB `DarkRoom-<version>-x86_64-setup.exe`, 64-bit stub |
| `wine setup.exe /S` | Installs exe + 7 models to `AppData\Local\Programs\DarkRoom`, writes the `HKCU` uninstall key; the installed exe runs |
| `wine uninstall.exe /S` | Removes the directory and the key |
| Start Menu shortcut | **Not verifiable here.** `CreateShortcut` is `IShellLink` and does nothing under a headless Wine; the directory beside it is created. Check on Windows. |
None of this proves a Vulkan device opens, a render completes, fonts are found or the secret store
round-trips. Those are a Windows machine, once per release — and today the secret store *cannot*
round-trip, because its Windows implementation is still the loud placeholder (docs/windows.md
§3.2).
## In CI
Not yet wired. The image and the leg are specified in docs/windows.md §7 in the shape of the
Android ones, and every step they would run has been exercised by hand above.
+76
View File
@@ -0,0 +1,76 @@
#!/usr/bin/env bash
# Run a command inside the DarkRoom Windows cross-build container.
#
# ./docker/windows/build.sh cargo build --release --target x86_64-pc-windows-gnu -p darkroom-desktop
# ./docker/windows/build.sh cargo clippy --target x86_64-pc-windows-gnu -p darkroom-desktop
# ./docker/windows/build.sh # interactive shell
#
# Builds the image on first use. Rebuild after editing the Dockerfile with:
# ./docker/windows/build.sh --rebuild
set -euo pipefail
IMAGE="darkroom-windows:latest"
HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO="$(cd "${HERE}/../.." && pwd)"
# Prefer podman (rootless by default); fall back to docker.
if command -v podman >/dev/null 2>&1; then
ENGINE=podman
elif command -v docker >/dev/null 2>&1; then
ENGINE=docker
else
echo "error: neither podman nor docker found" >&2
exit 1
fi
if [[ "${1:-}" == "--rebuild" ]]; then
shift
"${ENGINE}" build -t "${IMAGE}" "${HERE}"
elif ! "${ENGINE}" image exists "${IMAGE}" 2>/dev/null && \
! "${ENGINE}" image inspect "${IMAGE}" >/dev/null 2>&1; then
echo "==> building ${IMAGE} (first run; several minutes)"
"${ENGINE}" build -t "${IMAGE}" "${HERE}"
fi
# Persist the cargo registry and target dir across runs, or every build
# re-downloads the crate index.
CACHE="${XDG_CACHE_HOME:-${HOME}/.cache}/darkroom-windows"
# `home` is the container's $HOME: Wine keeps its prefix there for the smoke
# tests, and refuses one it does not own — which rules out anything the image
# could have created, since the container runs as the host user.
mkdir -p "${CACHE}/registry" "${CACHE}/target" "${CACHE}/home"
ARGS=(
--rm
-v "${REPO}:/work:z"
-v "${CACHE}/registry:/opt/cargo/registry:z"
-v "${CACHE}/target:/work/target-windows:z"
-v "${CACHE}/home:/tmp/home:z"
-e CARGO_TARGET_DIR=/work/target-windows
-w /work
)
# Build parallelism. A full cross-compile will otherwise take every thread on
# the host and make the machine unusable for the length of the build, which is
# a poor trade when it is running in the background.
#
# Both halves are needed: CARGO_BUILD_JOBS caps how many rustc processes cargo
# starts, while --cpus caps what the container gets no matter what any nested
# build script decides to spawn (cc, cmake, and ring's asm build all parallelise
# on their own account and do not consult cargo).
JOBS="${DARKROOM_BUILD_JOBS:-8}"
if [[ "${JOBS}" != "0" ]]; then
ARGS+=(--cpus "${JOBS}" -e "CARGO_BUILD_JOBS=${JOBS}")
fi
# Rootless podman already maps the host user; docker needs it stated.
if [[ "${ENGINE}" == "docker" ]]; then
ARGS+=(--user "$(id -u):$(id -g)")
fi
if [[ $# -eq 0 ]]; then
ARGS+=(-it)
set -- /bin/bash
fi
exec "${ENGINE}" run "${ARGS[@]}" "${IMAGE}" "$@"
+67
View File
@@ -0,0 +1,67 @@
#!/usr/bin/env bash
# Assemble the Windows installer from a finished cross-build.
#
# ./docker/windows/build.sh docker/windows/package.sh
#
# Expects `cargo build --release --target x86_64-pc-windows-gnu -p darkroom-desktop`
# to have run in the same target directory. Produces
# DarkRoom-<version>-x86_64-setup.exe in $OUT (default: target-windows/installer).
#
# Runs inside the container, where makensis is; docs/windows.md §5 is the
# specification this implements.
set -euo pipefail
HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO="$(cd "${HERE}/../.." && pwd)"
TARGET="${CARGO_TARGET_DIR:-${REPO}/target}/x86_64-pc-windows-gnu/release"
OUT="${OUT:-${CARGO_TARGET_DIR:-${REPO}/target}/installer}"
EXE="${TARGET}/darkroom-desktop.exe"
[[ -f "${EXE}" ]] || { echo "error: ${EXE} not built" >&2; exit 1; }
# The version, from the workspace rather than restated here — the same single
# source tools/set-version.sh writes and the APK packager reads.
VERSION="$(sed -n 's/^version = "\(.*\)"$/\1/p' "${REPO}/Cargo.toml" | head -1)"
[[ -n "${VERSION}" ]] || { echo "error: no version in Cargo.toml" >&2; exit 1; }
echo "==> version ${VERSION}"
# Staging: exactly what the installer carries (windows.md §5.2), and nothing
# from a previous run — a model dropped from the tree must not linger here
# and go on shipping.
STAGE="${OUT}/stage"
rm -rf "${STAGE}"
mkdir -p "${STAGE}/models"
cp "${EXE}" "${STAGE}/darkroom.exe"
# The models, with the guard every other packager carries: an LFS pointer is
# ~130 bytes and looks exactly like a model to `cp`. Shipped, it fails inside
# tract on the user's machine with a message about a broken graph rather than
# a checkout that needed `git lfs pull`. Only the weights are checked; the
# scene model's vocabulary and category descriptor are legitimately small.
for dir in face scene; do
for f in "${REPO}/models/${dir}"/*; do
case "$(basename "${f}")" in
README.md) continue ;;
esac
if [[ "${f}" == *.onnx && "$(stat -c%s "${f}")" -lt 100000 ]]; then
echo "error: $(basename "${f}") is $(stat -c%s "${f}") bytes — an LFS pointer, not a model." >&2
echo " run: git lfs pull" >&2
exit 1
fi
cp "${f}" "${STAGE}/models/"
done
done
echo "==> staged $(ls "${STAGE}/models" | wc -l) model file(s)"
INSTALLER="${OUT}/DarkRoom-${VERSION}-x86_64-setup.exe"
# NSIS wants Windows-style paths in File directives even on a POSIX host, and
# the script takes its inputs by define so nothing about the layout here is
# written into it.
makensis -V2 \
-DVERSION="${VERSION}" \
-DSTAGE="${STAGE}" \
-DOUT="${INSTALLER}" \
"${REPO}/packaging/windows/darkroom.nsi"
ls -la "${INSTALLER}"
echo "==> ${INSTALLER}"