VERSIONINFO auto-naming did not fire on GUI install flow (SWG bottle 7F4FF523)

[nickk02]

Symptom

For self-contained Windows apps installed via the GUI "Install Windows App" flow, the resulting bottle / app display name remains the source-exe stem instead of being derived from the .exe's VS_VERSIONINFO ProductName.

Concretely on 2026-05-28: installing SWG Legends via ~/Downloads/SWGLegendsSetup.exe produced bottle 7F4FF523-... shown in Crosswire's UI as SWGLegendsLauncher (the launcher's exe stem) rather than SWG Legends Launcher (which the launcher's PE VS_VERSIONINFO ProductName parses cleanly to in standalone smoke tests).

Evidence the parser itself is fine

VERSIONINFO parser was added in commit 76385f6 (CrosswireKit/.../PE/VersionInfo.swift). Standalone smoke tests on the same .exes returned the expected names:

• SWGLegendsLauncher.exe → SWG Legends Launcher
• npp-installer.x64.exe → Notepad++

So the parser is correct. Something in the install flow is bypassing the call site, or calling it against the wrong .exe, or calling it before the .exe is in the bottle.

Likely candidates to check

1. Bottle+Extensions.swift::finalizeAppIdentity() — chain is Start Menu shortcut → VERSIONINFO → registry uninstall DisplayName → installer filename. Maybe the chain skips VERSIONINFO because the Start Menu shortcut was created (with the installer's name, not the launcher's) and that wins.

2. provisionAndInstall in ContentView+Install.swift calls finalizeAppIdentity() after Wine.runProgram(installer). The .exe that VERSIONINFO sees is whatever userVisiblePrograms returns first — possibly the installer itself (which would VERSIONINFO to "Setup" or similar) rather than the launcher post-install.

3. The display name resolution might be deciding the bottle name from the source picker URL (SWGLegendsSetup.exe → "SWGLegendsSetup") and never updating after the installer drops the actual launcher.

Investigation needed

Read Bottle+Extensions.swift::finalizeAppIdentity(). Trace what userVisiblePrograms actually contains after a SWG install. Check whether VERSIONINFO was called and what value it returned. Determine the precedence in the name-resolution chain.

Severity

Cosmetic but visible — same surprise as the bug #91 plist gap. Same likely root area (auto-flow ordering / call-site mismatch in provisionAndInstall). Worth diagnosing alongside #91 since they may share a root cause.

Discovered 2026-05-28 during Checkpoint D end-to-end validation. See also docs/MILESTONE-SWG-LAUNCHER.md and docs/CHECKPOINT-D-SHIPPED.md.

[nickk02]

Resolved. The VERSIONINFO-precedence fix landed in 9ca8ccf ("Fix #91 + #92: drop decode write-side-effect, prefer VERSIONINFO over Start Menu"): finalizeAppIdentity() now prefers the PE VS_VERSIONINFO / registry DisplayName over the Start Menu .lnk stem (Bottle+Extensions.swift), instead of the stem always winning.

Verified on the current SWG bottle:

• raw name (installer stem) = SWGLegendsSetup
• appDisplayName (shown in UI) = "Star Wars Galaxies Legends"

So the symptom (bare exe stem shown) is gone — the auto-naming chain produces a polished name. Closing.