Issues #99, #77 and #46 — production follow-up, 2026-09-14¶

Historical record. This preserves the source, tests and limitations recorded at the time; it is not current setup guidance. See the documentation index.

This records completed source changes and automated checks. Source fixes and public delivery are separate. The published RC4.6.1 assets are not being replaced. No real installer, reboot, scheduled-task mutation, registry edit, controller session or production updater transaction is used by these checks.

#99 — portable updates must preserve a custom executable name¶

Issue #99 reports that a portable update adds DS4Windows.exe when a custom name is in use. The updater transaction indeed added aliases while retaining the canonical apphost in its replacement list. Its existing custom-name test checked the alias but not the unwanted default executable.

The repair remaps only the application EXE before computing transactional file changes. The canonical DS4Windows.dll, runtime configuration and dependency sidecars remain necessary because renaming the apphost does not rename its embedded assembly target. The downloaded package and its manifest remain intact; installed ownership records the selected name. An already-owned default EXE is removed through the same backed-up transaction. An unowned collision fails before live mutations instead of deleting or overwriting unrelated data.

The launcher resolves the saved name before binding its worker request. The initiating executable and destination are separate immutable identities: old identity before apply, canonical staged identity, selected destination afterward. Both apphost paths and the default path are included in read-only quiescence checks, but the initiating PID/start-time must match the original exact path. This also supports changing or clearing the saved name without requiring a nonexistent new executable to run first. The custom setting is never rewritten; it is locked/rechecked across apply and rollback. Unowned historical aliases are preserved rather than guessed safe to delete.

DS4Windows infrastructure staging also recognizes a custom-only owned apphost. Only the exact manifest-declared, already-validated running host is copied under the canonical name inside protected staging. The live folder remains unchanged; no executable search or weakened package/hash validation is introduced.

Updater x64 Release validation: 358 passed, zero failed, one explicit skip (historical RC4.5.1 archive absent). The actual RC4.6.1 ZIP fixture completed two custom-name transactions and verified all 553 entries, transformed ownership, PE version 5.0.7.0, required canonical dependencies and user-data sentinels. The immutable ZIP hash is 0B5B05E491AA01F6EAC58A33B1742FEA62481F7ABDBBC5EBAAE64BE7E7604541. This requires delivery of a new updater; the published 2.0.6 was not replaced. Deliver it alongside the compatible application staging code (or gate the new layout to a compatible application release); older application code does not understand a custom-only installed apphost manifest.

#46 — settings serialization and extras-only shift behavior¶

Issue #46 describes locale dates, legacy lightbar channels and shift-extras save/load errors. The four original live defects were already corrected in current source. The open PRs were inspected rather than blindly imported. Supported x64/x86 native reference paths are also already correct; AnyCPU/design-time and the constant-eight-slot latent observations are not new production fixes in this pass.

A remaining related live defect was found: extras-only shifted bindings write a trigger attribute, but the reader previously restored triggers only from shifted button/key/macro actions. Such extras lost their activation on reload and could be discarded on a subsequent save. The reader now restores a positive extras trigger when no shifted action supplies one, preserving action-trigger precedence.

The binding editor explicitly supports extras-only shifts, but runtime activation previously required a shifted action. Extras now evaluate their modifier without replacing the ordinary button/key output. Releasing the source or modifier clears the held extras, including when a shifted action has no extras of its own.

Focused DS4Windows validation: 80 passed, zero failed across serialization, actual per-control extras processing, Nintendo mode shifts and custom-host setup staging. Inputs and outputs are synthetic; no desktop injection or controller output is performed. The final integrated full-suite result is recorded below.

#77 — startup preference and post-reboot continuation¶

Issue #77 is not fully fixed by RC4.6.1. Disabled task state still obscures requested startup intent, and scheduleReboot alone does not establish the assumed next-logon Burn resume. The existing alternate-administrator shortcut uses /repair, which normally opens confirmation rather than automatically completing verification. The standalone helper also discards its staged package and requests manual Repair.

Resume staging reads Burn cache metadata only as untrusted routing hints. Windows' default Uninstall registry ACL can grant Terminal Server User writes, so matching registry tags cannot authorize execution. The current Burn engine's immutable provider GUID instead binds the exact native Package Cache/{GUID} directory; the selected executable and every filesystem ancestor must have trusted ownership, no reparse point, and no ordinary-account rights to replace it. The protected snapshot root uses the native Program Files path from HKLM64, not process environment variables. Existing unsafe staging roots fail closed; newly created roots and snapshots receive exact ACLs before executable copies are written.

Focused resolver/recovery validation: 35 passed, zero failed, including a read-only check of the installed RC4.6.1 cache registration and executable, native Program Files ancestry, forged metadata aimed at another bundle's cache, writable-file/owner/ancestor ACLs, and the shared resume state machine. These checks did not run the cached executable or mutate the registry, ACLs, or tasks.

The implementation preserves explicit startup intent separately from temporary disabled state, provides a narrowly scoped protected continuation after the boot changes, and retains driver/USB-IP ABI readiness gates before enabling the original RunDS4Windows and RunVIIPER tasks. No alternate app task names are introduced. A user explicitly disabling startup must remain authoritative.

The implemented preference path records an explicit disable before task removal or elevation. Read failures are visible, not converted to opt-outs. Passive and elevated task repair recheck intent and the deferred setup gate. The UI separates requested startup from active Windows registrations, including pending repair, reboot, alternate-administrator and failed-removal states. Messages name the actual Install / Repair VIIPER button, explain the next action and distinguish manual app opening from verified controller readiness. Technical read errors are logged once when the state changes, not appended to the primary status text. Canceled setup is not falsely described as making no changes.

For affected older installs, an exact owned/current disabled task plus the legacy RebootPending marker can recover requested startup as RepairRequired when no new setup record or explicit preference exists. This does not write settings or invent an automatic continuation that was never staged.

Both installer paths retain a protected, exact package snapshot and stage an ID-only next-logon continuation after result 3010. The claim checks the original account, changed boot, one-attempt record, fixed snapshot path and executable hash before continuing. UAC cancellation leaves a visible manual repair state; an explicit startup opt-out does not cancel already-requested driver repair or enable logon tasks. Only verified owned resume shortcuts are removed; ambiguous legacy shortcuts are preserved along with their cache. Verified old /repair shortcuts are removed before their cached executable, avoiding broken logon links. Optional resume staging/cleanup failures must not turn an otherwise completed installation into rollback.

Two WiX 5.0.2 source details were important:

• scheduleReboot reports restart-required but does not by itself guarantee next-logon continuation. The state-machine fixture now models the later recovery as a separate transaction rather than assuming it runs after 3010.
• WixBundleOriginalSource is persisted and therefore is not current-launch identity. See variable.cpp and cache.cpp. Bundle claims bind the current provider ID instead; the embedded app path still requires its exact executing apphost.

Limits: no real reboot, logon, UAC or installation transaction has been exercised for this change. A currently executing protected snapshot is retained after successful recovery rather than attempting unsafe self-deletion. Preference rechecks close the demonstrated elevation/inspection races, but registry intent and Task Scheduler writes are not a single cross-process atomic transaction; this is not a claim that arbitrary simultaneous external changes are impossible.

Final validation and delivery¶

• DS4Windows x64 Release: 6,081 passed, zero failed, 11 explicitly gated skips. _results/issues-99-77-46-final/issues-99-77-46-final-rerun.trx. The first full run found one source-contract assertion still expecting the old startupEnabled local name. It now checks startupRequested and the explicit requested-preference accessor; the entire suite was rerun successfully.
• Updater x64 Release: 358 passed, zero failed, one historical archive skip.
• SetupActions and Bootstrapper x64 Release builds: zero warnings/errors.
• Installer/localization/release-source validator tests: 32 passed.
• Actual extracted PowerShell startup-registration/rollback/containment checks, backup-file tests, USB-IP reboot-boundary simulation, and the installer state-machine simulation all pass without native setup/task mutations.

These changes are not a published release. DS4Windows RC4.6.1 and updater 2.0.6 remain the public builds; no tag or published asset was replaced. A controlled Windows logon/reboot acceptance test is still required before claiming complete end-to-end validation of automatic setup continuation.