build: package haul.exe with an embedded icon

A plain `go build` links no icon resource, so Explorer and the Start menu
draw the generic executable glyph. Inno's SetupIconFile only skins
setup.exe, so the fix has to happen at build time: `fyne package` turns
cmd/haul/Icon.png into a .syso and links it in, and adds -H=windowsgui
itself.

Documents the installer build alongside it, since the two steps are only
useful together.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitignore

@@ -1,3 +1,4 @@
 /bin/
 /dist/
 /haul.app/
+/Output/

Inno-compile.iss

@@ -0,0 +1,83 @@
+; Inno Setup script for haul — build with: iscc Inno-compile.iss
+;
+; Source paths below are relative to this file, so the script compiles from a
+; clone of the repo on any machine. Build the binary first:
+;
+;   go build -trimpath -ldflags "-s -w -H=windowsgui" -o bin\haul.exe .\cmd\haul
+;
+; The optional Mesa component picks up whatever DLLs are sitting in bin\ — see
+; "Running over Remote Desktop" in README.md for where to get them.
+;
+; Non-commercial use only
+
+#define MyAppName "Haul"
+#define MyAppVersion "0.1.0"
+#define MyAppPublisher "A Apointless Space"
+#define MyAppURL "https://gitea.apointless.space/bsncubed/haul"
+#define MyAppExeName "haul.exe"
+
+[Setup]
+; NOTE: The value of AppId uniquely identifies this application. Do not use the same AppId value in installers for other applications.
+AppId={{E7059C44-7B67-430F-BF2E-6BED87C720B6}
+AppName={#MyAppName}
+AppVersion={#MyAppVersion}
+AppPublisher={#MyAppPublisher}
+AppPublisherURL={#MyAppURL}
+AppSupportURL={#MyAppURL}
+AppUpdatesURL={#MyAppURL}
+; PrivilegesRequired=lowest makes {autopf} resolve to %LOCALAPPDATA%\Programs,
+; which is the per-user equivalent of Program Files. Use the constant rather
+; than a literal %LOCALAPPDATA% — Inno does not expand environment variables in
+; that form, and would create a folder named "%LOCALAPPDATA%" instead.
+DefaultDirName={autopf}\{#MyAppName}
+UninstallDisplayIcon={app}\{#MyAppExeName}
+; "ArchitecturesAllowed=x64compatible" specifies that Setup cannot run
+; on anything but x64 and Windows 11 on Arm.
+ArchitecturesAllowed=x64compatible
+; "ArchitecturesInstallIn64BitMode=x64compatible" requests that the
+; install be done in "64-bit mode" on x64 or Windows 11 on Arm,
+; meaning it should use the native 64-bit Program Files directory and
+; the 64-bit view of the registry.
+ArchitecturesInstallIn64BitMode=x64compatible
+DisableProgramGroupPage=yes
+; Remove the following line to run in administrative install mode (install for all users).
+PrivilegesRequired=lowest
+SetupIconFile=cmd\haul\Icon.ico
+OutputBaseFilename=haul-{#MyAppVersion}-setup-x64
+Compression=lzma2/max
+SolidCompression=yes
+WizardStyle=modern
+
+[Languages]
+Name: "english"; MessagesFile: "compiler:Default.isl"
+
+[Types]
+Name: "standard"; Description: "Standard installation"
+Name: "rdp"; Description: "Remote Desktop / virtual machine (adds software OpenGL)"
+Name: "custom"; Description: "Custom installation"; Flags: iscustom
+
+; A local opengl32.dll always wins over the system one, because Windows searches
+; the executable's own directory first — so shipping Mesa unconditionally would
+; force software rendering on every machine, including ones with a real GPU.
+; Hence it is opt-in, for the RDP/Hyper-V/basic-display case that needs it.
+[Components]
+Name: "app"; Description: "Haul"; Types: standard rdp custom; Flags: fixed
+Name: "mesa"; Description: "Software OpenGL renderer (Mesa llvmpipe)"; Types: rdp
+
+[Tasks]
+Name: "desktopicon"; Description: "{cm:CreateDesktopIcon}"; GroupDescription: "{cm:AdditionalIcons}"; Flags: unchecked
+
+[Files]
+Source: "bin\{#MyAppExeName}"; DestDir: "{app}"; Components: app; Flags: ignoreversion
+; Wildcard rather than a hand-maintained list: the Mesa distribution's file set
+; changes between releases, and a missing entry fails at compile time while a
+; stale one silently ships a DLL that no longer loads.
+Source: "bin\*.dll"; DestDir: "{app}"; Components: mesa; Flags: ignoreversion
+; NOTE: Don't use "Flags: ignoreversion" on any shared system files
+
+[Icons]
+Name: "{autoprograms}\{#MyAppName}"; Filename: "{app}\{#MyAppExeName}"
+Name: "{autodesktop}\{#MyAppName}"; Filename: "{app}\{#MyAppExeName}"; Tasks: desktopicon
+
+[Run]
+Filename: "{app}\{#MyAppExeName}"; Description: "{cm:LaunchProgram,{#StringChange(MyAppName, '&', '&&')}}"; Flags: nowait postinstall skipifsilent

Makefile

@@ -12,7 +12,7 @@ GO ?= $(shell test -x $(HOME)/.local/go/bin/go && echo $(HOME)/.local/go/bin/go
 # FYNE=/path/to/fyne if you'd rather use an installed copy.
 FYNE ?= $(GO) run fyne.io/tools/cmd/fyne@v1.7.2
 
-.PHONY: build install test vet check run run-xvfb dist package-darwin clean
+.PHONY: build install test vet check run run-xvfb dist package-darwin package-windows clean
 
 build: ## Build a native binary into ./bin/haul
 	$(GO) build -trimpath -ldflags "$(LDFLAGS)" -o bin/haul ./cmd/haul
@@ -80,5 +80,25 @@ package-darwin: ## Package haul.app for macOS (run this on a Mac)
 	$(FYNE) package --target darwin --src ./cmd/haul --release
 	@echo "built ./haul.app — drag it into /Applications"
 
+# A plain `go build` produces a haul.exe with no icon resource, so Explorer, the
+# taskbar and the Start menu all draw the generic executable icon. Nothing in
+# the installer can fix that — Inno's SetupIconFile only skins setup.exe itself.
+# `fyne package` generates a .syso from cmd/haul/Icon.png (it converts the PNG
+# itself; cmd/haul/Icon.ico is for Inno, not for this) and links it in, so the
+# icon travels with the binary. It also adds -H=windowsgui on its own, so this
+# needs none of the manual linker flags the README's build command does.
+#
+# Run this ON Windows, from the MSYS2 UCRT64 shell if you installed make there:
+# haul is cgo, so it needs the host MinGW-w64 toolchain. Like package-darwin it
+# rewrites cmd/haul/FyneApp.toml in place, bumping Build.
+#
+# fyne writes the binary beside the source, as cmd/haul/haul.exe. Move it into
+# bin/, which is where Inno-compile.iss looks for it.
+package-windows: ## Package haul.exe with an embedded icon (run this on Windows)
+	$(FYNE) package --target windows --src ./cmd/haul --release
+	@mkdir -p bin
+	mv ./cmd/haul/haul.exe ./bin/haul.exe
+	@echo "built ./bin/haul.exe — compile Inno-compile.iss to wrap it in an installer"
+
 clean: ## Remove build artifacts
-	rm -rf bin dist haul.app
+	rm -rf bin dist haul.app Output

README.md

@@ -250,6 +250,59 @@ xattr -dr com.apple.quarantine /Applications/haul.app
 Signing and notarising properly needs a paid Apple Developer ID, after which
 `fyne release --target darwin --certificate <name>` handles it.
 
+### Packaging on Windows
+
+The `go build` command [above](#building-on-windows) produces a working
+`haul.exe`, but one with **no icon** — Explorer, the taskbar and the Start menu
+all draw the generic executable glyph. A Windows binary carries its icon as a
+linked resource, and the Go compiler has nothing to link unless you give it a
+`.syso`. `fyne package` builds one:
+
+```powershell
+go run fyne.io/tools/cmd/fyne@v1.7.2 package --target windows --src .\cmd\haul --release
+Move-Item .\cmd\haul\haul.exe .\bin\haul.exe
+```
+
+Or, from the MSYS2 shell with `make` installed, `make package-windows`.
+
+That converts `cmd/haul/Icon.png` to an icon resource, links it in, and adds
+`-H=windowsgui` itself — so unlike the manual build you don't pass any linker
+flags. It writes the binary *beside the source* as `cmd\haul\haul.exe`, hence
+the move: `Inno-compile.iss` expects it in `bin\`. As on macOS, `fyne package`
+rewrites `cmd/haul/FyneApp.toml` in place and bumps `Build`.
+
+#### The installer
+
+`Inno-compile.iss` wraps that binary in a setup program. Install [Inno
+Setup](https://jrsoftware.org/isdl.php) (`winget install JRSoftware.InnoSetup`),
+then from the repo root:
+
+```powershell
+iscc Inno-compile.iss
+```
+
+That writes `Output\haul-0.1.0-setup-x64.exe`. Every `Source:` path in the
+script is relative to the script itself, so it compiles from any clone — but it
+packages whatever is in `bin\` at that moment, and does not build anything
+itself. Run the packaging step above first.
+
+It installs per-user into `%LOCALAPPDATA%\Programs\Haul`, so it needs no
+administrator rights and prompts for no UAC elevation.
+
+The wizard offers two install types. **Standard** installs `haul.exe` alone.
+**Remote Desktop / virtual machine** adds every DLL from `bin\` as the optional
+`mesa` component — the software OpenGL renderer described
+[below](#running-over-remote-desktop-or-in-a-vm). That split is deliberate and
+worth keeping: those DLLs override the system OpenGL for anything in the same
+folder, so installing them by default would force software rendering on machines
+with a perfectly good GPU. Populate `bin\` with the Mesa DLLs only when you
+intend to build an installer that offers them.
+
+Note that `cmd\haul\Icon.ico` is used by Inno for `setup.exe`'s own icon. The
+icon inside `haul.exe` comes from `Icon.png` via `fyne package` — the two are
+separate, and dropping the packaging step leaves you with a nicely-iconed
+installer that installs an icon-less application.
+
 ### Running over Remote Desktop (or in a VM)
 
 A build that compiles perfectly will still fail to start in an RDP session with:
@@ -315,7 +368,8 @@ Software rendering is slower than a GPU, but haul draws two tables and some text
 | `make run-xvfb`   | Build, then run against a virtual X display               |
 | `make dist`       | Release binary into `./dist`                              |
 | `make package-darwin` | macOS `.app` bundle into `./haul.app` (run on a Mac)   |
-| `make clean`      | Remove `bin/`, `dist/` and `haul.app/`                     |
+| `make package-windows` | `bin/haul.exe` with an embedded icon (run on Windows) |
+| `make clean`      | Remove `bin/`, `dist/`, `haul.app/` and `Output/`          |
 
 The Makefile picks up a Go toolchain at `~/.local/go/bin/go` if one is there,
 falling back to whatever `go` is on `PATH` — so it works on machines where Go