`Run-time error '76': Path not found` on finishing a game. Error 76 is VB6's
"path not found", and the path it could not find was the game's own.
Confining the prefix removed `z:`, which left `C:` as the only drive — and the
executable was in the plugin checkout, which `C:` does not cover. So wine gave
the game `\\?\unix\home\pastilhas\...\Minesweeper X.exe` as its own location
(confirmed with `winepath`), VB6 file I/O cannot write to a path of that shape,
and the first thing that needs to is the auto-saved recording. Which happens at
the END of a game, so the failure arrived after somebody had played.
The comment in prefix.ts already claimed "the game keeps its own directory, its
settings and its replays". It did not. It does now: `installGame` copies the
68 KB executable into `C:\Minesweeper` on every start and the game runs from
there, with cwd set to match so relative writes stop landing in C:\windows.
Copied rather than symlinked — a symlink out of drive_c is a door out of the
prefix, which is the exact thing confinePrefix exists to close. The cost is
that replays now live inside prefix/, so deleting it to unwedge wine takes them
along; that is in the README rather than left to be discovered.
Verified end to end rather than by inspection: set Auto-Save Recording to All,
played a beginner game to a loss, and
`Beg 1.16 - Aug 23 2026 22.09.18 PM (Lost).mvr` appeared in C:\Minesweeper.
Before this, that same moment was the error box. The default is "High scores",
which is why an ordinary losing game never reproduced it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
A cold install could never work. `winetricks -q vb6run` runs Microsoft's
redistributable, and that installer creates a window even when told to be
quiet — so with no DISPLAY wine cannot load a graphics driver, the installer
dies, and winetricks reports `returned status 43`. That message names neither
wine nor a display, and reads like a corrupt download.
ensurePrefix ran before Xvfb started, because building a prefix looks like
preparation rather than something that needs a screen.
It never showed up in testing here: this machine's prefix was seeded from the
pre-extraction one, so the build path only ever ran against a prefix that was
already complete. The first genuine cold install — alpha — failed on the first
Start. Diagnosed from `err:winediag:nodrv_CreateWindow` in the wine output,
which is the only line that says what is actually wrong.
Order is now display, prefix, game. ensurePrefix takes the display explicitly
rather than reading the ambient environment, so it cannot silently run without
one again, and a failed build now tears the display down instead of leaving an
Xvfb behind.
Verified by moving this machine's prefix aside and starting cold: prefix built
from nothing, msvbvm60.dll installed, session up with the window at 152x214,
Z: confined, socket mode 700, and RFB 003.008 through the platform relay.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
Two things the live install found.
The manifest was refused at discovery. `apt: 'wine wine32:i386'` is two
packages and an architecture suffix, and a package name may be neither — nor
should it be, since `dpkg --add-architecture i386` has to happen first and no
package name can express that. And Fedora's Xvfb package is
`xorg-x11-server-Xvfb`, with a capital X, which a manifest package name may not
have; the dnf entry is dropped rather than guessed, which turns into an
instruction to the owner instead of a wrong install.
More importantly: confining the prefix before wine starts is a confinement wine
can undo. Observed directly — after a run, every com* link had come back with a
fresh timestamp, because wine rebuilds dosdevices when it boots a prefix it
thinks needs updating, and a wine package upgrade is enough to make it think
so. Z: did not come back that time, but "the dangerous one happened not to
regenerate" is not a property to rely on. confineAndVerify now runs again once
the game is up and says so if Z: returned.
Verified on the live server: Z: and the three home symlinks are gone from a
prefix that had them, run/ is mode 700, nothing listens on 5907, and the RFB
handshake arrives through the platform relay with a valid owner token and
through nothing else.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
Minesweeper X under wine on a headless display, as a plugin. It was
/api/minesweeper, a Dashboard screen, an officerdev panel, a permission
registry entry and a hand-written websocket provider in server.tsx.
The socket is why it had to live in the platform: Bun's route table is fixed
at serve(), so nothing installed later could add one. That ceiling is gone,
and this is the first plugin through the per-plugin relay.
Three things changed rather than moved:
The sidecar owns the session. The platform used to spawn bin/session.sh
detached, so the game outlived every restart, nothing supervised it, and a
crashed run left wine processes holding the prefix — the next start hung
rather than failed. PM2 supervises a sidecar, and stop() uses 'wineserver -k'
scoped by WINEPREFIX instead of 'pkill -f wineserver', which would have killed
every other wine prefix on the machine.
x11vnc moved from 127.0.0.1:5907 to a unix socket in a mode-0700 directory.
-nopw was only ever safe because of the machine, not the platform: any local
account could open that port and take the display. A fixed port is squattable
too. There is now no listener to authenticate against.
The wine prefix is confined to C:. This is the one that mattered. The platform
classified Minesweeper as kind:'execution' — never grantable — because a fresh
prefix maps the whole filesystem to Z: and symlinks the profile into the
owner's real home, and the game has Open and Save dialogs. A plugin permission
has no kind and is always grantable, so extracting it without this would have
converted a sealed capability into a file picker running as the owner.
Re-asserted on every start, because wine restores z: whenever it updates a
prefix.
Not solved: one display and one game, so two grantees share a board.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
pastilhasandClaude Opus 5