fix(windows): remove the bundled installer and uninstaller (#466)

[PathGao]

Closes #466. Implements the route you picked in #466 (comment) — strip the install/uninstall code and let NSIS own it.

What the scanner reacts to

The uninstall path in setup.rs wrote a batch file to %TEMP%, wrote a .vbs that ran it with a hidden window and then deleted itself, and launched the pair through wscript.exe. Hidden script → self-delete → launch an executable is close to the definition of Trojan:Win32/Wacatac.B!ml, which scores behaviour rather than matching a signature. Each property had a reason (the batch waits on the PID rather than the image name so a portable copy survives an uninstall, #358), but the shape is what gets scored — so the only thing that clears it is removing the shape.

The install half was already dead code

get_app_mode entered installer mode only on a filename containing installer or an explicit --install, and #355 stopped publishing any installer-named artifact. Nothing shipped could reach install_app, create_shortcut, check_install_status or Installer.svelte. Removing them changes no observable behaviour for anyone on 2.7.0.

The uninstall half needed a migration — and it turned out not to need a Windows box

I asked you to verify on Windows whether the updater's /UPDATE run still writes the registry entry. That question doesn't arise. Reading the bundler template at the version that built 2.7.0 (tauri-cli-v2.9.6):

Section Install = lines 614..717
  line 682   WriteRegStr SHCTX "${UNINSTKEY}" "UninstallString" "$INSTDIR\uninstall.exe"
  occurrences of $UpdateMode inside 614..717:  0

The write isn't behind a mode check at all — the $UpdateMode guards in that file sit in Section WebView2 and Section Uninstall. So it lands whether or not /UPDATE is passed.

Both sides also address the same key: the custom installer used APP_NAME (setup.rs:47) and the template uses ${PRODUCTNAME} (:58), and both are Markpad.

One gap is left, and the hook closes it. Section Install writes through SHCTX, so an old install that chose the other hive keeps a second Add/Remove Programs row pointing at a command the binary no longer answers. MARKPAD_DROP_LEGACY_UNINSTALL_ENTRY checks both hives and deletes the key only when the value ends in --uninstall — a tail only the custom installer ever wrote, so it cannot match an entry this installer owns. DeleteRegKey under HKLM without elevation is a silent no-op, which is why there is also a backstop in the binary: a stray --uninstall hands off to uninstall.exe beside it and exits, and starts normally if there is none.

Also

• Drops mslnk and chrono — setup.rs was their only user.
• Signing would not have fixed this. A certificate addresses SmartScreen reputation, not a behaviour classifier's score. The same distinction applies to macOS: file-access permission not persisted on save (release is ad-hoc signed / not notarized) #209 on the macOS side, where notarization fixes quarantine and the TCC grant but not a heuristic detection.
• This also settles The portable and installer executables are the same binary, and re-running the installer after install silently opens the app #395, which was open on exactly this question.

Verification

npm run check 646 files 0 errors · npm test 728/728 · cargo test 125/125.

The Rust count is down 32 from master, which is exactly the number of #[test] inside the deleted setup.rs — the tests went with the code they covered, and nothing else moved.

What I could not verify here, stated plainly:

• forward_legacy_uninstall is #[cfg(target_os = "windows")], so a macOS cargo check does not compile it. I type-checked it separately against x86_64-pc-windows-msvc. It has not been run.
• The NSIS macro cannot be compiled on macOS at all. makensis runs in the Windows build-test leg, so a malformed macro fails there — please treat that leg as the real check on the hook.
• Nobody has run an actual 2.6.x → 2.7.1 upgrade and read the registry afterwards. The argument above is from the template source, not from an observation.

🤖 Generated with Claude Code