X-Git-Url: https://vilimpoc.org/repos/dotfiles/blobdiff_plain/3e0aa9fcdd4d04bd4d0714668af9af5fd200cb42..f51da37a77ac790110def9697b57f49b821c4c75:/setup-windows-no-uac.ps1 diff --git a/setup-windows-no-uac.ps1 b/setup-windows-no-uac.ps1 index 3b67f0f..27f7a0e 100644 --- a/setup-windows-no-uac.ps1 +++ b/setup-windows-no-uac.ps1 @@ -11,15 +11,13 @@ elevated would configure the *administrator's* profile instead of yours. What this installs / configures: - - WinMerge on the user PATH + - WinMerge on the user PATH (x64 only) - vswhere.exe on the user PATH: the Visual Studio installer puts it in %ProgramFiles(x86)%\Microsoft Visual Studio\Installer, which nothing adds to the PATH, so build scripts (and VsDevCmd.bat itself) complain that 'vswhere.exe' is not recognized - BinSkim (binary hardening analyzer) in %LOCALAPPDATA%\Programs\BinSkim, - on the user PATH. The package has no win-arm64 build, so on ARM64 this is - the x64 tool under emulation - which analyses ARM64 binaries fine, since it - only reads their headers. + on the user PATH (x64 only - the NuGet package publishes win-x64 alone) - Global git identity, and core.sshCommand pointed at a Win32-OpenSSH client so git shares the Windows ssh-agent: the fast ssh.exe the elevated half unpacks beside rsync.exe if it is there, the in-box one otherwise @@ -40,17 +38,42 @@ param( # for several, dot-call the script or use -Command: # .\setup-windows-no-uac.ps1 -Skip BinSkim,GitConfig # powershell -File .\setup-windows-no-uac.ps1 -Skip BinSkim - [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'NinjaPath', 'ArchAudit')] + [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'NinjaPath', 'LlvmPath', 'ArchAudit')] [string[]] $Skip = @() ) $ErrorActionPreference = 'Stop' -# Host architecture. RuntimeInformation rather than PROCESSOR_ARCHITECTURE: an -# emulated PowerShell reports the emulated architecture in the environment -# variable while this API reports the real one. Values: X64, Arm64, X86. -$HostArch = [Runtime.InteropServices.RuntimeInformation]::OSArchitecture.ToString() -$IsArm64 = ($HostArch -eq 'Arm64') +# Host architecture, from the machine environment in the registry. Both of the +# obvious sources report the EMULATED architecture inside an emulated x64 +# PowerShell - which is what `powershell` resolves to when launched from an x64 +# shell on an ARM64 box. Measured on this machine: +# [RuntimeInformation]::OSArchitecture X64 <- wrong +# $env: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, so it is kept only as a fallback. +# $IsArm64 decides which steps run at all, so this has to be the real one. +$rawArch = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -ErrorAction SilentlyContinue).PROCESSOR_ARCHITECTURE +if (-not $rawArch) { $rawArch = [Runtime.InteropServices.RuntimeInformation]::OSArchitecture.ToString() } +$IsArm64 = ($rawArch -eq 'ARM64') +$HostArch = if ($IsArm64) { 'Arm64' } elseif ($rawArch -eq 'AMD64') { 'X64' } else { $rawArch } + +# Steps that do not run on ARM64, with the reason printed in place of the step. +# +# The ARM64 machine is provisioned as a single-compiler build box - see the +# x64-only set in setup-windows.bat - so the packages these three steps wire up +# are not installed there. Skipping the step rather than letting it find nothing +# matters: Install-BinSkim would happily download and PATH the x64 build, and +# Add-LlvmToUserPath is the step that put an emulated-adjacent toolchain on the +# PATH ahead of MSVC in the first place. +# +# -Skip still works on top of this; it can only subtract. +$Arm64Dropped = [ordered]@{ + WinMerge = 'not installed on ARM64 - the only build an unelevated winget can fetch is the emulated x64 one' + BinSkim = 'not installed on ARM64 - the NuGet package publishes win-x64 only' + LlvmPath = 'not installed on ARM64 - this box carries MSVC alone' +} # --- Global git identity: FILL THESE IN BEFORE RUNNING --- # Left empty, Set-GlobalGitConfig skips the identity and says so, rather than @@ -421,6 +444,51 @@ function Set-NativeNinjaFirst { Add-ToUserPath (Split-Path $native -Parent) -Prepend } +function Add-LlvmToUserPath { + # Put the upstream LLVM's bin directory on the user PATH. + # + # Two reasons this needs a step rather than trusting the installer: + # + # 1. WHERE IT LANDS. LLVM's NSIS installer targets %ProgramFiles%\LLVM, and + # when it cannot write there - a standard user, no elevation - it does not + # fail. It silently falls back to a per-user directory, observed as + # %USERPROFILE%\Documents\LLVM, and winget still reports "Successfully + # installed". So the package is registered, the compiler is genuinely + # there and native, and nothing can find it. + # 2. PATH. The installer's "add to PATH" option is not taken in a silent + # install, so clang-cl is not a command afterwards either way. + # + # Appended, not prepended: this is a second compiler kept deliberately + # alongside MSVC, and it should not quietly win a `clang-cl` that some script + # meant for Visual Studio's copy. Note VS does NOT put its own + # VC\Tools\Llvm on the PATH (its clang-cl is reached through CMake's + # -T ClangCL), so there is no collision to lose here. + Write-Step 'Upstream LLVM on the user PATH' + $candidates = @( + (Join-Path $env:ProgramFiles 'LLVM\bin') + (Join-Path ${env:ProgramFiles(x86)} 'LLVM\bin') + (Join-Path $env:LOCALAPPDATA 'Programs\LLVM\bin') + (Join-Path ([Environment]::GetFolderPath('MyDocuments')) 'LLVM\bin') + (Join-Path $env:USERPROFILE 'Documents\LLVM\bin') + ) + $dir = $candidates | Where-Object { Test-Path (Join-Path $_ 'clang-cl.exe') } | Select-Object -First 1 + if (-not $dir) { + Write-Host ' Not installed (winget install LLVM.LLVM); Visual Studio''s own clang-cl is unaffected.' -ForegroundColor DarkGray + return + } + $exe = Join-Path $dir 'clang-cl.exe' + $mach = Get-PEMachine $exe + Write-Host " $exe ($mach)" + if ($IsArm64 -and $mach -ne 'ARM64') { + Write-Warning "This LLVM is $mach, not ARM64. winget install LLVM.LLVM should resolve to the -woa64 build on this host." + } + if ($dir -notmatch [regex]::Escape($env:ProgramFiles)) { + Write-Host ' Note: not under Program Files - the installer fell back to a per-user' -ForegroundColor Yellow + Write-Host ' location because it could not write there. Re-run elevated for a machine-wide install.' -ForegroundColor Yellow + } + Add-ToUserPath $dir +} + function Get-PEMachine { # Architecture of a PE, read straight from the COFF header: the 2 bytes at # the e_lfanew offset + 4. Cheap, and it answers the only question that @@ -493,11 +561,16 @@ function Invoke-ArchAudit { # Tools with no native ARM64 build available anywhere, with the reason. These # print as expected rather than as problems - see the README's ARM64 section. + # + # Shorter than it was: BinSkim, OpenCppCoverage and NASM used to be listed + # here as accepted emulation, and are now simply not installed on ARM64. That + # is the whole shape of the change - the exceptions that were tolerable one at + # a time added up to a VM full of x64 binaries. + # + # rsync came off this list when the release started publishing an arm64 + # asset. An x64 rsync.exe on an ARM64 box is now a leftover from a run before + # that, not an accepted exception, so it warns and gets a remedy below. $KnownEmulated = @{ - 'BinSkim.exe' = 'NuGet package publishes win-x64 only; it reads PE headers, so it still analyses ARM64 binaries' - 'rsync.exe' = 'no ARM64 asset published; transfer is socket-bound, not CPU-bound' - 'OpenCppCoverage.exe' = 'x86/x64 only, and cannot instrument ARM64 binaries - run coverage against the x64 build' - 'nasm.exe' = 'x86/x86-64 assembler by definition; ARM64 uses armasm64.exe from MSVC' 'iperf3.exe' = 'no ARM64 build published; network-bound anyway' 'py.exe' = 'python.org ships the launcher shim as x86; it execs the native python.exe' 'vswhere.exe' = 'Microsoft ships x86 only; runs once per script' @@ -511,10 +584,15 @@ function Invoke-ArchAudit { # even on ARM64, and it is re-invoked for every edge in the build graph, so # an emulated one is paid over and over rather than once. The NinjaPath step # puts the native copy first; this is the check that it worked. + # + # Only two left, and both are for tools ARM64 still installs. The clang-cl and + # WinMerge remedies were removed with their rows: advising an install that the + # x64-only set has just declined to do would be the audit arguing with the + # provisioning. $Remedies = @{ - 'ninja.exe' = 'Visual Studio bundles an x64 ninja. Install the native one (winget install Ninja-build.Ninja) and re-run - the NinjaPath step puts its directory at the front of the user PATH.' - 'cmake.exe' = 'Install the native build with: winget install Kitware.CMake' - 'clang-cl.exe' = 'Install the upstream native LLVM with: winget install LLVM.LLVM' + 'ninja.exe' = 'Visual Studio bundles an x64 ninja. Install the native one (winget install Ninja-build.Ninja) and re-run - the NinjaPath step puts its directory at the front of the user PATH.' + 'cmake.exe' = 'Install the native build with: winget install Kitware.CMake (its MSI is machine-scope, so it needs an administrator).' + 'rsync.exe' = 'Left over from before the release published an arm64 asset. Re-run setup-windows-with-uac.ps1 as an administrator to replace it, and the ARM64 ssh.exe beside it, with the native build.' } $vs = $null @@ -527,11 +605,21 @@ function Invoke-ArchAudit { $targets = [ordered]@{ 'git.exe' = @("$env:LOCALAPPDATA\Programs\Git\cmd\git.exe", (Join-Path $env:ProgramFiles 'Git\cmd\git.exe')) 'python.exe' = @() - 'py.exe' = @("$env:WINDIR\py.exe") + # Both homes of the launcher: C:\Windows for an all-users install, the + # per-user Launcher directory otherwise. Often neither - it is a separate + # component from the interpreter, and "- not installed" here next to a + # native python.exe is the normal result of an unelevated Python install. + 'py.exe' = @("$env:WINDIR\py.exe", "$env:LOCALAPPDATA\Programs\Python\Launcher\py.exe") 'pwsh.exe' = @() 'cmake.exe' = @((Join-Path $env:ProgramFiles 'CMake\bin\cmake.exe')) 'ninja.exe' = @() - 'clang-cl.exe' = @((Join-Path $env:ProgramFiles 'LLVM\bin\clang-cl.exe')) + # Upstream LLVM. The Documents path is not a typo - see Add-LlvmToUserPath + # for why an unelevated install lands there. + 'clang-cl.exe' = @( + (Join-Path $env:ProgramFiles 'LLVM\bin\clang-cl.exe') + (Join-Path $env:LOCALAPPDATA 'Programs\LLVM\bin\clang-cl.exe') + (Join-Path ([Environment]::GetFolderPath('MyDocuments')) 'LLVM\bin\clang-cl.exe') + ) 'dotnet.exe' = @((Join-Path $env:ProgramFiles 'dotnet\dotnet.exe')) 'WinMergeU.exe' = @((Join-Path $env:ProgramFiles 'WinMerge\WinMergeU.exe'), (Join-Path ${env:ProgramFiles(x86)} 'WinMerge\WinMergeU.exe')) 'BinSkim.exe' = @((Join-Path $BinSkimDir 'BinSkim.exe')) @@ -556,14 +644,39 @@ function Invoke-ArchAudit { $targets['clang-cl.exe (VS)'] = @((Join-Path $vs "VC\Tools\Llvm\$llvmHost\clang-cl.exe")) } + # Tools this box does not provision on ARM64. Dropped from the audit rather + # than left to print "- not installed", because that line reads as a gap in + # the provisioning when it is the provisioning working as intended - and a + # dull audit is one you keep reading. + # + # The rows survive on x64, where all of these are installed and expected. + # Anything still on disk from before the split shows up in the winget list, + # not here. + if ($IsArm64) { + foreach ($gone in 'WinMergeU.exe', 'BinSkim.exe', 'nasm.exe', + 'OpenCppCoverage.exe', 'clang-cl.exe', 'clang-cl.exe (VS)') { + $targets.Remove($gone) + } + } + $native = if ($IsArm64) { 'ARM64' } else { 'x64' } $unexpected = @() foreach ($name in $targets.Keys) { - # PATH first - that is the binary a build would actually invoke - then the - # explicit candidates. The bare exe name is stripped of any " (label)". - $exe = ($name -split ' ')[0] - $path = Resolve-OnPath $exe - if (-not $path) { $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 } + # A LABELLED entry - "clang-cl.exe (VS)" - names one specific copy, so it + # is resolved ONLY from its explicit candidates. Falling back to the PATH + # there would silently answer with a different installation of the same + # tool: with upstream LLVM on the PATH, the "(VS)" row reported the + # upstream compiler and so claimed Visual Studio's was present when it was + # not. Unlabelled entries still resolve PATH-first, because for those the + # question is which binary a build would actually invoke. + $exe = ($name -split ' ')[0] + $isPinned = $name -ne $exe + if ($isPinned) { + $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 + } else { + $path = Resolve-OnPath $exe + if (-not $path) { $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 } + } if (-not $path) { Write-Host (" {0,-22} {1}" -f $name, '- not installed') -ForegroundColor DarkGray; continue } $mach = Get-PEMachine $path @@ -605,6 +718,7 @@ $steps = [ordered]@{ BinSkim = { Install-BinSkim } GitConfig = { Set-GlobalGitConfig } NinjaPath = { Set-NativeNinjaFirst } + LlvmPath = { Add-LlvmToUserPath } # Last on purpose: it reports on what the steps above (and the winget installs # in setup-windows.bat) actually put on the box. ArchAudit = { Invoke-ArchAudit } @@ -616,6 +730,10 @@ foreach ($name in $steps.Keys) { Write-Host "`n==> $name (skipped)" -ForegroundColor DarkGray continue } + if ($IsArm64 -and $Arm64Dropped.Contains($name)) { + Write-Host "`n==> $name (skipped: $($Arm64Dropped[$name]))" -ForegroundColor DarkGray + continue + } try { & $steps[$name] } catch {