From: Max Vilimpoc Date: Sun, 6 Sep 2026 06:32:10 +0000 (+0200) Subject: dotfiles: split provisioning between x64 and ARM64 X-Git-Url: https://vilimpoc.org/repos/dotfiles/commitdiff_plain/7840e3c2b0c54c1d49bd2aa7c717892e8a3669e7?ds=sidebyside;hp=7840e3c2b0c54c1d49bd2aa7c717892e8a3669e7 dotfiles: split provisioning between x64 and ARM64 The ARM64 machine is a small VM, and nearly everything it installed without a native build ran under Prism emulation. Each exception was defensible on its own; together they were a VM full of x64 binaries. So the two architectures now provision different things on purpose. x64 is the full workstation. ARM64 gets MSVC and nothing that duplicates it or exists only as an x64 binary: Brave, WinMerge, upstream LLVM, NASM, Android GPU Inspector, OpenCppCoverage, BinSkim, Visual Studio's clang-cl, and the WDK are all dropped there. :x64only in the batch file is the single place the policy is applied, so every skip prints its reason into the run log instead of leaving a silent gap. Two of those are dropped by choice rather than limitation, and the comments say so: a native ARM64 clang-cl is offered on Arm and worked here before this change. The WDK could not have installed anyway, which is worth recording. It requires the matching Windows SDK revision, and revisions are not side-by-side - Include\10.0.26100.0 is one directory whichever wrote it. VS 2026 installs SDK 26100.7705; linkid=2335869 is WDK 26100.6584, the kit paired with VS 2022. wdksetup.exe /quiet therefore aborts with exit 15605 and WER "WDK / 10.1.26100.6584 / Install / 0x80070642" - 0x642 is 1602, ERROR_INSTALL_USEREXIT, a silent install cancelling itself on a failed prerequisite. Nothing to do with Arm; the same pairing fails on x64. Fix the architecture detection, which this change makes load-bearing. Both sources the scripts trusted report the EMULATED architecture inside an emulated x64 process - which is what `powershell` resolves to when launched from an x64 shell on an ARM64 box. Measured there: [RuntimeInformation]::OSArchitecture X64 wrong %PROCESSOR_ARCHITECTURE% AMD64 wrong HKLM\...\Session Manager\Environment ARM64 right OSArchitecture is documented as the OS's architecture, and on .NET Core it is; under .NET Framework on Prism it is not. All three scripts now read the registry and keep the old sources as a fallback. This was a mislabelled log line before; now it decides which packages install at all. The batch parses reg.exe without piping to find/findstr - both are shadowable, and a POSIX find turns the detection into a silent no-op that leaves the emulated answer standing. Stop invoking `py`, which failed with "'py' is not recognized" for two independent reasons that look identical at the prompt. The session inherits its PATH before winget installs Python, so nothing winget adds is visible - the same staleness the DOTNET_EXE lookup already handles. And the launcher may not exist: on this box every other Python component registered while no launcher did, and the Launcher directory is on the user PATH but absent. Resolve an interpreter by full path instead, preferring the launcher only when it is real, and require python.exe inside the directory - a half-removed version leaves the folder behind with only Doc and Lib, which is what this box has. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ak6VzfGyaocrykX1LhNMwt ---