dotfiles: fix two architecture bugs a real ARM64 run exposed

[dotfiles] / setup-windows.bat

diff --git a/setup-windows.bat b/setup-windows.bat
index 05e65eb822507a0f536a6d41a67a0e0cc5669eb4..b9e47529fe28e08d6d4164e51802df397e2749a5 100644 (file)
--- a/setup-windows.bat
+++ b/setup-windows.bat
@@ -47,7 +47,25 @@ winget install Git.Git
 winget install Microsoft.DotNet.SDK.10\r
 winget install Microsoft.PowerShell Microsoft.Sysinternals.ProcessExplorer Microsoft.Sysinternals.ProcessMonitor Microsoft.Sysinternals.SDelete Microsoft.VisualStudioCode Microsoft.WindowsTerminal\r
 winget install Python.Python.3.13\r
-winget install WinMerge.WinMerge\r
+\r
+@rem WinMerge is the one package here where winget's own preference order picks\r
+@rem the WRONG architecture, and it is worth knowing why: upstream publishes the\r
+@rem ARM64 build as a MACHINE-scope installer (WinMerge-<ver>-ARM64-Setup.exe) and\r
+@rem the x64 build as a PER-USER one (WinMerge-<ver>-x64-PerUser-Setup.exe). Run\r
+@rem unelevated, winget's scope preference beats its architecture preference and\r
+@rem you silently get the emulated x64 build.\r
+@rem\r
+@rem So ask for arm64 explicitly, and fall back to the default when that cannot be\r
+@rem installed - which is exactly the standard-user case, where the machine-scope\r
+@rem installer has nowhere to go. The fallback is the x64 build under emulation:\r
+@rem a diff tool is not a hot path, and a working WinMerge beats none. The\r
+@rem architecture audit at the end of setup-windows-no-uac.ps1 reports which one\r
+@rem you ended up with.\r
+if "%IS_ARM64%"=="1" (\r
+    winget install WinMerge.WinMerge --architecture arm64 || winget install WinMerge.WinMerge\r
+) else (\r
+    winget install WinMerge.WinMerge\r
+)\r
 \r
 @rem --- Build drivers, standalone and native ---\r
 @rem\r