Elevated portion of the Windows provisioning. Invoked by setup-windows.bat\r
via Start-Process -Verb RunAs, or run manually from an Administrator prompt.\r
\r
+ Its steps are the 'uac' rows of setup-windows-steps.ps1. The batch file runs it\r
+ with -Only <the steps its plan left selected> -Yes, having already asked. Run\r
+ by hand, it lists what it will do and asks before doing any of it:\r
+\r
+ .\setup-windows-with-uac.ps1 all of it, after asking\r
+ .\setup-windows-with-uac.ps1 -Only VisualStudio,Wdk just these\r
+ .\setup-windows-with-uac.ps1 -Skip VTune -Yes without asking\r
+\r
What this installs / configures:\r
- OpenSSH Client capability (the ssh.exe rsync shells out to, and the\r
System32 libcrypto.dll the release's own ssh.exe links against)\r
What changes is called out at each step, and $HostArch below is what drives it.\r
#>\r
\r
+[CmdletBinding()]\r
+param(\r
+ # Step names from setup-windows-steps.ps1, comma-separated. `powershell -File`\r
+ # hands "A,B" to an array parameter as one string; it is split, so both work.\r
+ [string[]] $Only,\r
+ [string[]] $Skip = @(),\r
+ # Do not ask first. setup-windows.bat passes it, having asked already.\r
+ [switch] $Yes\r
+)\r
+\r
$ErrorActionPreference = 'Stop'\r
\r
# ---------------------------------------------------------------------------\r
# under .NET Framework on Prism it is not, so it is kept only as a fallback.\r
#\r
# $IsArm64 gates:\r
+# - which steps run at all. VsClang, VsWinXP and Wdk are x64-only, and that is\r
+# decided in setup-windows-steps.ps1 (-X64Only, with the reason the plan\r
+# shows); the comments at each step here carry the full reasoning. In short:\r
+# the v141/XP toolset has no ARM64-hosted compiler and Microsoft does not\r
+# ship Windows XP targeting for Arm hosts; Clang/LLVM and the WDK are out by\r
+# policy rather than by limitation - both are available and native on Arm\r
# - which rsync-windows release zip is fetched (x86 / x64 / arm64, all native)\r
# - which Visual Studio generation is driven ($VsChannel: 18 on Arm, 17 on x64)\r
-# - the Visual Studio component groups: ARM64 build tools in; the v141/XP\r
-# toolset out because it has no ARM64-hosted compiler and Microsoft does not\r
-# ship Windows XP targeting for Arm hosts; Clang/LLVM and the WDK VSIX out by\r
-# policy rather than by limitation - both are available and native on Arm\r
-# - whether the Windows Driver Kit is installed at all\r
-# - what the VTune and WPT steps report\r
+# - the base Visual Studio components: ARM64 build tools in, the WDK VSIX out\r
+# - what the verification, VTune and WPT steps report\r
# ---------------------------------------------------------------------------\r
$rawArch = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -ErrorAction SilentlyContinue).PROCESSOR_ARCHITECTURE\r
if (-not $rawArch) { $rawArch = [Runtime.InteropServices.RuntimeInformation]::OSArchitecture.ToString() }\r
Select-Object -First 1\r
}\r
\r
+function Test-VsHasComponents([string[]] $Ids) {\r
+ # True when the Visual Studio this script drives already has every one of\r
+ # these workload / component ids. vswhere's -requires matches only an\r
+ # instance that has ALL of them (checked: one id it does not have, and the\r
+ # instance is not returned), and it is scoped to $VsChannel the same way\r
+ # Get-VsInstallPath is, so the answer is about the install the passes target.\r
+ if (-not $Ids -or -not $script:InstallPath -or -not (Test-Path $script:VsWhere)) { return $false }\r
+ $range = "[$script:VsChannel.0,$($script:VsChannel + 1).0)"\r
+ $found = & $script:VsWhere -products '*' -version $range -requires $Ids -property installationPath -format value\r
+ @($found) -contains $script:InstallPath\r
+}\r
+\r
function Invoke-VsModify {\r
# Run one VS install/modify pass for a named group of components. Splitting\r
# the install into separate passes makes it obvious WHICH group fails: each\r
Write-Host ' (no components in this group for this architecture - skipping)' -ForegroundColor DarkGray\r
return\r
}\r
+ # Everything already there: running the installer would change nothing and\r
+ # cost minutes. This script never UPDATES Visual Studio - `modify` adds\r
+ # components, it does not move the product version - so skipping loses\r
+ # nothing. Updates come from the Visual Studio Installer, as always.\r
+ if (Test-VsHasComponents $Ids) {\r
+ Write-Host " All $($Ids.Count) components already installed in $script:InstallPath; not running the installer."\r
+ return\r
+ }\r
$addStr = ($Ids | ForEach-Object { "--add $_" }) -join ' '\r
# --installPath must be quoted: it contains spaces ("C:\Program Files\...").\r
# Windows PowerShell 5.1's Start-Process does not quote array elements, so we\r
if (-not $script:InstallPath) { $script:InstallPath = Get-VsInstallPath }\r
}\r
\r
+# ---------------------------------------------------------------------------\r
+# Which steps to take\r
+#\r
+# The steps, and which of them cannot run on this machine, come from the 'uac'\r
+# rows of setup-windows-steps.ps1 - the same catalog setup-windows.bat builds its\r
+# plan from. The plan is printed first, inside the transcript, so the log the\r
+# batch file shows afterwards starts with what this half was asked to do.\r
+#\r
+# Every section below is gated on Test-SetupStep with its catalog Id, which also\r
+# records that it was asked. Both kinds of disagreement with the catalog are\r
+# loud: an Id the catalog does not have throws where it is used, and a selected\r
+# step that no section ever asks about fails the run at the end rather than\r
+# letting "All done." cover a step that was never taken.\r
+# ---------------------------------------------------------------------------\r
+. (Join-Path $PSScriptRoot 'setup-windows-steps.ps1')\r
+\r
+# Elevation is a given here (#Requires above), so nothing is blocked on it.\r
+$Plan = @(Resolve-SetupSelection -Steps @(Get-SetupCatalog -IsArm64 $IsArm64 | Where-Object Runner -eq 'uac') `\r
+ -Only $(if ($PSBoundParameters.ContainsKey('Only')) { $Only } else { $null }) -Skip $Skip `\r
+ -IsArm64 $IsArm64 -Elevation 'ALREADY')\r
+$StepIds = @($Plan | ForEach-Object { $_.Id })\r
+$RunSteps = @($Plan | Where-Object Selected | ForEach-Object { $_.Id })\r
+$AskedSteps = New-Object 'System.Collections.Generic.HashSet[string]' ([StringComparer]::OrdinalIgnoreCase)\r
+\r
+function Test-SetupStep([string] $Id) {\r
+ if ($script:StepIds -notcontains $Id) {\r
+ throw "Test-SetupStep: '$Id' is not a setup-windows-with-uac.ps1 step in setup-windows-steps.ps1."\r
+ }\r
+ [void]$script:AskedSteps.Add($Id)\r
+ $script:RunSteps -contains $Id\r
+}\r
+\r
# ---------------------------------------------------------------------------\r
# This runs in a separate elevated window that closes the moment it exits, so\r
# the non-elevated caller (setup-windows.bat) can't see what happened. Mirror\r
\r
try {\r
\r
+Write-SetupPlan $Plan "Plan for setup-windows-with-uac.ps1 (host: $HostArch)"\r
+if (-not $RunSteps) {\r
+ Write-Host ' Nothing selected, so there is nothing to do.'\r
+ exit 0\r
+}\r
+# From the batch file, -Yes: the question was asked before anything ran. By\r
+# hand, ask now. Either way `exit` here still runs the finally below, so the\r
+# transcript is closed and its ACL relaxed.\r
+$ok = Confirm-SetupPlan -Yes:$Yes -Count $RunSteps.Count\r
+if ($ok -ne $true) { exit $(if ($null -eq $ok) { 2 } else { 0 }) }\r
+\r
Write-Step "Host architecture: $HostArch"\r
if ($IsArm64) {\r
# x64 emulation ("Prism") is what carries every x64-only tool this script\r
# Non-fatal, like the server half below: a box that cannot have it should still\r
# finish provisioning.\r
# ---------------------------------------------------------------------------\r
-Write-Step 'OpenSSH Client'\r
-try {\r
- $sshc = Get-WindowsCapability -Online -Name 'OpenSSH.Client*' |\r
- Select-Object -First 1\r
- if (-not $sshc) {\r
- Write-Warning 'OpenSSH.Client capability not offered by this Windows image - skipping.'\r
- } elseif ($sshc.State -eq 'Installed') {\r
- Write-Host " OK: $($sshc.Name) already installed"\r
- } else {\r
- Write-Host " Installing $($sshc.Name) ..."\r
- $r = Add-WindowsCapability -Online -Name $sshc.Name\r
- if ($r.RestartNeeded) { Write-Host ' [reboot required after OpenSSH Client]' -ForegroundColor Yellow }\r
+if (Test-SetupStep 'OpenSshClient') {\r
+ Write-Step 'OpenSSH Client'\r
+ try {\r
+ $sshc = Get-WindowsCapability -Online -Name 'OpenSSH.Client*' |\r
+ Select-Object -First 1\r
+ if (-not $sshc) {\r
+ Write-Warning 'OpenSSH.Client capability not offered by this Windows image - skipping.'\r
+ } elseif ($sshc.State -eq 'Installed') {\r
+ Write-Host " OK: $($sshc.Name) already installed"\r
+ } else {\r
+ Write-Host " Installing $($sshc.Name) ..."\r
+ $r = Add-WindowsCapability -Online -Name $sshc.Name\r
+ if ($r.RestartNeeded) { Write-Host ' [reboot required after OpenSSH Client]' -ForegroundColor Yellow }\r
+ }\r
+ } catch {\r
+ Write-Warning "OpenSSH Client setup failed: $($_.Exception.Message)"\r
}\r
-} catch {\r
- Write-Warning "OpenSSH Client setup failed: $($_.Exception.Message)"\r
}\r
\r
# ---------------------------------------------------------------------------\r
# SSH agent\r
# ---------------------------------------------------------------------------\r
-Write-Step 'Enabling ssh-agent'\r
-Set-Service -Name ssh-agent -StartupType Automatic\r
-if ((Get-Service ssh-agent).Status -ne 'Running') { Start-Service ssh-agent }\r
+if (Test-SetupStep 'SshAgent') {\r
+ Write-Step 'Enabling ssh-agent'\r
+ Set-Service -Name ssh-agent -StartupType Automatic\r
+ if ((Get-Service ssh-agent).Status -ne 'Running') { Start-Service ssh-agent }\r
+}\r
\r
# ---------------------------------------------------------------------------\r
# OpenSSH Server (sshd)\r
#\r
# Non-fatal: a box that can't run sshd should still finish provisioning.\r
# ---------------------------------------------------------------------------\r
-Write-Step 'OpenSSH Server (sshd)'\r
-try {\r
- $sshd = Get-WindowsCapability -Online -Name 'OpenSSH.Server*' |\r
- Select-Object -First 1\r
- if (-not $sshd) {\r
- Write-Warning 'OpenSSH.Server capability not offered by this Windows image - skipping.'\r
- } else {\r
- if ($sshd.State -ne 'Installed') {\r
- Write-Host " Installing $($sshd.Name) ..."\r
- $r = Add-WindowsCapability -Online -Name $sshd.Name\r
- if ($r.RestartNeeded) { Write-Host ' [reboot required after OpenSSH Server]' -ForegroundColor Yellow }\r
+if (Test-SetupStep 'OpenSshServer') {\r
+ Write-Step 'OpenSSH Server (sshd)'\r
+ try {\r
+ $sshd = Get-WindowsCapability -Online -Name 'OpenSSH.Server*' |\r
+ Select-Object -First 1\r
+ if (-not $sshd) {\r
+ Write-Warning 'OpenSSH.Server capability not offered by this Windows image - skipping.'\r
} else {\r
- Write-Host " OK: $($sshd.Name) already installed"\r
- }\r
+ if ($sshd.State -ne 'Installed') {\r
+ Write-Host " Installing $($sshd.Name) ..."\r
+ $r = Add-WindowsCapability -Online -Name $sshd.Name\r
+ if ($r.RestartNeeded) { Write-Host ' [reboot required after OpenSSH Server]' -ForegroundColor Yellow }\r
+ } else {\r
+ Write-Host " OK: $($sshd.Name) already installed"\r
+ }\r
\r
- Set-Service -Name sshd -StartupType Automatic\r
- if ((Get-Service sshd).Status -ne 'Running') { Start-Service sshd }\r
- Write-Host ' sshd: Automatic + running'\r
+ Set-Service -Name sshd -StartupType Automatic\r
+ if ((Get-Service sshd).Status -ne 'Running') { Start-Service sshd }\r
+ Write-Host ' sshd: Automatic + running'\r
\r
- # Firewall: allow inbound 22 on all profiles. VirtualBox host-only and\r
- # bridged adapters are frequently classified Public, and the capability's\r
- # own rule is Private-only on some images, which is what leaves a plainly\r
- # running sshd plainly unreachable.\r
- #\r
- # OpenSSH-Server-In-TCP is the name the capability itself uses, so this\r
- # WIDENS that rule rather than adding a second one next to it. Creating\r
- # our own under a different name would leave the narrow rule in place and\r
- # the box still unreachable on a Public-classified adapter; creating one\r
- # under the same name would collide. Adopt it if present, create it if not.\r
- $ruleName = 'OpenSSH-Server-In-TCP'\r
- if (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue) {\r
- Set-NetFirewallRule -Name $ruleName -Enabled True -Profile Any\r
- Write-Host " Widened firewall rule $ruleName to all profiles"\r
- } else {\r
- New-NetFirewallRule -Name $ruleName -DisplayName 'OpenSSH SSH Server (sshd)' `\r
- -Enabled True -Direction Inbound -Protocol TCP -Action Allow `\r
- -LocalPort 22 -Profile Any | Out-Null\r
- Write-Host " Added firewall rule $ruleName (TCP 22, all profiles)"\r
+ # Firewall: allow inbound 22 on all profiles. VirtualBox host-only and\r
+ # bridged adapters are frequently classified Public, and the capability's\r
+ # own rule is Private-only on some images, which is what leaves a plainly\r
+ # running sshd plainly unreachable.\r
+ #\r
+ # OpenSSH-Server-In-TCP is the name the capability itself uses, so this\r
+ # WIDENS that rule rather than adding a second one next to it. Creating\r
+ # our own under a different name would leave the narrow rule in place and\r
+ # the box still unreachable on a Public-classified adapter; creating one\r
+ # under the same name would collide. Adopt it if present, create it if not.\r
+ $ruleName = 'OpenSSH-Server-In-TCP'\r
+ if (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue) {\r
+ Set-NetFirewallRule -Name $ruleName -Enabled True -Profile Any\r
+ Write-Host " Widened firewall rule $ruleName to all profiles"\r
+ } else {\r
+ New-NetFirewallRule -Name $ruleName -DisplayName 'OpenSSH SSH Server (sshd)' `\r
+ -Enabled True -Direction Inbound -Protocol TCP -Action Allow `\r
+ -LocalPort 22 -Profile Any | Out-Null\r
+ Write-Host " Added firewall rule $ruleName (TCP 22, all profiles)"\r
+ }\r
}\r
+ } catch {\r
+ Write-Warning "OpenSSH Server setup failed: $($_.Exception.Message)"\r
}\r
-} catch {\r
- Write-Warning "OpenSSH Server setup failed: $($_.Exception.Message)"\r
}\r
\r
# ---------------------------------------------------------------------------\r
#\r
# Non-fatal: a download failure only warns.\r
# ---------------------------------------------------------------------------\r
-Write-Step 'rsync for Windows'\r
-$RsyncRepo = 'nuket/rsync-windows'\r
-# The release publishes x86, x64 and - since v3.5.0-gdeeda96f - arm64, so every\r
-# architecture this script runs on gets a native build. ARM64 used to take the\r
-# x64 zip under emulation, which was defensible (a transfer is bound by the\r
-# socket, not by emulated CPU) but cost the release's ssh.exe: that x64 binary\r
-# could not load the ARM64 libcrypto.dll in System32 and had to be deleted on\r
-# every run. The arm64 asset ships an ARM64 rsync.exe AND an ARM64 ssh.exe, so\r
-# both halves are now native and the fast client survives.\r
-#\r
-# Selected off $HostArch rather than Is64BitOperatingSystem, which answers "true"\r
-# on ARM64 and so cannot tell the two 64-bit cases apart.\r
-$RsyncAsset = switch ($HostArch) {\r
- 'X64' { 'rsync-windows-x64.zip' }\r
- 'Arm64' { 'rsync-windows-arm64.zip' }\r
- default { 'rsync-windows-x86.zip' }\r
-}\r
-if ($IsArm64) {\r
- Write-Host ' ARM64: using the native arm64 asset (rsync.exe and ssh.exe both ARM64).' -ForegroundColor Green\r
-}\r
-# The /releases/latest/download/ redirect rather than the API: unauthenticated\r
-# API calls are rate-limited to 60/hour per IP, which a provisioning run behind a\r
-# shared NAT can genuinely exhaust, and the redirect costs none of that budget.\r
-# To hold a box on a known build, pin the tag instead:\r
-# .../releases/download/v3.5.0-gABCDEF0/$RsyncAsset\r
-$RsyncUrl = "https://github.com/$RsyncRepo/releases/latest/download/$RsyncAsset"\r
-$RsyncDir = 'C:\Tools\rsync'\r
-try {\r
- New-Item -ItemType Directory -Force -Path $RsyncDir | Out-Null\r
- $RsyncExe = Join-Path $RsyncDir 'rsync.exe'\r
-\r
- # Does the release's ssh.exe have the libcrypto it needs? Decided before the\r
- # download so the answer can also gate what comes out of the zip. This is a\r
- # cheap pre-filter only - the authoritative check is running the thing, which\r
- # happens after the unpack below.\r
- $SysCrypto = Join-Path $env:WINDIR 'System32\libcrypto.dll'\r
- $WantSsh = Test-Path $SysCrypto\r
- if (-not $WantSsh) {\r
- Write-Warning "$SysCrypto is missing - the OpenSSH Client capability is not installed - and the release's ssh.exe needs it. Installing rsync.exe only; rsync will use the ssh on the PATH."\r
- } else {\r
- $v = (Get-Item $SysCrypto).VersionInfo.FileVersion\r
- if ($v -and ([version]($v -replace '[^0-9.]', '')) -lt [version]'3.8.2') {\r
- Write-Warning "$SysCrypto is LibreSSL $v; the release's ssh.exe is built against 3.8.2 (Windows OpenSSH Client 9.5). Update Windows, or expect ssh.exe not to start."\r
- }\r
- # No architecture special-case here any more: the asset chosen above\r
- # matches the host, so the release's ssh.exe and System32's libcrypto.dll\r
- # are the same architecture on every box. The run-it check below still\r
- # happens on all of them - it is cheap, and it is what caught the ARM64\r
- # mismatch back when this took the x64 zip.\r
- }\r
-\r
- # Download and unpack beside the targets, not over them, so an interrupted\r
- # transfer can't leave a truncated rsync.exe sitting on the PATH. The scratch\r
- # name still has to END in .zip: Windows PowerShell 5.1's Expand-Archive\r
- # refuses any other extension outright ("*.download is not a supported\r
- # archive file format"), where PowerShell 7 just reads the file.\r
- [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12\r
- $tmpZip = Join-Path $RsyncDir "download-$RsyncAsset"\r
- Invoke-WebRequest -Uri $RsyncUrl -OutFile $tmpZip -UseBasicParsing\r
- Write-Host " Downloaded $RsyncAsset ($([math]::Round((Get-Item $tmpZip).Length / 1MB, 2)) MB)"\r
-\r
- # Verify against the .sha256 published beside it. Same origin, so this is an\r
- # integrity check on the transfer rather than a defence against a hostile\r
- # release - but a truncated or proxy-mangled download is the failure that\r
- # actually happens, and it fails here instead of mid-transfer later.\r
+if (Test-SetupStep 'Rsync') {\r
+ Write-Step 'rsync for Windows'\r
+ $RsyncRepo = 'nuket/rsync-windows'\r
+ # The release publishes x86, x64 and - since v3.5.0-gdeeda96f - arm64, so every\r
+ # architecture this script runs on gets a native build. ARM64 used to take the\r
+ # x64 zip under emulation, which was defensible (a transfer is bound by the\r
+ # socket, not by emulated CPU) but cost the release's ssh.exe: that x64 binary\r
+ # could not load the ARM64 libcrypto.dll in System32 and had to be deleted on\r
+ # every run. The arm64 asset ships an ARM64 rsync.exe AND an ARM64 ssh.exe, so\r
+ # both halves are now native and the fast client survives.\r
#\r
- # -OutFile, not .Content: GitHub serves the .sha256 as\r
- # application/octet-stream, and Invoke-WebRequest hands back a byte[] rather\r
- # than a string for any non-text content type, so .Content would compare the\r
- # first BYTE against the hash and fail on every correct download.\r
- $tmpSha = "$tmpZip.sha256"\r
- Invoke-WebRequest -Uri "$RsyncUrl.sha256" -OutFile $tmpSha -UseBasicParsing\r
- $want = (((Get-Content $tmpSha -Raw) -split '\s+')[0]).Trim().ToLower()\r
- Remove-Item $tmpSha -Force -ErrorAction SilentlyContinue\r
- $got = (Get-FileHash $tmpZip -Algorithm SHA256).Hash.ToLower()\r
- if ($want -and $want -ne $got) {\r
- Remove-Item $tmpZip -Force\r
- throw "SHA-256 mismatch for ${RsyncAsset}: expected $want, got $got"\r
+ # Selected off $HostArch rather than Is64BitOperatingSystem, which answers "true"\r
+ # on ARM64 and so cannot tell the two 64-bit cases apart.\r
+ $RsyncAsset = switch ($HostArch) {\r
+ 'X64' { 'rsync-windows-x64.zip' }\r
+ 'Arm64' { 'rsync-windows-arm64.zip' }\r
+ default { 'rsync-windows-x86.zip' }\r
}\r
- Write-Host " SHA-256 verified: $got"\r
-\r
- # Unpack to a scratch directory and move out the files we asked for, rather\r
- # than expanding straight over the install directory: the zip is the unit\r
- # that was checksummed, and this way a future release adding something to it\r
- # cannot quietly drop that something onto the machine PATH.\r
- $unpack = Join-Path $RsyncDir '.unpack'\r
- if (Test-Path $unpack) { Remove-Item -Recurse -Force $unpack }\r
- Expand-Archive -Path $tmpZip -DestinationPath $unpack -Force\r
- Remove-Item $tmpZip -Force\r
- foreach ($f in 'rsync.exe', 'ssh.exe', 'COPYING.txt', 'NOTICE-ssh.txt') {\r
- $src = Join-Path $unpack $f\r
- if (-not (Test-Path $src)) { continue }\r
- if ($f -eq 'ssh.exe' -and -not $WantSsh) { continue }\r
- Move-Item -Path $src -Destination (Join-Path $RsyncDir $f) -Force\r
+ if ($IsArm64) {\r
+ Write-Host ' ARM64: using the native arm64 asset (rsync.exe and ssh.exe both ARM64).' -ForegroundColor Green\r
}\r
- Remove-Item -Recurse -Force $unpack\r
+ # The /releases/latest/download/ redirect rather than the API: unauthenticated\r
+ # API calls are rate-limited to 60/hour per IP, which a provisioning run behind a\r
+ # shared NAT can genuinely exhaust, and the redirect costs none of that budget.\r
+ # To hold a box on a known build, pin the tag instead:\r
+ # .../releases/download/v3.5.0-gABCDEF0/$RsyncAsset\r
+ $RsyncUrl = "https://github.com/$RsyncRepo/releases/latest/download/$RsyncAsset"\r
+ $RsyncDir = 'C:\Tools\rsync'\r
+ try {\r
+ New-Item -ItemType Directory -Force -Path $RsyncDir | Out-Null\r
+ $RsyncExe = Join-Path $RsyncDir 'rsync.exe'\r
\r
- # Prove the unpacked ssh.exe actually starts, and DELETE it if it does not.\r
- #\r
- # This matters more than it looks. rsync.exe prefers an ssh.exe sitting in its\r
- # own directory, so a present-but-unstartable one does not degrade to the\r
- # in-box client - it breaks rsync outright, and the error you get is a remote\r
- # shell that died rather than anything naming ssh.exe. The way to land there\r
- # is a missing or too-old System32 libcrypto.dll. Removing it is the repair:\r
- # rsync then falls back to the ssh on the PATH, which is the in-box client.\r
- #\r
- # This also used to fire on every ARM64 run, when the x64 asset was the only\r
- # 64-bit one published and its ssh.exe could not load the ARM64 libcrypto\r
- # (exit 0xC0000135, STATUS_DLL_NOT_FOUND). The arm64 asset fixed that at the\r
- # source; the check stays because it is how that was found in the first place.\r
- #\r
- # EAP back to Continue for the call: ssh -V writes its version to STDERR, and\r
- # under $ErrorActionPreference = 'Stop' a native command's stderr becomes a\r
- # terminating error, so a WORKING client would look like a broken one.\r
- # $global:LASTEXITCODE is cleared first because an exe that cannot start at\r
- # all throws without setting one, and the stale 0 from the previous native\r
- # command would otherwise read as success.\r
- #\r
- # DRAIN THE OUTPUT BEFORE READING $LASTEXITCODE. `... | Select-Object -First 1`\r
- # was the original spelling here, and it is a trap: Select-Object stops the\r
- # pipeline the instant it has its one object, and that is when ssh.exe has\r
- # WRITTEN its banner - not when it has exited. PowerShell then tears the\r
- # pipeline down, kills the still-running process, and reports -1. Measured on a\r
- # healthy binary on an x64 box: 24 of 25 runs reported exit -1 through\r
- # Select-Object, and 25 of 25 reported 0 when the output was collected first.\r
- #\r
- # So this check was deleting a perfectly good ssh.exe on almost every run, on\r
- # every architecture, and the resulting fallback to the in-box client - the\r
- # ~17MB/s one this whole step exists to avoid - looked like a property of the\r
- # release rather than a bug in the test. Collect, THEN take the first line.\r
- $SshExe = Join-Path $RsyncDir 'ssh.exe'\r
- if ($WantSsh -and (Test-Path $SshExe)) {\r
- $prevEap = $ErrorActionPreference\r
- $ErrorActionPreference = 'Continue'\r
- $global:LASTEXITCODE = $null\r
- $sshVer = $null\r
- try { $sshOut = (& $SshExe -V 2>&1); $sshVer = $sshOut | Select-Object -First 1 } catch { }\r
- finally { $ErrorActionPreference = $prevEap }\r
- if ($LASTEXITCODE -eq 0) {\r
- Write-Host " ssh.exe runs: $sshVer"\r
+ # Does the release's ssh.exe have the libcrypto it needs? Decided before the\r
+ # download so the answer can also gate what comes out of the zip. This is a\r
+ # cheap pre-filter only - the authoritative check is running the thing, which\r
+ # happens after the unpack below.\r
+ $SysCrypto = Join-Path $env:WINDIR 'System32\libcrypto.dll'\r
+ $WantSsh = Test-Path $SysCrypto\r
+ if (-not $WantSsh) {\r
+ Write-Warning "$SysCrypto is missing - the OpenSSH Client capability is not installed - and the release's ssh.exe needs it. Installing rsync.exe only; rsync will use the ssh on the PATH."\r
} else {\r
- $why = if ($null -eq $LASTEXITCODE) { 'it would not start' } else { "exit $LASTEXITCODE" }\r
- Write-Warning "The release's ssh.exe does not run here ($why)$(if ($sshVer) { ": $sshVer" }). Removing it so rsync.exe falls back to the ssh on the PATH instead of failing on it."\r
- Remove-Item $SshExe -Force -ErrorAction SilentlyContinue\r
- $WantSsh = $false\r
+ $v = (Get-Item $SysCrypto).VersionInfo.FileVersion\r
+ if ($v -and ([version]($v -replace '[^0-9.]', '')) -lt [version]'3.8.2') {\r
+ Write-Warning "$SysCrypto is LibreSSL $v; the release's ssh.exe is built against 3.8.2 (Windows OpenSSH Client 9.5). Update Windows, or expect ssh.exe not to start."\r
+ }\r
+ # No architecture special-case here any more: the asset chosen above\r
+ # matches the host, so the release's ssh.exe and System32's libcrypto.dll\r
+ # are the same architecture on every box. The run-it check below still\r
+ # happens on all of them - it is cheap, and it is what caught the ARM64\r
+ # mismatch back when this took the x64 zip.\r
}\r
- }\r
- Write-Host " Installed $RsyncExe$(if ($WantSsh) { ' and the ssh.exe it runs' })"\r
-\r
- # Machine PATH (HKLM environment). Idempotent: only appends if absent.\r
- $m = [Environment]::GetEnvironmentVariable('Path', 'Machine')\r
- if (-not $m) { $m = '' }\r
- if (($m -split ';') -notcontains $RsyncDir) {\r
- $new = if ($m.Trim()) { $m.TrimEnd(';') + ';' + $RsyncDir } else { $RsyncDir }\r
- [Environment]::SetEnvironmentVariable('Path', $new, 'Machine')\r
- Write-Host " Added $RsyncDir to the machine PATH (restart shells / sshd to pick it up)."\r
- # sshd caches the environment it was started with, so an already-running\r
- # service would not see the new PATH until restarted.\r
- if ((Get-Service sshd -ErrorAction SilentlyContinue).Status -eq 'Running') {\r
- Restart-Service sshd\r
- Write-Host ' Restarted sshd so it inherits the updated machine PATH.'\r
+\r
+ # Download and unpack beside the targets, not over them, so an interrupted\r
+ # transfer can't leave a truncated rsync.exe sitting on the PATH. The scratch\r
+ # name still has to END in .zip: Windows PowerShell 5.1's Expand-Archive\r
+ # refuses any other extension outright ("*.download is not a supported\r
+ # archive file format"), where PowerShell 7 just reads the file.\r
+ [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12\r
+ $tmpZip = Join-Path $RsyncDir "download-$RsyncAsset"\r
+\r
+ # The .sha256 published beside the zip is fetched FIRST, for two jobs. It\r
+ # verifies the download below. Same origin, so that is an integrity check on\r
+ # the transfer rather than a defence against a hostile release - but a\r
+ # truncated or proxy-mangled download is the failure that actually happens,\r
+ # and it fails here instead of mid-transfer later.\r
+ #\r
+ # And it says whether there is anything new to fetch at all. The hash of the\r
+ # zip the installed files came from is recorded beside them in\r
+ # rsync-windows.sha256, written only once they have all landed (as BinSkim's\r
+ # nupkg-version.txt is). When the release's hash still matches and the files\r
+ # are all there, the download and unpack are skipped - a re-run costs one\r
+ # small request instead of the zip. An ssh.exe that was wanted but is gone\r
+ # (removed below for not starting) does NOT count as there, so each run\r
+ # tries it again: whatever stopped it starting may have been fixed since.\r
+ #\r
+ # -OutFile, not .Content: GitHub serves the .sha256 as\r
+ # application/octet-stream, and Invoke-WebRequest hands back a byte[] rather\r
+ # than a string for any non-text content type, so .Content would compare the\r
+ # first BYTE against the hash and fail on every correct download.\r
+ $tmpSha = "$tmpZip.sha256"\r
+ Invoke-WebRequest -Uri "$RsyncUrl.sha256" -OutFile $tmpSha -UseBasicParsing\r
+ $want = (((Get-Content $tmpSha -Raw) -split '\s+')[0]).Trim().ToLower()\r
+ Remove-Item $tmpSha -Force -ErrorAction SilentlyContinue\r
+\r
+ $RsyncMarker = Join-Path $RsyncDir 'rsync-windows.sha256'\r
+ $InstalledSha = if (Test-Path $RsyncMarker) { (Get-Content $RsyncMarker -Raw).Trim().ToLower() } else { '' }\r
+ $RsyncCurrent = $want -and ($InstalledSha -eq $want) -and (Test-Path $RsyncExe) -and\r
+ (-not $WantSsh -or (Test-Path (Join-Path $RsyncDir 'ssh.exe')))\r
+ if ($RsyncCurrent) {\r
+ Write-Host " $RsyncAsset unchanged since it was installed (SHA-256 $want); not downloading it again."\r
+ } else {\r
+ Invoke-WebRequest -Uri $RsyncUrl -OutFile $tmpZip -UseBasicParsing\r
+ Write-Host " Downloaded $RsyncAsset ($([math]::Round((Get-Item $tmpZip).Length / 1MB, 2)) MB)"\r
+ $got = (Get-FileHash $tmpZip -Algorithm SHA256).Hash.ToLower()\r
+ if ($want -and $want -ne $got) {\r
+ Remove-Item $tmpZip -Force\r
+ throw "SHA-256 mismatch for ${RsyncAsset}: expected $want, got $got"\r
+ }\r
+ Write-Host " SHA-256 verified: $got"\r
+\r
+ # Unpack to a scratch directory and move out the files we asked for, rather\r
+ # than expanding straight over the install directory: the zip is the unit\r
+ # that was checksummed, and this way a future release adding something to it\r
+ # cannot quietly drop that something onto the machine PATH.\r
+ $unpack = Join-Path $RsyncDir '.unpack'\r
+ if (Test-Path $unpack) { Remove-Item -Recurse -Force $unpack }\r
+ Expand-Archive -Path $tmpZip -DestinationPath $unpack -Force\r
+ Remove-Item $tmpZip -Force\r
+ foreach ($f in 'rsync.exe', 'ssh.exe', 'COPYING.txt', 'NOTICE-ssh.txt') {\r
+ $src = Join-Path $unpack $f\r
+ if (-not (Test-Path $src)) { continue }\r
+ if ($f -eq 'ssh.exe' -and -not $WantSsh) { continue }\r
+ Move-Item -Path $src -Destination (Join-Path $RsyncDir $f) -Force\r
+ }\r
+ Remove-Item -Recurse -Force $unpack\r
+ # Written last: the marker must only claim a release that fully landed.\r
+ if ($want) { Set-Content -Path $RsyncMarker -Value $want -Encoding ascii }\r
}\r
- } else {\r
- Write-Host " OK: $RsyncDir already in the machine PATH"\r
- }\r
\r
- & $RsyncExe --version | Select-Object -First 1\r
-} catch {\r
- Write-Warning "rsync install failed: $($_.Exception.Message)"\r
- Write-Warning "Download $RsyncAsset from https://github.com/$RsyncRepo/releases manually"\r
- Write-Warning "and unpack it into $RsyncDir, keeping rsync.exe and ssh.exe together."\r
+ # Prove the unpacked ssh.exe actually starts, and DELETE it if it does not.\r
+ #\r
+ # This matters more than it looks. rsync.exe prefers an ssh.exe sitting in its\r
+ # own directory, so a present-but-unstartable one does not degrade to the\r
+ # in-box client - it breaks rsync outright, and the error you get is a remote\r
+ # shell that died rather than anything naming ssh.exe. The way to land there\r
+ # is a missing or too-old System32 libcrypto.dll. Removing it is the repair:\r
+ # rsync then falls back to the ssh on the PATH, which is the in-box client.\r
+ #\r
+ # This also used to fire on every ARM64 run, when the x64 asset was the only\r
+ # 64-bit one published and its ssh.exe could not load the ARM64 libcrypto\r
+ # (exit 0xC0000135, STATUS_DLL_NOT_FOUND). The arm64 asset fixed that at the\r
+ # source; the check stays because it is how that was found in the first place.\r
+ #\r
+ # EAP back to Continue for the call: ssh -V writes its version to STDERR, and\r
+ # under $ErrorActionPreference = 'Stop' a native command's stderr becomes a\r
+ # terminating error, so a WORKING client would look like a broken one.\r
+ # $global:LASTEXITCODE is cleared first because an exe that cannot start at\r
+ # all throws without setting one, and the stale 0 from the previous native\r
+ # command would otherwise read as success.\r
+ #\r
+ # DRAIN THE OUTPUT BEFORE READING $LASTEXITCODE. `... | Select-Object -First 1`\r
+ # was the original spelling here, and it is a trap: Select-Object stops the\r
+ # pipeline the instant it has its one object, and that is when ssh.exe has\r
+ # WRITTEN its banner - not when it has exited. PowerShell then tears the\r
+ # pipeline down, kills the still-running process, and reports -1. Measured on a\r
+ # healthy binary on an x64 box: 24 of 25 runs reported exit -1 through\r
+ # Select-Object, and 25 of 25 reported 0 when the output was collected first.\r
+ #\r
+ # So this check was deleting a perfectly good ssh.exe on almost every run, on\r
+ # every architecture, and the resulting fallback to the in-box client - the\r
+ # ~17MB/s one this whole step exists to avoid - looked like a property of the\r
+ # release rather than a bug in the test. Collect, THEN take the first line.\r
+ $SshExe = Join-Path $RsyncDir 'ssh.exe'\r
+ if ($WantSsh -and (Test-Path $SshExe)) {\r
+ $prevEap = $ErrorActionPreference\r
+ $ErrorActionPreference = 'Continue'\r
+ $global:LASTEXITCODE = $null\r
+ $sshVer = $null\r
+ try { $sshOut = (& $SshExe -V 2>&1); $sshVer = $sshOut | Select-Object -First 1 } catch { }\r
+ finally { $ErrorActionPreference = $prevEap }\r
+ if ($LASTEXITCODE -eq 0) {\r
+ Write-Host " ssh.exe runs: $sshVer"\r
+ } else {\r
+ $why = if ($null -eq $LASTEXITCODE) { 'it would not start' } else { "exit $LASTEXITCODE" }\r
+ Write-Warning "The release's ssh.exe does not run here ($why)$(if ($sshVer) { ": $sshVer" }). Removing it so rsync.exe falls back to the ssh on the PATH instead of failing on it."\r
+ Remove-Item $SshExe -Force -ErrorAction SilentlyContinue\r
+ $WantSsh = $false\r
+ }\r
+ }\r
+ Write-Host " $(if ($RsyncCurrent) { 'Kept' } else { 'Installed' }) $RsyncExe$(if ($WantSsh) { ' and the ssh.exe it runs' })"\r
+\r
+ # Machine PATH (HKLM environment). Idempotent: only appends if absent.\r
+ $m = [Environment]::GetEnvironmentVariable('Path', 'Machine')\r
+ if (-not $m) { $m = '' }\r
+ if (($m -split ';') -notcontains $RsyncDir) {\r
+ $new = if ($m.Trim()) { $m.TrimEnd(';') + ';' + $RsyncDir } else { $RsyncDir }\r
+ [Environment]::SetEnvironmentVariable('Path', $new, 'Machine')\r
+ Write-Host " Added $RsyncDir to the machine PATH (restart shells / sshd to pick it up)."\r
+ # sshd caches the environment it was started with, so an already-running\r
+ # service would not see the new PATH until restarted.\r
+ if ((Get-Service sshd -ErrorAction SilentlyContinue).Status -eq 'Running') {\r
+ Restart-Service sshd\r
+ Write-Host ' Restarted sshd so it inherits the updated machine PATH.'\r
+ }\r
+ } else {\r
+ Write-Host " OK: $RsyncDir already in the machine PATH"\r
+ }\r
+\r
+ & $RsyncExe --version | Select-Object -First 1\r
+ } catch {\r
+ Write-Warning "rsync install failed: $($_.Exception.Message)"\r
+ Write-Warning "Download $RsyncAsset from https://github.com/$RsyncRepo/releases manually"\r
+ Write-Warning "and unpack it into $RsyncDir, keeping rsync.exe and ssh.exe together."\r
+ }\r
}\r
\r
# ---------------------------------------------------------------------------\r
# It is dropped on ARM64 because that machine is a constrained VM provisioned as\r
# a single-compiler build box: MSVC and nothing else. Compiler diversity - MSVC,\r
# VS clang-cl and upstream LLVM over the same sources - now lives entirely on the\r
-# x64 machine, which is the one with room for three toolchains. Empty here means\r
-# Invoke-VsModify is never called for this group.\r
-$ClangComponents = if ($IsArm64) { @() } else {\r
- @(\r
- 'Microsoft.VisualStudio.Component.VC.Llvm.Clang'\r
- 'Microsoft.VisualStudio.Component.VC.Llvm.ClangToolset'\r
- )\r
-}\r
+# x64 machine, which is the one with room for three toolchains. The VsClang step\r
+# is -X64Only in setup-windows-steps.ps1, so on ARM64 this group is never asked\r
+# for.\r
+$ClangComponents = @(\r
+ 'Microsoft.VisualStudio.Component.VC.Llvm.Clang'\r
+ 'Microsoft.VisualStudio.Component.VC.Llvm.ClangToolset'\r
+)\r
\r
# Windows XP targeting (v141_xp toolset, used in CMakePresets.json). The v141\r
# (VS2017) build tools provide the 14.16 compiler that the XP toolset wraps;\r
# WinXP layers the XP-compatible CRT/SDK on top of it.\r
#\r
-# NOT USED ON ARM64, and left empty there. The components are still listed in the\r
+# NOT USED ON ARM64 - VsWinXP is -X64Only. The components are still listed in the\r
# catalog on Arm, so this is not strictly "unavailable" - but the 14.16 toolset\r
# predates Windows on Arm as a host and ships HostX86/HostX64 compilers only, so\r
# the best you could get is an x86-emulated compiler, and Microsoft does not\r
# used: Windows XP never ran on ARM64, so an XP-targeting build from an ARM64\r
# host has no purpose beyond producing x86 binaries, which the current toolset\r
# does natively via -A Win32. On x64 the group is installed exactly as before.\r
-$XpComponents = if ($IsArm64) { @() } else {\r
- @(\r
- 'Microsoft.VisualStudio.Component.VC.v141.x86.x64'\r
- 'Microsoft.VisualStudio.Component.WinXP'\r
- )\r
-}\r
+$XpComponents = @(\r
+ 'Microsoft.VisualStudio.Component.VC.v141.x86.x64'\r
+ 'Microsoft.VisualStudio.Component.WinXP'\r
+)\r
\r
# Which Visual Studio generation to drive: 17 = VS 2022, 18 = VS 2026. Both have\r
# native ARM64 installers and ARM64-hosted MSVC. This picks the bootstrapper URL,\r
$VsWhere = Join-Path ${env:ProgramFiles(x86)} 'Microsoft Visual Studio\Installer\vswhere.exe'\r
$InstallPath = Get-VsInstallPath\r
\r
+# Three steps drive Visual Studio - the base install and the two optional groups\r
+# layered on it. They share the bootstrapper download and the verification\r
+# below, which happen once if any of them runs. Asked once, here.\r
+$DoVsBase = Test-SetupStep 'VisualStudio'\r
+$DoVsClang = Test-SetupStep 'VsClang'\r
+$DoVsXp = Test-SetupStep 'VsWinXP'\r
+$DoVs = $DoVsBase -or $DoVsClang -or $DoVsXp\r
+\r
+# Whether any selected pass still has something to add. When none does, the\r
+# bootstrapper is not even downloaded: each pass would find its components\r
+# already installed (Test-VsHasComponents) and return before using it. The Clang\r
+# and XP passes only count with an install to add them to - without one they\r
+# stand down below, and would not use the bootstrapper either.\r
+$VsNeedsInstaller = ($DoVsBase -and -not (Test-VsHasComponents $BaseComponents)) -or\r
+ ($DoVsClang -and $InstallPath -and -not (Test-VsHasComponents $ClangComponents)) -or\r
+ ($DoVsXp -and $InstallPath -and -not (Test-VsHasComponents $XpComponents))\r
+\r
# Report any OTHER Visual Studio generations on the box. They are left alone -\r
# the passes below only ever touch $InstallPath - but when none of them matches\r
# $VsChannel this script is about to download and install a second, largely\r
# redundant toolchain, and that should be a visible decision rather than a\r
# surprise 10GB. (On ARM64, where $VsChannel is 18, an existing VS 2026 IS the\r
# match and gets modified in place rather than duplicated.)\r
-if (Test-Path $VsWhere) {\r
+if ($DoVs -and (Test-Path $VsWhere)) {\r
$others = & $VsWhere -products '*' -format value -property installationPath |\r
Where-Object { $_ -and $_ -ne $InstallPath }\r
if ($others) {\r
}\r
}\r
\r
-Write-Step "Downloading VS $VsChannel $VsEdition bootstrapper (host: $HostArch)"\r
-# aka.ms serves the bootstrapper for the requesting machine's architecture, so on\r
-# ARM64 this is the native ARM64 installer - no --arch flag needed or offered.\r
-$VsInstallerUrl = "https://aka.ms/vs/$VsChannel/$VsChannelPath/vs_$VsEdition.exe"\r
-$VsBootstrapper = Join-Path $TempDir "vs_$VsEdition.exe"\r
-Write-Host " $VsInstallerUrl" -ForegroundColor DarkGray\r
-Invoke-WebRequest -Uri $VsInstallerUrl -OutFile $VsBootstrapper -UseBasicParsing\r
-\r
-# Prove we got an installer and not a web page. The Bing redirect described above\r
-# returns 200 with HTML, and every other aka.ms typo behaves the same way, so a\r
-# bad channel/edition combination is otherwise only discovered when the "exe"\r
-# fails to start. 'MZ' is the DOS header every PE begins with.\r
-$vsHead = [IO.File]::ReadAllBytes($VsBootstrapper) | Select-Object -First 2\r
-if (-not ($vsHead.Count -eq 2 -and $vsHead[0] -eq 0x4D -and $vsHead[1] -eq 0x5A)) {\r
- throw "Visual Studio: $VsInstallerUrl did not return an executable (no MZ header; $((Get-Item $VsBootstrapper).Length) bytes). Check `$VsChannel / `$VsChannelPath / `$VsEdition."\r
+if ($DoVs -and -not $VsNeedsInstaller -and $InstallPath) {\r
+ Write-Step 'Visual Studio'\r
+ Write-Host " Every selected component group is already in $InstallPath; not downloading the installer."\r
+}\r
+if ($VsNeedsInstaller) {\r
+ Write-Step "Downloading VS $VsChannel $VsEdition bootstrapper (host: $HostArch)"\r
+ # aka.ms serves the bootstrapper for the requesting machine's architecture, so on\r
+ # ARM64 this is the native ARM64 installer - no --arch flag needed or offered.\r
+ $VsInstallerUrl = "https://aka.ms/vs/$VsChannel/$VsChannelPath/vs_$VsEdition.exe"\r
+ $VsBootstrapper = Join-Path $TempDir "vs_$VsEdition.exe"\r
+ Write-Host " $VsInstallerUrl" -ForegroundColor DarkGray\r
+ Invoke-WebRequest -Uri $VsInstallerUrl -OutFile $VsBootstrapper -UseBasicParsing\r
+\r
+ # Prove we got an installer and not a web page. The Bing redirect described above\r
+ # returns 200 with HTML, and every other aka.ms typo behaves the same way, so a\r
+ # bad channel/edition combination is otherwise only discovered when the "exe"\r
+ # fails to start. 'MZ' is the DOS header every PE begins with.\r
+ $vsHead = [IO.File]::ReadAllBytes($VsBootstrapper) | Select-Object -First 2\r
+ if (-not ($vsHead.Count -eq 2 -and $vsHead[0] -eq 0x4D -and $vsHead[1] -eq 0x5A)) {\r
+ throw "Visual Studio: $VsInstallerUrl did not return an executable (no MZ header; $((Get-Item $VsBootstrapper).Length) bytes). Check `$VsChannel / `$VsChannelPath / `$VsEdition."\r
+ }\r
+ Write-Host " OK: bootstrapper is a PE ($([math]::Round((Get-Item $VsBootstrapper).Length / 1MB, 2)) MB)"\r
}\r
-Write-Host " OK: bootstrapper is a PE ($([math]::Round((Get-Item $VsBootstrapper).Length / 1MB, 2)) MB)"\r
\r
# Install in three sequential passes. The base set is installed first (this is\r
# the configuration that previously worked); Clang and the XP toolset are added\r
# needed to build with MSVC, and on a host where one of them is simply not\r
# offered a hard failure here would cost you the whole toolchain over a component\r
# you can add later from the installer UI.\r
-Invoke-VsModify -Label 'base toolset + workload' -Ids $BaseComponents\r
-if ($IsArm64) {\r
- Write-Step 'Visual Studio: Clang / LLVM'\r
- Write-Host ' Skipped on ARM64 by choice, not by limitation: a native ARM64 clang-cl is' -ForegroundColor Yellow\r
- Write-Host ' offered here and works. This box is provisioned with MSVC alone; the' -ForegroundColor Yellow\r
- Write-Host ' multi-compiler builds belong on the x64 machine.' -ForegroundColor Yellow\r
-} else {\r
- Invoke-VsModify -Label 'Clang / LLVM' -Ids $ClangComponents -Optional\r
+#\r
+# On ARM64 only the first pass is ever selected: VsClang and VsWinXP are\r
+# -X64Only in setup-windows-steps.ps1, and the plan printed at the top says why.\r
+#\r
+# The last two MODIFY an existing install. With the base step switched off and\r
+# no Visual Studio of this generation on the box, there is nothing to modify -\r
+# and letting the pass run anyway would install a Visual Studio holding that one\r
+# component group and no C++ workload. So they say so and stand down instead.\r
+if ($DoVsBase) {\r
+ Invoke-VsModify -Label 'base toolset + workload' -Ids $BaseComponents\r
}\r
-if ($IsArm64) {\r
- Write-Step 'Visual Studio: Windows XP (v141 + WinXP)'\r
- Write-Host ' Skipped on ARM64: the v141 (14.16) toolset ships x86/x64-hosted compilers only,' -ForegroundColor Yellow\r
- Write-Host ' and Windows XP targeting is not offered for Arm hosts. Build x86 with the' -ForegroundColor Yellow\r
- Write-Host ' current toolset instead (cmake -A Win32), which is native here.' -ForegroundColor Yellow\r
-} else {\r
- Invoke-VsModify -Label 'Windows XP (v141 + WinXP)' -Ids $XpComponents -Optional\r
+foreach ($pass in @(\r
+ @{ Run = $DoVsClang; Label = 'Clang / LLVM'; Ids = $ClangComponents }\r
+ @{ Run = $DoVsXp; Label = 'Windows XP (v141 + WinXP)'; Ids = $XpComponents })) {\r
+ if (-not $pass.Run) { continue }\r
+ if ($InstallPath) {\r
+ Invoke-VsModify -Label $pass.Label -Ids $pass.Ids -Optional\r
+ } else {\r
+ Write-Step "Visual Studio: $($pass.Label)"\r
+ Write-Warning "No Visual Studio $VsChannel is installed to add this to. Select the VisualStudio step as well."\r
+ }\r
}\r
\r
# ---------------------------------------------------------------------------\r
# the installer UI, not a reason to fail a provisioning run that installed a\r
# working compiler.\r
# ---------------------------------------------------------------------------\r
-Write-Step 'Verifying the installed toolsets'\r
-$InstallPath = Get-VsInstallPath\r
-if (-not $InstallPath) {\r
- Write-Warning "No Visual Studio $VsChannel installation found after the passes above; cannot verify toolsets."\r
-} else {\r
- Write-Host " Install path: $InstallPath"\r
-\r
- # What MSVC versions landed, and which host toolchains each one carries.\r
- # HostARM64 is the directory that proves the native ARM64 compiler is here\r
- # rather than an x64 one that would run under emulation.\r
- $msvcRoot = Join-Path $InstallPath 'VC\Tools\MSVC'\r
- foreach ($v in (Get-ChildItem $msvcRoot -Directory -ErrorAction SilentlyContinue | Sort-Object Name)) {\r
- $hosts = Get-ChildItem (Join-Path $v.FullName 'bin') -Directory -ErrorAction SilentlyContinue |\r
- ForEach-Object { $_.Name }\r
- Write-Host " MSVC $($v.Name): $(if ($hosts) { $hosts -join ', ' } else { '(no bin dir)' })"\r
- }\r
- if ($IsArm64) {\r
- $armHost = Test-Path (Join-Path $msvcRoot '*\bin\HostARM64\ARM64\cl.exe')\r
- if ($armHost) {\r
- Write-Host ' OK: native ARM64-hosted cl.exe present.' -ForegroundColor Green\r
- } else {\r
- Write-Warning 'No HostARM64 cl.exe found - MSVC would run under x64 emulation. Add "MSVC v14x - VS 2022 C++ ARM64/ARM64EC build tools" in the installer.'\r
+if ($DoVs) {\r
+ Write-Step 'Verifying the installed toolsets'\r
+ $InstallPath = Get-VsInstallPath\r
+ if (-not $InstallPath) {\r
+ Write-Warning "No Visual Studio $VsChannel installation found after the passes above; cannot verify toolsets."\r
+ } else {\r
+ Write-Host " Install path: $InstallPath"\r
+\r
+ # What MSVC versions landed, and which host toolchains each one carries.\r
+ # HostARM64 is the directory that proves the native ARM64 compiler is here\r
+ # rather than an x64 one that would run under emulation.\r
+ $msvcRoot = Join-Path $InstallPath 'VC\Tools\MSVC'\r
+ foreach ($v in (Get-ChildItem $msvcRoot -Directory -ErrorAction SilentlyContinue | Sort-Object Name)) {\r
+ $hosts = Get-ChildItem (Join-Path $v.FullName 'bin') -Directory -ErrorAction SilentlyContinue |\r
+ ForEach-Object { $_.Name }\r
+ Write-Host " MSVC $($v.Name): $(if ($hosts) { $hosts -join ', ' } else { '(no bin dir)' })"\r
+ }\r
+ if ($IsArm64) {\r
+ $armHost = Test-Path (Join-Path $msvcRoot '*\bin\HostARM64\ARM64\cl.exe')\r
+ if ($armHost) {\r
+ Write-Host ' OK: native ARM64-hosted cl.exe present.' -ForegroundColor Green\r
+ } else {\r
+ Write-Warning 'No HostARM64 cl.exe found - MSVC would run under x64 emulation. Add "MSVC v14x - VS 2022 C++ ARM64/ARM64EC build tools" in the installer.'\r
+ }\r
}\r
- }\r
\r
- # clang-cl, for the ClangCL toolset in CMakePresets.json. Checked per host\r
- # directory, because the Llvm tree is partitioned by HOST architecture and\r
- # only the matching one is a native compiler.\r
- #\r
- # Look for clang-cl.exe specifically, NOT for the directory. VC\Tools\Llvm\*\bin\r
- # holds clang-format.exe and clang-tidy.exe on every host whether or not the\r
- # Clang component was ever installed - those ship with the NativeDesktop\r
- # workload - so a present ARM64\bin proves nothing on its own. That is the\r
- # false positive to avoid when checking this by hand.\r
- $llvmRoot = Join-Path $InstallPath 'VC\Tools\Llvm'\r
- $clangArm = Test-Path (Join-Path $llvmRoot 'ARM64\bin\clang-cl.exe')\r
- $clangX64 = Test-Path (Join-Path $llvmRoot 'x64\bin\clang-cl.exe')\r
- $clangX86 = Test-Path (Join-Path $llvmRoot 'bin\clang-cl.exe')\r
- $clangAny = $clangArm -or $clangX64 -or $clangX86\r
- if ($IsArm64) {\r
- # Not installed here by design, so its absence is the expected result and\r
- # must not read as a fault. Its PRESENCE is the thing worth a line: a box\r
- # provisioned before this split still carries it, and the component stays\r
- # until it is explicitly removed - the installer never uninstalls what you\r
- # simply stopped asking for.\r
- if ($clangAny) {\r
- Write-Host ' clang-cl: present but no longer provisioned on ARM64 - left over from an earlier run.' -ForegroundColor Yellow\r
- Write-Host ' Remove it with: vs_installer.exe modify --installPath "<path>" --remove Microsoft.VisualStudio.Component.VC.Llvm.Clang --remove Microsoft.VisualStudio.Component.VC.Llvm.ClangToolset --quiet' -ForegroundColor Yellow\r
+ # clang-cl, for the ClangCL toolset in CMakePresets.json. Checked per host\r
+ # directory, because the Llvm tree is partitioned by HOST architecture and\r
+ # only the matching one is a native compiler.\r
+ #\r
+ # Look for clang-cl.exe specifically, NOT for the directory. VC\Tools\Llvm\*\bin\r
+ # holds clang-format.exe and clang-tidy.exe on every host whether or not the\r
+ # Clang component was ever installed - those ship with the NativeDesktop\r
+ # workload - so a present ARM64\bin proves nothing on its own. That is the\r
+ # false positive to avoid when checking this by hand.\r
+ $llvmRoot = Join-Path $InstallPath 'VC\Tools\Llvm'\r
+ $clangArm = Test-Path (Join-Path $llvmRoot 'ARM64\bin\clang-cl.exe')\r
+ $clangX64 = Test-Path (Join-Path $llvmRoot 'x64\bin\clang-cl.exe')\r
+ $clangX86 = Test-Path (Join-Path $llvmRoot 'bin\clang-cl.exe')\r
+ $clangAny = $clangArm -or $clangX64 -or $clangX86\r
+ if ($IsArm64) {\r
+ # Not installed here by design, so its absence is the expected result and\r
+ # must not read as a fault. Its PRESENCE is the thing worth a line: a box\r
+ # provisioned before this split still carries it, and the component stays\r
+ # until it is explicitly removed - the installer never uninstalls what you\r
+ # simply stopped asking for.\r
+ if ($clangAny) {\r
+ Write-Host ' clang-cl: present but no longer provisioned on ARM64 - left over from an earlier run.' -ForegroundColor Yellow\r
+ Write-Host ' Remove it with: vs_installer.exe modify --installPath "<path>" --remove Microsoft.VisualStudio.Component.VC.Llvm.Clang --remove Microsoft.VisualStudio.Component.VC.Llvm.ClangToolset --quiet' -ForegroundColor Yellow\r
+ } else {\r
+ Write-Host ' clang-cl: n/a on ARM64 (MSVC only by design; use the x64 box for ClangCL).' -ForegroundColor DarkGray\r
+ }\r
+ } elseif ($clangAny) {\r
+ Write-Host " clang-cl: $(@(if ($clangArm) {'ARM64'}; if ($clangX64) {'x64'}; if ($clangX86) {'x86'}) -join ', ')" -ForegroundColor Green\r
+ } elseif (-not $DoVsClang) {\r
+ # Switched off in the plan: a choice, so not worth a warning.\r
+ Write-Host ' clang-cl: not installed (the VsClang step was not selected).' -ForegroundColor DarkGray\r
} else {\r
- Write-Host ' clang-cl: n/a on ARM64 (MSVC only by design; use the x64 box for ClangCL).' -ForegroundColor DarkGray\r
+ Write-Warning 'clang-cl not found - the ClangCL presets will fail. Add the "C++ Clang tools for Windows" component.'\r
}\r
- } elseif ($clangAny) {\r
- Write-Host " clang-cl: $(@(if ($clangArm) {'ARM64'}; if ($clangX64) {'x64'}; if ($clangX86) {'x86'}) -join ', ')" -ForegroundColor Green\r
- } else {\r
- Write-Warning 'clang-cl not found - the ClangCL presets will fail. Add the "C++ Clang tools for Windows" component.'\r
- }\r
\r
- # v141 / XP. Only meaningful where the toolset can exist at all; on ARM64 the\r
- # group above was deliberately skipped, so warning here would be noise about\r
- # a decision this script made on purpose two steps ago.\r
- if ($IsArm64) {\r
- Write-Host ' v141 / Windows XP toolset: n/a on ARM64 (not offered for Arm hosts).' -ForegroundColor DarkGray\r
- } else {\r
- $V141 = Get-ChildItem $msvcRoot -Directory -ErrorAction SilentlyContinue |\r
- Where-Object { $_.Name -like '14.16.*' } | Select-Object -First 1\r
- if ($V141) {\r
- Write-Host " OK: v141 toolset present ($($V141.Name))" -ForegroundColor Green\r
+ # v141 / XP. Only meaningful where the toolset can exist at all; on ARM64 the\r
+ # group above was deliberately skipped, so warning here would be noise about\r
+ # a decision this script made on purpose two steps ago.\r
+ if ($IsArm64) {\r
+ Write-Host ' v141 / Windows XP toolset: n/a on ARM64 (not offered for Arm hosts).' -ForegroundColor DarkGray\r
} else {\r
- Write-Warning 'v141 (14.16.x) toolset NOT found - the XP build presets will fail.'\r
- Write-Warning 'Add it via Visual Studio Installer > Modify > Individual components:'\r
- Write-Warning ' - MSVC v141 - VS 2017 C++ x64/x86 build tools (v14.16)'\r
- Write-Warning ' - C++ Windows XP Support for VS 2017 (v141) tools'\r
+ $V141 = Get-ChildItem $msvcRoot -Directory -ErrorAction SilentlyContinue |\r
+ Where-Object { $_.Name -like '14.16.*' } | Select-Object -First 1\r
+ if ($V141) {\r
+ Write-Host " OK: v141 toolset present ($($V141.Name))" -ForegroundColor Green\r
+ } elseif (-not $DoVsXp) {\r
+ Write-Host ' v141 / Windows XP toolset: not installed (the VsWinXP step was not selected).' -ForegroundColor DarkGray\r
+ } else {\r
+ Write-Warning 'v141 (14.16.x) toolset NOT found - the XP build presets will fail.'\r
+ Write-Warning 'Add it via Visual Studio Installer > Modify > Individual components:'\r
+ Write-Warning ' - MSVC v141 - VS 2017 C++ x64/x86 build tools (v14.16)'\r
+ Write-Warning ' - C++ Windows XP Support for VS 2017 (v141) tools'\r
+ }\r
}\r
}\r
}\r
# pairs VS 2026 with the 28000.x kit - not this link.\r
#\r
# On x64 with VS 2022 the SDK and this WDK are the matched pair, so it installs.\r
+#\r
+# The x64-only rule itself is the Wdk step's -X64Only in setup-windows-steps.ps1,\r
+# so on ARM64 this step never runs and the plan says why.\r
# ---------------------------------------------------------------------------\r
-$WdkVersion = '10.0.26100'\r
-# Both hives. The WDK installer is a 32-bit program, so on x64 it writes under\r
-# WOW6432Node - but which hive a given kit lands in has varied across kit\r
-# versions and architectures, and reading only one of them makes an installed WDK\r
-# look absent, which costs a needless multi-GB reinstall on every run. Check the\r
-# native hive too and take whichever answers.\r
-$WdkInstalledRoot = @(\r
- 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows Kits\Installed Roots'\r
- 'HKLM:\SOFTWARE\Microsoft\Windows Kits\Installed Roots'\r
-) | ForEach-Object { (Get-ItemProperty $_ -ErrorAction SilentlyContinue).WdkBinRootVersioned } |\r
- Where-Object { $_ } | Select-Object -First 1\r
+if (Test-SetupStep 'Wdk') {\r
+ $WdkVersion = '10.0.26100'\r
+ # Both hives. The WDK installer is a 32-bit program, so on x64 it writes under\r
+ # WOW6432Node - but which hive a given kit lands in has varied across kit\r
+ # versions and architectures, and reading only one of them makes an installed WDK\r
+ # look absent, which costs a needless multi-GB reinstall on every run. Check the\r
+ # native hive too and take whichever answers.\r
+ $WdkInstalledRoot = @(\r
+ 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows Kits\Installed Roots'\r
+ 'HKLM:\SOFTWARE\Microsoft\Windows Kits\Installed Roots'\r
+ ) | ForEach-Object { (Get-ItemProperty $_ -ErrorAction SilentlyContinue).WdkBinRootVersioned } |\r
+ Where-Object { $_ } | Select-Object -First 1\r
\r
-if ($IsArm64) {\r
- Write-Step 'Windows Driver Kit'\r
- Write-Host ' Skipped on ARM64: this box builds user-mode software only, and WDK 26100.6584' -ForegroundColor Yellow\r
- Write-Host ' cannot install beside the 26100.7705 SDK that Visual Studio 2026 brings - the' -ForegroundColor Yellow\r
- Write-Host ' kit needs the matching SDK revision and they are not side-by-side. See the' -ForegroundColor Yellow\r
- Write-Host ' comment above this step for the exit code and what to use instead.' -ForegroundColor Yellow\r
-} elseif ($WdkInstalledRoot -and $WdkInstalledRoot -match [regex]::Escape($WdkVersion)) {\r
- # Re-running wdksetup.exe for an already-present version returns exit code\r
- # 2008 (maintenance mode / nothing to do), which is not a real failure.\r
- Write-Step "WDK $WdkVersion already installed - skipping ($WdkInstalledRoot)"\r
-} else {\r
- Write-Step 'Downloading WDK installer'\r
- $WdkUrl = 'https://go.microsoft.com/fwlink/?linkid=2335869'\r
- $WdkInstaller = Join-Path $TempDir 'wdksetup.exe'\r
- Invoke-WebRequest -Uri $WdkUrl -OutFile $WdkInstaller -UseBasicParsing\r
-\r
- Write-Step 'Installing WDK'\r
- # wdksetup.exe is a 32-bit binary and runs under emulation on ARM64; the kit\r
- # it lays down does include the ARM64 target headers, libs and tools (the\r
- # signing/deployment tools under bin\arm64), so an ARM64 driver builds from\r
- # an ARM64 host. Only the installer is emulated, not the toolchain.\r
- $proc = Start-Process -FilePath $WdkInstaller -ArgumentList '/quiet /norestart' -Wait -PassThru -NoNewWindow\r
- Write-Host " WDK installer exit code: $($proc.ExitCode)"\r
- if ($proc.ExitCode -eq 2008) {\r
- # 2008 = the WDK is already present; the installer has nothing to do.\r
- Write-Host ' [WDK already installed (exit 2008) - treating as success]' -ForegroundColor Yellow\r
+ if ($WdkInstalledRoot -and $WdkInstalledRoot -match [regex]::Escape($WdkVersion)) {\r
+ # Re-running wdksetup.exe for an already-present version returns exit code\r
+ # 2008 (maintenance mode / nothing to do), which is not a real failure.\r
+ Write-Step "WDK $WdkVersion already installed - skipping ($WdkInstalledRoot)"\r
} else {\r
- Assert-ExitCode $proc.ExitCode 'WDK'\r
+ Write-Step 'Downloading WDK installer'\r
+ $WdkUrl = 'https://go.microsoft.com/fwlink/?linkid=2335869'\r
+ $WdkInstaller = Join-Path $TempDir 'wdksetup.exe'\r
+ Invoke-WebRequest -Uri $WdkUrl -OutFile $WdkInstaller -UseBasicParsing\r
+\r
+ Write-Step 'Installing WDK'\r
+ # wdksetup.exe is a 32-bit binary and runs under emulation on ARM64; the kit\r
+ # it lays down does include the ARM64 target headers, libs and tools (the\r
+ # signing/deployment tools under bin\arm64), so an ARM64 driver builds from\r
+ # an ARM64 host. Only the installer is emulated, not the toolchain.\r
+ $proc = Start-Process -FilePath $WdkInstaller -ArgumentList '/quiet /norestart' -Wait -PassThru -NoNewWindow\r
+ Write-Host " WDK installer exit code: $($proc.ExitCode)"\r
+ if ($proc.ExitCode -eq 2008) {\r
+ # 2008 = the WDK is already present; the installer has nothing to do.\r
+ Write-Host ' [WDK already installed (exit 2008) - treating as success]' -ForegroundColor Yellow\r
+ } else {\r
+ Assert-ExitCode $proc.ExitCode 'WDK'\r
+ }\r
}\r
}\r
\r
#\r
# Idempotent and non-fatal - it never aborts provisioning.\r
# ---------------------------------------------------------------------------\r
-Write-Step 'Windows Performance Toolkit (xperf / wpr / WPA)'\r
-$WptDirs = @(\r
- (Join-Path ${env:ProgramFiles(x86)} 'Windows Kits\10\Windows Performance Toolkit'),\r
- (Join-Path $env:ProgramFiles 'Windows Kits\10\Windows Performance Toolkit'),\r
- (Join-Path ${env:ProgramFiles(x86)} 'Windows Kits\10\Assessment and Deployment Kit\Windows Performance Toolkit')\r
-)\r
-function Find-WptDir { $script:WptDirs | Where-Object { Test-Path (Join-Path $_ 'xperf.exe') } | Select-Object -First 1 }\r
+if (Test-SetupStep 'Wpt') {\r
+ Write-Step 'Windows Performance Toolkit (xperf / wpr / WPA)'\r
+ $WptDirs = @(\r
+ (Join-Path ${env:ProgramFiles(x86)} 'Windows Kits\10\Windows Performance Toolkit'),\r
+ (Join-Path $env:ProgramFiles 'Windows Kits\10\Windows Performance Toolkit'),\r
+ (Join-Path ${env:ProgramFiles(x86)} 'Windows Kits\10\Assessment and Deployment Kit\Windows Performance Toolkit')\r
+ )\r
+ function Find-WptDir { $script:WptDirs | Where-Object { Test-Path (Join-Path $_ 'xperf.exe') } | Select-Object -First 1 }\r
\r
-$WptDir = Find-WptDir\r
-if ($WptDir) {\r
- Write-Host " OK: WPT already present ($WptDir)" -ForegroundColor Green\r
-} else {\r
- try {\r
- # The ADK manifest offers no ARM64 installer, so on ARM64 winget fetches\r
- # the x64 one; it runs under emulation and lays down a toolkit that does\r
- # include the ARM64 binaries. The SDK feature is the lighter route on any\r
- # architecture and is worth preferring if this fallback ever gives\r
- # trouble - see the winsdksetup.exe line in the comment above.\r
- if ($IsArm64) {\r
- Write-Host ' ARM64: the ADK installer is x64 (emulated); the toolkit it installs is ARM64.' -ForegroundColor Yellow\r
+ $WptDir = Find-WptDir\r
+ if ($WptDir) {\r
+ Write-Host " OK: WPT already present ($WptDir)" -ForegroundColor Green\r
+ } else {\r
+ try {\r
+ # The ADK manifest offers no ARM64 installer, so on ARM64 winget fetches\r
+ # the x64 one; it runs under emulation and lays down a toolkit that does\r
+ # include the ARM64 binaries. The SDK feature is the lighter route on any\r
+ # architecture and is worth preferring if this fallback ever gives\r
+ # trouble - see the winsdksetup.exe line in the comment above.\r
+ if ($IsArm64) {\r
+ Write-Host ' ARM64: the ADK installer is x64 (emulated); the toolkit it installs is ARM64.' -ForegroundColor Yellow\r
+ }\r
+ winget install --id Microsoft.WindowsADK --exact --silent --disable-interactivity `\r
+ --accept-source-agreements --accept-package-agreements\r
+ Write-Host ' Windows ADK (includes Windows Performance Toolkit) installed.'\r
+ $WptDir = Find-WptDir\r
+ } catch {\r
+ Write-Warning "WPT install failed: $($_.Exception.Message)"\r
+ Write-Warning 'Install manually: winget install Microsoft.WindowsADK, or add the'\r
+ Write-Warning 'Windows SDK "Windows Performance Toolkit" optional feature.'\r
}\r
- winget install --id Microsoft.WindowsADK --exact --silent --disable-interactivity `\r
- --accept-source-agreements --accept-package-agreements\r
- Write-Host ' Windows ADK (includes Windows Performance Toolkit) installed.'\r
- $WptDir = Find-WptDir\r
- } catch {\r
- Write-Warning "WPT install failed: $($_.Exception.Message)"\r
- Write-Warning 'Install manually: winget install Microsoft.WindowsADK, or add the'\r
- Write-Warning 'Windows SDK "Windows Performance Toolkit" optional feature.'\r
}\r
-}\r
\r
-if ($WptDir) {\r
- # Report what actually landed. wpa.exe is the piece people come looking for\r
- # and it is the one that is absent if a trimmed toolkit ever shows up.\r
- foreach ($tool in 'xperf.exe', 'wpr.exe', 'wpa.exe', 'wpaexporter.exe') {\r
- $p = Join-Path $WptDir $tool\r
- if (Test-Path $p) {\r
- Write-Host " $tool $((Get-Item $p).VersionInfo.ProductVersion)"\r
- } else {\r
- Write-Warning "$tool is missing from $WptDir"\r
+ if ($WptDir) {\r
+ # Report what actually landed. wpa.exe is the piece people come looking for\r
+ # and it is the one that is absent if a trimmed toolkit ever shows up.\r
+ foreach ($tool in 'xperf.exe', 'wpr.exe', 'wpa.exe', 'wpaexporter.exe') {\r
+ $p = Join-Path $WptDir $tool\r
+ if (Test-Path $p) {\r
+ Write-Host " $tool $((Get-Item $p).VersionInfo.ProductVersion)"\r
+ } else {\r
+ Write-Warning "$tool is missing from $WptDir"\r
+ }\r
}\r
- }\r
\r
- # The WPT installer normally adds this to the machine PATH itself (and the\r
- # Start Menu gets "Windows Kits > Windows Performance Toolkit" shortcuts for\r
- # WPA and WPR). Re-assert it anyway: on the machine PATH rather than a user\r
- # one so it also resolves for the non-interactive sshd sessions this box is\r
- # driven through, which build their environment from the registry PATH.\r
- # Compared trailing-backslash-insensitively - the installer's own entry has\r
- # one, and adding a second spelling of the same directory is just noise.\r
- $m = [Environment]::GetEnvironmentVariable('Path', 'Machine')\r
- if (-not $m) { $m = '' }\r
- $have = ($m -split ';') | Where-Object { $_.TrimEnd('\') -eq $WptDir.TrimEnd('\') }\r
- if ($have) {\r
- Write-Host " OK: $WptDir already in the machine PATH"\r
- } else {\r
- $new = if ($m.Trim()) { $m.TrimEnd(';') + ';' + $WptDir } else { $WptDir }\r
- [Environment]::SetEnvironmentVariable('Path', $new, 'Machine')\r
- Write-Host " Added $WptDir to the machine PATH (restart shells to pick it up)."\r
+ # The WPT installer normally adds this to the machine PATH itself (and the\r
+ # Start Menu gets "Windows Kits > Windows Performance Toolkit" shortcuts for\r
+ # WPA and WPR). Re-assert it anyway: on the machine PATH rather than a user\r
+ # one so it also resolves for the non-interactive sshd sessions this box is\r
+ # driven through, which build their environment from the registry PATH.\r
+ # Compared trailing-backslash-insensitively - the installer's own entry has\r
+ # one, and adding a second spelling of the same directory is just noise.\r
+ $m = [Environment]::GetEnvironmentVariable('Path', 'Machine')\r
+ if (-not $m) { $m = '' }\r
+ $have = ($m -split ';') | Where-Object { $_.TrimEnd('\') -eq $WptDir.TrimEnd('\') }\r
+ if ($have) {\r
+ Write-Host " OK: $WptDir already in the machine PATH"\r
+ } else {\r
+ $new = if ($m.Trim()) { $m.TrimEnd(';') + ';' + $WptDir } else { $WptDir }\r
+ [Environment]::SetEnvironmentVariable('Path', $new, 'Machine')\r
+ Write-Host " Added $WptDir to the machine PATH (restart shells to pick it up)."\r
+ }\r
}\r
}\r
\r
# and run it elevated; it installs unattended with\r
# intel-vtune-<version>_offline.exe -a --silent --cli --eula accept\r
# ---------------------------------------------------------------------------\r
-Write-Step 'Intel VTune Profiler (status only)'\r
-if ($IsArm64) {\r
- # Not a "not installed yet" case - there is no Windows-on-Arm build of VTune,\r
- # and there is nothing for it to sample: its whole value is reading Intel PMU\r
- # counters. Say so plainly and point at what does work here, rather than\r
- # printing a download link for a product this box cannot run.\r
- Write-Host ' n/a on ARM64: Intel ships no Windows-on-Arm build, and hardware event-based' -ForegroundColor DarkGray\r
- Write-Host ' sampling reads Intel PMU counters. Use the Windows Performance Toolkit above' -ForegroundColor DarkGray\r
- Write-Host ' (wpr / xperf to collect, wpa to analyse) for profiling on this box.' -ForegroundColor DarkGray\r
- Write-Host ' Arm also publishes Arm Performance Studio / Streamline for Arm PMU sampling.' -ForegroundColor DarkGray\r
-} else {\r
- $UninstallKeys = @(\r
- 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'\r
- 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'\r
- )\r
- $vtune = Get-ItemProperty $UninstallKeys -ErrorAction SilentlyContinue |\r
- Where-Object { $_.DisplayName -match 'VTune' } |\r
- Select-Object -First 1\r
- if ($vtune) {\r
- Write-Host " Installed: $($vtune.DisplayName.Trim()) $($vtune.DisplayVersion)" -ForegroundColor Green\r
- # The oneAPI layout keeps a `latest` junction beside the versioned directory,\r
- # so this path stays right across upgrades.\r
- $VTuneCli = Join-Path $vtune.InstallLocation 'vtune\latest\bin64\vtune.exe'\r
- if (Test-Path $VTuneCli) { Write-Host " CLI: $VTuneCli" }\r
+if (Test-SetupStep 'VTune') {\r
+ Write-Step 'Intel VTune Profiler (status only)'\r
+ if ($IsArm64) {\r
+ # Not a "not installed yet" case - there is no Windows-on-Arm build of VTune,\r
+ # and there is nothing for it to sample: its whole value is reading Intel PMU\r
+ # counters. Say so plainly and point at what does work here, rather than\r
+ # printing a download link for a product this box cannot run.\r
+ Write-Host ' n/a on ARM64: Intel ships no Windows-on-Arm build, and hardware event-based' -ForegroundColor DarkGray\r
+ Write-Host ' sampling reads Intel PMU counters. Use the Windows Performance Toolkit above' -ForegroundColor DarkGray\r
+ Write-Host ' (wpr / xperf to collect, wpa to analyse) for profiling on this box.' -ForegroundColor DarkGray\r
+ Write-Host ' Arm also publishes Arm Performance Studio / Streamline for Arm PMU sampling.' -ForegroundColor DarkGray\r
} else {\r
- Write-Host ' Not installed.' -ForegroundColor Yellow\r
- Write-Host ' https://www.intel.com/content/www/us/en/developer/tools/oneapi/vtune-profiler-download.html' -ForegroundColor Yellow\r
- $cpu = (Get-CimInstance Win32_Processor -ErrorAction SilentlyContinue | Select-Object -First 1).Manufacturer\r
- if ($cpu -and $cpu -notmatch 'Intel') {\r
- Write-Host " (This CPU reports itself as '$cpu' - VTune's hardware event-based sampling wants Intel silicon.)" -ForegroundColor Yellow\r
+ $UninstallKeys = @(\r
+ 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'\r
+ 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'\r
+ )\r
+ $vtune = Get-ItemProperty $UninstallKeys -ErrorAction SilentlyContinue |\r
+ Where-Object { $_.DisplayName -match 'VTune' } |\r
+ Select-Object -First 1\r
+ if ($vtune) {\r
+ Write-Host " Installed: $($vtune.DisplayName.Trim()) $($vtune.DisplayVersion)" -ForegroundColor Green\r
+ # The oneAPI layout keeps a `latest` junction beside the versioned directory,\r
+ # so this path stays right across upgrades.\r
+ $VTuneCli = Join-Path $vtune.InstallLocation 'vtune\latest\bin64\vtune.exe'\r
+ if (Test-Path $VTuneCli) { Write-Host " CLI: $VTuneCli" }\r
+ } else {\r
+ Write-Host ' Not installed.' -ForegroundColor Yellow\r
+ Write-Host ' https://www.intel.com/content/www/us/en/developer/tools/oneapi/vtune-profiler-download.html' -ForegroundColor Yellow\r
+ $cpu = (Get-CimInstance Win32_Processor -ErrorAction SilentlyContinue | Select-Object -First 1).Manufacturer\r
+ if ($cpu -and $cpu -notmatch 'Intel') {\r
+ Write-Host " (This CPU reports itself as '$cpu' - VTune's hardware event-based sampling wants Intel silicon.)" -ForegroundColor Yellow\r
+ }\r
}\r
}\r
}\r
\r
# ---------------------------------------------------------------------------\r
+# A selected step that no section above asked about means this script and the\r
+# catalog disagree - an Id renamed in one and not the other, or a row added with\r
+# nothing behind it. That is a failure: the plan promised a step that was not\r
+# taken.\r
+$neverAsked = @($RunSteps | Where-Object { -not $AskedSteps.Contains($_) })\r
+if ($neverAsked) {\r
+ throw "Selected in the plan but not implemented by setup-windows-with-uac.ps1: $($neverAsked -join ', ')"\r
+}\r
+\r
Write-Host "`nAll done." -ForegroundColor Green\r
Write-Host "Host architecture was $HostArch."\r
Write-Host 'If a reboot was flagged above, restart before opening VS or building drivers.'\r
vilimpoc.org / repos / dotfiles / blobdiff