X-Git-Url: https://vilimpoc.org/repos/dotfiles/blobdiff_plain/3e0aa9fcdd4d04bd4d0714668af9af5fd200cb42..fbe899b67d263a1ae5404d3ed25f5f091c3d2c1e:/setup-windows.bat?ds=sidebyside

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