| winget packages | `winget install` on a package winget can see is installed upgrades it when a newer version exists and otherwise does nothing — winget's own default. `--force`, which would install regardless, is never used. |
| `ClaudeCode` | Anthropic's installer always downloads and reinstalls, so `setup-windows-current.ps1` asks first: is `%USERPROFILE%\.local\bin\claude.exe` the latest release — the version the installer's own endpoint names — and the build for this host? Only both skip it. |
| `NASM` | Its per-user fallback install registers nothing, so winget cannot see it and would rerun the installer every time. `setup-windows-current.ps1` compares that `nasm.exe` with the version winget offers. A machine-wide NASM is left to winget. |
+| `Msys2` | The base archive is downloaded only when `%LOCALAPPDATA%\msys64\usr\bin\pacman.exe` is missing. Otherwise `pacman -Syuu` updates what is there, and `pacman -S --needed` leaves the GCC packages alone when they are already installed. |
| `Rustup` | Needs no help: rustup registers itself under the manifest's product code and rewrites its version when it updates itself, so winget sees what is really there. |
| `AndroidStudio` | Installed only when it is missing. Studio updates itself in the app, and winget's package is marked never to upgrade it; the check keeps winget from installing over a Studio it cannot match to its package, as on a box where Studio was installed some other way. |
| `WiX` | Skipped when 5.0.2 is already in the .NET global tool store. |
emulation on ARM64, which every Windows on Arm has; the audit lists it as
expected. It stays on ARM64 for the same reason `iperf3` does: it is bound by
the link to the device, not by the CPU.
+- **MSYS2 and MinGW-w64 GCC** (`Msys2`) go into `%LOCALAPPDATA%\msys64`, per-user,
+ with no elevation: the MSYS2 base self-extracting archive unpacks wherever it
+ is pointed, whereas the winget package runs the installer machine-wide into
+ `C:\msys64`. Two environments get GCC: `ucrt64` (x86_64, links the UCRT) and
+ `mingw32` (i686, links `msvcrt.dll`, the one that can still target Windows XP).
+ These are the same toolchains GitHub's `windows-latest` runner carries, so a
+ build that works here works there. Nothing is added to the `PATH`: the
+ environments' `bin` directories hold same-named `gcc`, `ld` and `windres`, so a
+ project names the one it wants by full path, e.g.
+ `%LOCALAPPDATA%\msys64\mingw32\bin`.
- **Android Studio and the Android SDK** are separate steps. Studio
(`Google.AndroidStudio`) is machine-wide — its installer elevates itself — and
is installed only when missing, since it updates itself. The SDK is per-user,
| `WinMerge.WinMerge` | `setup-windows.bat` | ARM64 ships as a **machine-scope** installer only, so an unelevated `winget` can install nothing but the emulated x64 build |
| `LLVM.LLVM` | `setup-windows.bat` | second Clang, dropped along with VS's `clang-cl` |
| `NASM.NASM` | `setup-windows.bat` | x86/x86-64 assembler with no ARM64 target; MSVC's `armasm64.exe` is the native one |
+| MSYS2 (`Msys2`) | `setup-windows.bat` | its base system is x86_64 and would run emulated, and the Windows XP target it is installed for is x64-box work |
| `Google.AndroidGPUInspector` | `setup-windows.bat` | x64-only, and it profiles Android devices rather than anything compiled here |
| `OpenCppCoverage` | `setup-windows.bat` | collects coverage by stepping x86/x64 instructions, so it cannot instrument an ARM64 binary at all |
| VS Clang/LLVM component | `setup-windows-with-uac.ps1` | see below |
New-SetupStep PlatformTools U bat -Package Google.PlatformTools -Text 'Android SDK Platform-Tools: adb, fastboot (an x86 build)'
New-SetupStep NASM U bat -Package NASM.NASM `
-X64Only 'x86/x64-only assembler; MSVC armasm64 is the native one'
+ # Not winget: its package runs the machine-wide installer into C:\msys64.
+ New-SetupStep Msys2 U bat -Text 'MSYS2 into %LOCALAPPDATA%\msys64 (no admin), with MinGW-w64 GCC: ucrt64 (x64) and mingw32 (i686, msvcrt, for XP targets)' `
+ -X64Only 'its base system is x86_64 (emulated on Arm), and the XP target it is here for is x64-box work'
New-SetupStep VirtualBox U bat -Package Oracle.VirtualBox -Text 'for the Windows 7 test VM' `
-X64Only 'no ARM64 host build, so no Windows 7 x86 test VM either' `
-NotInVM 'the test VMs belong on the physical host, not nested in a guest'
if not "%ERRORLEVEL%"=="0" call :winget NASM NASM.NASM\r
:after_nasm\r
\r
+@rem MSYS2, per-user, for the MinGW-w64 GCC toolchains - the same ones GitHub's\r
+@rem windows-latest runner carries under C:\msys64, so a build that works here\r
+@rem works there. Two environments are installed:\r
+@rem ucrt64 x86_64, links the UCRT - the modern target\r
+@rem mingw32 i686, links msvcrt.dll - the one that can still target\r
+@rem Windows XP\r
+@rem\r
+@rem Not through winget: the MSYS2.MSYS2 package runs the GUI installer, which\r
+@rem installs machine-wide into C:\msys64 by default. The self-extracting\r
+@rem archive (7-Zip SFX) needs no elevation and unpacks wherever it is pointed,\r
+@rem here %LOCALAPPDATA%\msys64. Nothing is put on the PATH on purpose: the\r
+@rem environments' bin directories carry same-named exes (gcc, ld, windres) and\r
+@rem a project picks one by its full path, e.g. %LOCALAPPDATA%\msys64\mingw32\bin.\r
+@rem\r
+@rem Re-running: the archive is downloaded only when pacman is missing; otherwise\r
+@rem `pacman -Syu` updates what is there and `--needed` leaves installed packages\r
+@rem alone. The first -Syu after a fresh unpack may replace the MSYS2 runtime and\r
+@rem end the shell on purpose, which is why it runs twice.\r
+call :want Msys2 || goto :after_msys2\r
+set "MSYS2_ROOT=%LOCALAPPDATA%\msys64"\r
+if exist "%MSYS2_ROOT%\usr\bin\pacman.exe" goto :msys2_packages\r
+echo [setup-windows] Msys2: downloading the MSYS2 base archive\r
+"%PS64%" -NoProfile -ExecutionPolicy Bypass -Command "$ProgressPreference='SilentlyContinue'; Invoke-WebRequest -Uri 'https://github.com/msys2/msys2-installer/releases/latest/download/msys2-base-x86_64-latest.sfx.exe' -OutFile \"$env:TEMP\msys2-base.sfx.exe\""\r
+if not exist "%TEMP%\msys2-base.sfx.exe" ( echo [setup-windows] Msys2: download failed & goto :after_msys2 )\r
+echo [setup-windows] Msys2: unpacking into %MSYS2_ROOT%\r
+"%TEMP%\msys2-base.sfx.exe" -y -o"%LOCALAPPDATA%" >nul\r
+del /q "%TEMP%\msys2-base.sfx.exe" 2>nul\r
+if not exist "%MSYS2_ROOT%\usr\bin\pacman.exe" ( echo [setup-windows] Msys2: unpack failed & goto :after_msys2 )\r
+@rem First start: creates the home directory and the key ring.\r
+"%MSYS2_ROOT%\usr\bin\bash.exe" -lc "true"\r
+:msys2_packages\r
+echo [setup-windows] Msys2: updating the base system\r
+"%MSYS2_ROOT%\usr\bin\bash.exe" -lc "pacman -Syuu --noconfirm"\r
+"%MSYS2_ROOT%\usr\bin\bash.exe" -lc "pacman -Syuu --noconfirm"\r
+echo [setup-windows] Msys2: MinGW-w64 GCC for ucrt64 and mingw32\r
+"%MSYS2_ROOT%\usr\bin\bash.exe" -lc "pacman -S --noconfirm --needed mingw-w64-ucrt-x86_64-gcc mingw-w64-i686-gcc"\r
+"%MSYS2_ROOT%\mingw32\bin\gcc.exe" --version | findstr /i "gcc" && echo [setup-windows] Msys2: mingw32 gcc ready in %MSYS2_ROOT%\mingw32\bin\r
+"%MSYS2_ROOT%\ucrt64\bin\gcc.exe" --version | findstr /i "gcc" && echo [setup-windows] Msys2: ucrt64 gcc ready in %MSYS2_ROOT%\ucrt64\bin\r
+:after_msys2\r
+\r
@rem VirtualBox has no ARM64 Windows host build, and the x64 one cannot be made to\r
@rem work by emulation: a hypervisor is kernel-mode, and its x64 driver will not\r
@rem load on an ARM64 kernel. Installing it on ARM64 gets you a broken product and\r
vilimpoc.org / repos / dotfiles / commitdiff