Toggles are identified by name prefix, not by the Type field, so the
WPFTweaks-prefixed key made Reset-WPFCheckBoxes treat this entry as an
ordinary checkbox and force it off on every tab build, deleting the
NoLockScreen value it had just set.
Closes#5060
* chore(dns): remove Mullvad DNS providers
Mullvad is shutting down its public encrypted DNS servers and sponsoring
Quad9 instead, so the six Mullvad profiles would resolve nothing once the
servers go dark.
Drops the Mullvad entries from config/dns.json, trims them out of the
WPFchangedns ComboItems, and removes the matching bullets and the
DoH-fallback note from the tweaks guide. Quad9 already ships as a provider,
so users have a documented destination.
The generated code-reference page for this tweak is left alone; the
pre-release workflow regenerates it from config/tweaks.json.
* test(dns): use generic fixtures for DoH-only providers
The DoH-only and SecondaryDohTemplate paths in Set-WinUtilDNS were covered
by fixtures named after Mullvad and carrying its real resolver addresses.
Those code paths still exist, so the coverage stays; only the naming was
tied to a provider WinUtil no longer ships.
Renames the fixtures to DohOnlyProvider and DohOnlyNoSecondary and swaps in
RFC 5737 / RFC 3849 documentation addresses and example.com templates, so
the tests no longer read as if they exercise a shipped provider.
* Add a job layer for long running work
- Start-WinUtilJob owns busy state, progress, taskbar, logging and errors
- Write-WinUtilJobProgress reports from a job without UI checks in the body
- Post UI updates instead of waiting on the dispatcher for each one
- Move Invoke-WPFInstall onto it as the first workflow
* Move the remaining app and feature workflows onto the job layer
- Uninstall, AppX install, Features, OOSU and installed detection
- Drop the per workflow busy flag, progress, taskbar and error handling
- Rework their tests to check the job and its body instead of runspace internals
* Run the WinUtil interface on its own thread
main.ps1 now only manages the run: it creates a dedicated STA runspace for
the window, waits for it, and reports whatever the interface thread failed
with. The interface itself moved into Start-WinUtilUserInterface, so the
thread that owns the window does nothing but paint and dispatch.
- New-WinUtilSessionState builds one starting point for both the interface
runspace and the worker pool, carrying $sync, the compiled script globals
and every WinUtil function. The pool previously copied only functions
matching winutil|WPF, which is not enough for a runspace that has to build
a tab.
- Invoke-WPFUIThread hands work to the interface runspace as body text plus
parameters instead of marshalling a scriptblock. A scriptblock keeps the
session state it was written in; running one across runspaces loses the
caller's variables on an async post and costs roughly twenty times as much
per command, which turned a checkbox refresh into a multi-minute freeze.
- Both helpers stop at a shut-down dispatcher, so a job that outlives the
window finishes quietly.
* Move every long workflow onto the job layer
Tweaks, undo, AppX removal and the five Win11 Creator workflows now go
through Start-WinUtilJob like the install workflows already did. That
removes the five hand-built STA runspaces and the function-definition
injection the ISO code needed to reach its own helpers.
- One busy flag: $sync.ActiveJob replaces ProcessRunning and
Win11ISOProcessRunning, and only the job layer writes it.
- Write-WinUtilJobProgress -Hide absorbs the last use of
Set-WinUtilTweaksProgressIndicator, so the progress bar and taskbar item
have a single owner. The helper is gone.
- Show-WinUtilMessage marshals onto the interface thread and logs the
prompt, so a job body can ask a question without knowing which thread it
is on. The raw MessageBox calls in the ISO workflows are gone.
- Win11 Creator status-log lines also go to the session log, and the
per-workflow Log/SetProgress helpers are gone.
- Get-WinUtilOscdimgPath and Get-WinUtilFreeDriveLetter are now real
functions rather than nested ones, so the pool can resolve them.
* Log from every WinUtil thread into one session file
Start-Transcript only records the runspace it was started on, so every line
a worker or the interface logged was being dropped. Write-WinUtilLog now
appends to the session log directly, serialized with a named mutex, and the
console transcript gets its own file in the same logs directory.
* Document the threading model and the job layer
* Stop Invoke-WPFUIThread leaking the body's output to its caller
The helper returned whatever the body produced, including a bare $null. Callers written
against the old void signature then returned an array instead of their own value:
Get-WinUtilSelectedPackages handed back @($null, $split), both package lists read as empty,
and Install and Uninstall reported success without installing or removing anything.
Output is now suppressed unless -PassThru is asked for, which only Show-WinUtilMessage needs.
Covered by tests on both the helper and the package split.
* Put every button that changes the system on the job layer
Invoke-WPFButton now classifies the press instead of running it. Anything that changes the
system gets a job; tab switches, selection helpers, window chrome and the WPFPanel* applet
launchers stay on the interface thread. Updates, the Ultimate Performance plan, the Fixes
buttons, OpenSSH Server, the system repair scan and the AppX query previously ran inline,
which froze the window, produced no progress and interleaved their output with a running job.
The job layer also owns the console banner now. Write-WinUtilJobBanner draws it once, so the
eleven hand-drawn === boxes are gone and every operation announces its start, not only its end.
- The job is named after what the button says, read from the config or the control itself,
so there is no second list of labels to keep in step.
- Show-WinUtilMessage replaces the last raw MessageBox calls, which could not have worked
from a worker thread.
- Write-WinUtilJobProgress replaces the last direct Set-WinUtilTaskbaritem calls.
* Document button routing and the job banner
* Read function bodies from the FunctionInfo instead of the function provider
Building the session state is on the path to first paint, and going through
function:\ for every function cost about as much as the whole interface
runspace saved. Time to first window is back level with upstream.
* Render the taskbar overlays after first paint
The logo overlay render costs about 55ms and nothing can see it until the window
is up, so it no longer sits between the interface being built and being shown.
Both the logo and the status overlays are now rendered from the same deferred
call once the window has painted.
* Make a failed package fail the job
Both package helpers ran the manager and moved on regardless of its exit code, so
a run in which nothing installed still reported success with a green checkmark.
They now emit a result per package, classified from the exit code: succeeded,
skipped for WinGet telling us there was nothing to do, or failed. The workflow
collects them and Complete-WinUtilPackageRun prints the summary and throws when
anything failed, which is what puts the job into its failed state.
* Time every pipeline step and report the slowest ones
Measure-WinUtilStep wraps a step, passes its output through untouched, logs how
long it took and keeps the record. Every job and the interface build end with a
summary ranking the slowest steps and their share of the total, so "which tweak
is taking forever" and "what is holding up startup" are answerable from the log
instead of by guessing.
Wired into the interface build, each tweak, each undo, each feature, and each
package. Jobs also log their own wall-clock duration, and the interface logs the
moment it can first service input.
* Render the taskbar overlays on the main thread's runspace
The overlays need an STA thread, which the worker pool is not, so they get one of
their own. Starting it from the interface thread cost more than it saved: opening
the runspace took 154-221ms there against 88ms of rendering. Starting it from the
main thread instead is free, because that thread does nothing but wait for the
window, and the render then overlaps the interface build.
Measured over three runs each, time from start to the interface accepting input:
2071/2105ms before, 2105/2131/2193ms started from the interface thread,
2026/2044/2050ms started from the main thread.
Also caches the session state, which two runspaces now share, and moves the
runspace cleanup registration into its own function for the second caller.
* Cut startup to first interaction roughly in half
- wire button clicks by type name against a HashSet, not a pipeline per $sync key: 335ms to 81ms
- build no tab content before first paint; Invoke-WPFTab already builds the tab it activates
- group apps by category into Lists, not by appending to arrays
- interface built ~1460ms to ~465ms, ready for input ~2090ms to ~858ms
* Warm the unopened tabs while the interface is idle
- queue each remaining tab at ApplicationIdle priority after first paint
- one tab per queued operation so input is serviced in between
- first click on a tab no longer pays for its build
* Report failures with the context needed to act on them
- Write-WinUtilErrorRecord logs message, exception type, command, line and script stack
- used by the job layer, the button funnel, the interface dispatcher and the main thread
- route buttons to the job layer by whitelist, so chrome and popup toggles stop starting empty jobs
* Wire the Install tab controls where they are created
- ChocoRadioButton, WingetRadioButton and the install action buttons come from
appnavigation.json, so they do not exist until the Install tab is built
- the interface build wired them anyway, which is the three null-reference errors
reported on close since tab content moved behind first paint
- Initialize-WinUtilInstallTabControls now does it from the tab build, guarded
- offline mode disables the install buttons from there too, for the same reason
- new test fails if the interface build touches any config-generated control
* Stop losing warnings and non-terminating errors from job bodies
- a worker buffers its warning and error streams on an object nobody reads:
Write-Warning never reached the log, Write-Error reached nothing at all
- the job layer merges both into the log, so all 30+ Write-Warning and 4
Write-Error sites in the helpers are visible without touching each one
- the interface runspace warning stream is drained on exit too
- $sync.LoggedErrors counts error events, detail lines excluded
- a job that logged errors without throwing now finishes as "N error(s)"
with a warning overlay instead of a green checkmark
* Drive winget through Microsoft.WinGet.Client for real progress
The winget CLI hides its progress bar as soon as its output is redirected, so a
package could only ever be reported as started and finished. The module reports
progress and returns a structured result.
- Install-WinUtilWinGetClient installs and imports the module, cached per session
- Invoke-WinUtilWinGetCommand runs a cmdlet on a nested PowerShell and polls its
progress stream, which cannot be redirected like output or errors
- percentages map into the package's slice of the job bar: "7zip.7zip - 1.9 MB / 1.9 MB"
- outcome comes from Status and InstallerErrorCode, not an exit code
- a package already present is upgraded, not reinstalled: Install-WinGetPackage
re-downloads and re-runs the installer even without -Force
- detection uses Get-WinGetPackage and matches on name as well as id, so apps
installed outside winget are recognised (Brave, and every other ARP entry)
- falls back to the command line unchanged when the module cannot be installed
Verified against real winget in the eval VM, 12 checks; 545 unit tests pass.
* Show the install phase as running instead of finished
Measured what the module actually emits: 7 progress records whether the package
is 1.9 MB or 57.8 MB, only two of them download samples, and the install phase
reports 0 then 100 with nothing between. On VLC the install is 4.3s of the 9.7s.
- the download gets the first half of the package's slice, so reaching 100%
download no longer fills the bar
- the install phase pulses the bar and counts elapsed seconds in the label,
because neither winget nor the module exposes installer progress
- scan the whole progress collection, not just its last record: a byte sample
can be superseded within milliseconds
- RoundedProgressBarStyle gained an indeterminate trigger; it had none
Fixes uninstall reporting a package that is not installed as a failure, which is
what UninstallError after 354ms was, and adds ExtendedErrorCode to the detail.
* Say what a winget failure actually was
The command line prints a sentence for a failure; the client module returns only
an HRESULT, so the same failure read as "COMException (0x8A15007D)". Both report
the same number, so one table serves both paths.
- Get-WinUtilWinGetErrorMessage explains the codes WinUtil hits, and gives the
hex plus the return-code reference for anything else
- 0x8A15007D now reads: installed for a single user, cannot be removed while
running as administrator, remove it from Settings > Apps
- unsigned HRESULTs are wrapped rather than cast, which overflowed Int32
- a shared failure reason is repeated in the thrown message
- the banner wraps at 76 columns instead of drawing a box wider than the console
* Keep the run position in the progress text during a package
- the bar itself was already whole-workflow: 0-12, 25-37, 50-62, 75-87, 100
- but the status read "A.A - 50% downloaded", dropping the (n/total) the old
per-package messages carried
- callers pass a label, so it now reads "A.A (1/4) - 50% downloaded"
* Pulse the progress bar in place instead of filling it
- IsIndeterminate makes WPF discard Value and stretch the indicator across the
whole track: measured 398px of a 400px track at value 40, against 159px correct
- the pulse is driven by Tag instead, so the bar keeps the progress it reached
- RemoveStoryboard on exit, because Stop left the indicator at whatever opacity
the pulse happened to be on
* perf: cut Install tab build and keep the interface answering during warmup
- look apps up by hashtable index, not dynamic member: Install tab app area 361ms -> 91ms
- cap a render pass at 25 apps so a large category cannot stall the interface
- yield between batches when building speculative tab content
- claim a tab as initialized before building it, so a click during a yield cannot double build
- time each step of a tab switch
* xaml: drop layout elements and styles that do nothing
- remove 8 single child wrappers from control templates, one per instance of every button, toggle and tweak switch
- delete unreferenced labelfortweaks and ScrollVisibilityRectangle styles
- verified pixel identical across all five tabs
* fix: bring the last workflows into the job layer
- upgrade all runs package by package on the worker instead of spawning a console
- PS profile setup runs pwsh with output captured, not a Windows Terminal tab
- resolve the PS7 profile path from pwsh, so remove targets the file install wrote
- treat winget exit 3010 and 1641 as success; a reboot requirement is not a failure
- drop the power plan success popups, the job layer already reports the result
- load PresentationFramework before a message box on a worker, and log if it cannot show
- probe optional commands with -ErrorAction so a missing choco does not throw
- refresh PATH after installing chocolatey
* fix: keep the runspace handle out of the console and the pipeline
- suppress the IAsyncResult Start-WinUtilJob got back, which printed a table on every button press
- test fails if any caller leaves Invoke-WPFRunspace unassigned
* fix: choco parity with winget, and prompts that cannot hang or assume consent
- choco runs one package per call, so progress moves and a failure names the package
- add an Upgrade action; upgrade all was building "choco install all", which is not a package
- explain a choco failure from its own output instead of reporting a bare exit code
- pass a progress slice to choco from install and uninstall, as winget already gets
- never show a message box without a window: a modal there never returns
- an unanswerable prompt answers No, so it can never stand in for consent
- uninstall requires an explicit Yes rather than the absence of a No
* feat: headless runs report and finish on their own
- progress goes to the console when there is no window, throttled so downloads do not bury it
- one entry point for preset and config; a preset can now be a baseline a config adds to
- apply selected toggles, which only ever applied themselves from the window
- exit code carries the outcome: 0 clean, 1 problems, 2 nothing selected
- elevation waits for the elevated run and hands its code back
- per step timeout, so an installer that never returns cannot hang the run for good
- a step that throws no longer abandons the remaining steps
- name an unrecognised config entry instead of failing on a null list, and ignore duplicates
- import with no window logs instead of throwing on a message box type it cannot load
- temp file cleanup skips files in use rather than reporting each as an error
* perf: stop the interface stalling while the app list loads
Measured with a new input-priority heartbeat: 2669 ms unresponsive across 18
stalls, worst 399 ms. Now 502 ms across 5, worst 151 ms, and nothing after the
first three seconds.
- cache app icons on disk and fetch the missing ones on a worker; assigning a
remote address to an Image made WPF fetch and decode it, landing back on the
interface thread whenever the network answered, for a minute after startup
- share the six app entry event handlers instead of building them per entry:
3.18 ms to 1.36 ms per entry, measured
- slice rendering and tab building by a deadline rather than an entry count, so
a slower machine cannot turn a batch into a stall
- yield while building the tab opened at startup, as the warmup already did
- reject a ParameterList that is a flattened pair; it silently ran the worker
with two characters of the parameter name and did nothing
- add Start-WinUtilUIHeartbeat behind WINUTIL_TRACE_UI to measure any of this
* fix: build the other tabs before finishing the app list
Tab warmup was queued at idle priority while app rendering was queued at
background priority, so no tab was warmed until every render pass had run.
For the first few seconds every tab except the open one was empty, and
clicking one paid for its whole build: Tweaks measures 400-530 ms.
Verified from the log: all tabs were ready after 32 of 32 background steps
before, and after 5 of 32 now.
- warm tabs at background priority so they are not starved by the app list
- hold app rendering while any tab is still unbuilt
- stand aside for 400 ms after input, and skip drawing entries for a tab that
is not on screen, resuming when it is
- report the whole latency distribution rather than only gaps over 60 ms; a
thread kept busy by short pieces of work showed no stall while every
interaction still waited behind the piece in flight
* fix: ask before closing over running work, and shut down in order
Closing while a job ran tore the worker pool down underneath it. A queued
instance then started on a runspace already in Closing, threw on a thread
pool thread where nothing catches, and ended the process with an unhandled
InvalidRunspaceStateException instead of exiting.
- ask whether to wait for the running job or stop it, and keep the window
open if the close is cancelled
- track what is running so it can be stopped, and stop it before closing the
pool rather than pulling the runspaces away from it
- refuse to queue new work once shutdown has begun
- close the window by itself once an awaited job finishes
- bound the wait, so a worker that cannot be stopped does not keep the window
open for ever
- phrase the question so the buttons answer it in any language; Windows labels
them itself and text naming them Yes and No does not match Ja and Nein
- treat a missing collection as empty; @($null) is a one element array, which
read as one running item when nothing was running
* fix: let a running job finish in the console after the window is closed
Waiting kept the window open until the job ended, which is not what closing
it means. The window now goes at once and the run continues where it can
still be seen, ending the process when it is done.
- close the window immediately and leave the job on the worker pool
- skip the pool shutdown on that path; it would stop the work just kept
- wait for the job on the main thread, then close the pool and exit
- treat a shut down dispatcher as no window, so progress reaches the console
instead of being posted to a dispatcher that drops it
- bound that wait, so a job that never returns cannot hold the process open
- guard the close post against a window that has already gone
* feat: pause button, and progress that rewrites its line
- add a pause button beside the progress bar; a run holds at the point every
loop reports progress, since a command already started cannot be suspended
- hold only inside a job worker: whoever presses pause reports it through the
same progress call and would otherwise wait on itself
- clear the pause once the body returns, or the finish reporting pauses too and
the job stays marked running for ever
- release it when the window is closed over the job, since there is then no
button left to resume with
- rewrite the console progress line in place rather than adding one line per
update; a single install scrolled a screenful
- keep one line per update when output is redirected, where there is no cursor
to move, and throttle harder there
- say goodbye where the process actually ends; closing can be declined or leave
a job running
* feat: stop button for the running action
- add a stop button beside pause; it asks first, since stopping an install
halfway is not undoable
- end the run at the same safe point a pause holds at, so anything already
started finishes and nothing is cut in half
- report it as stopped rather than failed, through its own cancellation
- clear the stop before reporting it, or the report throws it again from inside
the handler doing the reporting
- release a pause when stopping, or the run would never reach the point where
it notices
- cut the worker off after a grace period, since a single long step reaches no
safe point until it returns
- reset both flags per job, so a late stop cannot end the next run
* fix: use a stop glyph that does not look like a missing one
U+E71A is a hollow square at button size and reads as the empty box a font
shows for a code point it lacks. U+E73B is the filled square.
- add a test that every private use code point in the markup and the scripts
exists in Segoe MDL2 Assets
* fix: icon buttons render in the icon font, not a fallback
A char assigned to Content is not laid out with the control's own font. It
falls back to whatever font claims the code point and is drawn in that font's
colour and metrics, which is why the pause icon came out teal and a different
size from the cross beside it. Add-SelectedAppsMenuItem already cast to string
for the same reason.
- cast every icon assignment to string: pause, play, the app entry popup and
the theme button
- use the cancel cross for stop; a square is a blank block at button size
whether it is filled or hollow
- test that no icon reaches Content as a char
* fix: the font scaling slider goes where it is clicked
WPF leaves IsMoveToPointEnabled off, so a click on the track pages by
LargeChange instead of moving the thumb to the pointer. LargeChange defaults
to 1.0, which over a range of 0.75 to 2.0 is most of the track, so clicking
anywhere toggled between 100% and 200%.
- follow the click, and page by one tick rather than a full unit
- test that every slider does both
* fix: draw the logo at the size it is asked for, and give the window its own icon
The rasteriser built the bitmap from the canvas rather than the requested
size, so every render came out 100 by 100 whatever was asked for: a 32px icon
was that downscaled, and anything larger was an upscale. The canvas was also
smaller than the artwork, whose paths run to about 108 by 110, so the right
and bottom edges were cut off. Between the two, the logo covered about a third
of the icon it was drawn into.
- rasterise from the geometry's real bounds into a bitmap of the requested
size, centred and filling the frame
- keep the shapes in one place, so the control and the bitmap draw the same art
- set the window icon at the sizes the system reports for this display, small
and large, instead of leaving Windows to scale one bitmap
- hold the icon handles for the life of the window and free the ones replaced
* fix: give the nav logo its square box back
Fitting the box to the artwork left no room around it. The logo is taller than
it is wide, so a square control filled by it edge to edge sat against the tab
buttons next to it.
- centre the artwork in a square box with a small margin, so the control fills
the size it was given rather than the artwork's own proportions
- the bitmap form is unchanged and still fills the frame, which is what an icon
wants
* refactor: one background queue, one UI-alive check, drop the stall tracer
- move the DPI window icon work out to feat/dpi-window-icon and revert it here
- drop Start-WinUtilUIHeartbeat: it found the startup stalls, it is not
something a normal run should carry
- add Start-WinUtilBackgroundQueue and put tab warmup and app-entry rendering
on it; they were the same pump written twice
- add Test-WinUtilUIAlive, replacing the same dispatcher guard hand-written
eleven times in three spellings
- carry the queue name as the dispatcher's own argument, not a captured
variable, so the posted step still resolves where it was written
- give Invoke-WinUtilWhenIdle an -Argument for the same reason
- load the WPF assemblies in preferences-theme tests instead of relying on
logo-render having loaded them first
* docs: bring the agent rules in line with the job layer
Section 13 still pointed at Set-WinUtilTweaksProgressIndicator, which the job
layer removed, and said nothing about the pieces that replaced it.
- point the UI-helper rule at Write-WinUtilJobProgress and Test-WinUtilUIAlive
instead of the deleted progress indicator
- say that long operations go through Start-WinUtilJob, and that a job body
owns neither the busy flag, the banner, nor its own interface handling
- send deferred interface work through Start-WinUtilBackgroundQueue rather
than a fourth hand-rolled pump
- record how values reach a posted scriptblock, and why a closure is the wrong
answer: it carries the value but binds command lookup to a copied scope
- state that diagnostic scaffolding is measured with and then deleted
- require each Pester file to load what it needs; several passed only because
an earlier file in alphabetical order had loaded it
* refactor: trim the package work back to what the pipeline needs
The winget client module earns its place: winget.exe hides its progress bar
once its output is redirected, so the CLI can never say how far along an
install is and the progress bar has nothing to show. What rode in behind it
did not.
- keep the module, the per-package progress and the result objects both
managers now return; those are what the job layer reports from
- take the action from the caller instead of probing the machine first:
Install, Uninstall and Upgrade each pick their own cmdlet and verb, matching
the set Install-WinUtilProgramChoco already takes
- drop the Get-WinGetPackage probe with it, which cost a nested call per
package and made the module path mean "install or upgrade" while the command
line path still meant "install"
- send the upgrade workflow through -Action Upgrade, which is what it was
always asking for
- revert Invoke-WinUtilCurrentSystem to the command line; reading which apps
are installed has nothing to do with reporting progress
- cut the winget and choco error tables: the hex code and Microsoft's own list
say the same thing without a copy to keep in step, and choco's reason is
already in the output that gets logged
* test: drop the tests that assert on source text
Sixty-six tests read a function file and regex-matched its contents, so they
failed on edits that changed no behaviour: ten of them broke during a refactor
that only moved code between files. A test that pins how something is spelled
is an edit detector, not a test.
- remove the It blocks that Get-Content a .ps1 and match against it, and the
Describe blocks left with nothing in them
- keep the ones that read source to check a set rather than a spelling, such as
every WPF handler resolving to a defined function and every $sync member
being declared; those catch a real mistake
- drop Get-WinUtilFunctionFile, which had no callers left
* fix: make the active job slot safe to claim and release
Three defects in the job layer's shared state, all of them races that the
dispatcher happened to hide.
- claim $sync.ActiveJob under the collection's own lock. Interface events are
serialised by the dispatcher, but a headless run, a scheduled caller and a
job body starting another job are not, and a test-then-assign there let two
jobs both believe they owned the slot
- identify a run by token rather than by name. A worker the stop watchdog cut
off can still be unwinding when the next job starts, and its finally block
released the slot unconditionally, wiping the claim the next job had just
made. Both the worker and the watchdog now release only what they still own
- rename Write-WinUtilJobProgress to Step-WinUtilJob. Write- in PowerShell
means adds to a stream, and this blocks while paused and throws
OperationCanceledException on stop. The trap was already live: the job layer
has to clear both flags before its own finish reporting or that reporting
re-raises the stop it is reporting
Also corrects the cross-runspace cost noted in the tests. Marshalling a
scriptblock is not "roughly twenty times" dearer; measured over 400 command
invocations it is 5354 ms against 3 ms rebuilt from text, because every command
the body invokes is resolved back through the originating runspace.
* refactor: drop the WinGet client module from this branch
The module is the one thing here that adds a runtime dependency: 53 MB from
PSGallery on first use, fetched at elevated privilege. It buys progress
movement inside a single package and nothing else. That is a different kind of
change from the rest of this branch, which only moves work between threads, and
it deserves to be judged on its own.
- remove Install-WinUtilWinGetClient and Invoke-WinUtilWinGetCommand
- collapse Install-WinUtilProgramWinget onto the command line path it already
had underneath, keeping the per-package result objects, so a failed package
still fails the job
- drop ProgressBase, ProgressSpan and Label from the winget path, which only
existed to slice the bar inside one package. Chocolatey keeps its own: it
reports per package from its own loop and never needed the module
- read upgradable packages from the winget command line output again
Kept on feat/winget-client-module, which branches from here.
* docs: follow the Write-WinUtilJobProgress rename in the architecture page
* fix: address the review findings on the job layer
Ten findings held up on inspection. The first two were breakage this branch
introduced.
- run a nested Start-WinUtilJob inline instead of refusing it. Install Features
reaches the job layer twice, once through its feature.json entry and again
from Invoke-WPFFeatureInstall, so the inner call was refused and features
never installed
- read the package manager preference rather than ChocoRadioButton.IsChecked in
Invoke-WPFInstallUpgrade, which runs on a worker where touching a control
throws
- pass parameters and return values through the Invoke-WPFUIThread fallback.
[action] carries neither, so Show-WinUtilMessage lost both its arguments and
its answer whenever the dispatch delegate was not yet built
- register a shell after BeginInvoke, not before: a NotStarted instance looks
finished to the pruning pass and could be dropped before shutdown saw it
- clear $sync.ActiveJobToken wherever the slot is released, through one
Clear-WinUtilActiveJob helper. Clearing only the name left a token that could
match a later run
- clear $global:WinUtilIsJobWorker when a worker finishes. Pool runspaces are
reused, so the flag outlived the job that set it
- set the pause and stop button state through the dispatcher
- take a locked snapshot of $sync.ActiveShells before enumerating it, and create
the collection under the lock
- stop the watchdog waiting on the interface thread. It issues the stop and
watches later ticks instead of sleeping for up to ten seconds
- throw rather than return on the ISO failure paths, which the job layer was
reporting as finished, and check exit codes in Invoke-WPFSystemRepair and
Invoke-WPFUltimatePerformance so a failed step fails the job
- give the pause and stop buttons AutomationProperties.Name; their content is a
private-use glyph
* fix: address the remaining review findings
Seven more held up. The first is the one that mattered most and this branch
introduced it.
- separate recycling a runspace pool from shutting down. Initialize-WinUtilRunspacePool
replaces a pool that is no longer open by calling Close-WinUtilRunspacePool,
which set $sync.ShuttingDown. Nothing resets it, so a single recycle made the
job layer refuse every later action for the rest of the session
- bound the ISO mount wait at 60 seconds. The loop had no exit but success, and
one job runs at a time, so a damaged or already-mounted image blocked every
other action and the shutdown wait
- check robocopy exit codes in both ISO and USB workflows through one
Invoke-WinUtilRobocopy. Codes of 8 and above mean files were not copied, which
produced media that reported complete and did not boot
- read oscdimg stderr as it arrives. Draining stdout first and stderr afterwards
deadlocks once the stderr pipe fills
- look for oscdimg on PATH, in both ADK roots and in the per-user WinGet package
root, using the same search before and after the install attempt
- set the child error preference to Stop for the profile setup, and fail on
captured error records. A non-terminating failure exited zero and was reported
as installed
- confirm each id parsed out of the winget upgrade table against winget before
upgrading it, and keep stderr out of the parse. The table is localised and
truncated, so a wrapped version or a translated header matched the same shape
* fix: address the minor and nitpick review findings
The review body carried 38 findings beyond the 20 inline ones, in collapsed
sections. These are the ones that held up.
Real defects:
- the theme hook assigned to $handled instead of $handled.Value, so a
WM_SETTINGCHANGE was never marked handled
- a declined UAC prompt left $elevated null and exited 0, which a headless
caller reads as a successful run
- Start-Transcript ran before the log directory existed, so the first run failed
before logging started
- Write-WinUtilLog appended even when the mutex wait timed out, which is the
case with the most contention and the one that interleaves lines
- Wait-WinUtilRemainingWork took [int] minutes, so any fractional timeout
truncated to zero and the bound meant "do not wait"
- the console progress throttle only applied when the text was unchanged, so a
job reporting per package wrote on every call
- an undecodable icon response stayed in the cache and was skipped on every
later run
- Start-WinUtilAssetRendering leaked its dedicated STA runspace; the cleanup
callback now disposes a runspace it was given
- Invoke-WPFFixesWinget could not repair a broken WinGet, because
Install-WinUtilWinget returns early when winget is detected. Added -Force
- winget's own reboot-required and reboot-initiated codes counted as failures
Smaller:
- set TLS 1.2 and a timeout before fetching the Chocolatey bootstrap
- let the headless queue drain survive one failing item, as the dispatcher path
already does
- bind the idle timer to the interface dispatcher explicitly
- route the export message through Show-WinUtilMessage like the import branch
- suppress New-Item output that was reaching the job's output stream
Tests that could not fail:
- the bounded-wait test passed a fractional timeout that truncated to zero, so
the wait never ran
- the slider tests cast possibly-absent attributes to [double], and compared two
empty strings for the regression they exist to catch
* fix: startup crash and icons that only appeared once the list was drawn
Both were mine, and both were introduced while addressing review findings.
The crash. Register-WinUtilRunspaceCleanup compiles its helper type once and
guards that with a type-exists check, so a session already holding the old
shape keeps it. Adding a Runspace property to that type therefore failed on
every later run with "The property 'Runspace' cannot be found". The type is
back to exactly what it was, and the asset rendering runspace lives until the
process exits: one STA runspace for the lifetime of the app is the cheaper
trade against a helper type that cannot be changed safely in a session.
The icons. Start-WinUtilIconFetch ran from Complete-WinUtilInstallAppRendering,
so nothing was fetched until every entry had been drawn and no icon appeared
for the first several seconds. Upstream assigned a remote address per Image and
let WPF fetch them all at once, which is what made them appear promptly.
- fetch after each render batch instead, gated so one fetch runs at a time and
whatever queues up meanwhile is taken when that fetch ends
- clear the gate when the runspace refuses the work, or no fetch would ever run
again for the rest of the session
- request each wave together rather than one icon after another
Measured on a cold cache in a VM: first icons at 1.35s and all of them by 4.0s,
against nothing before roughly 7s previously.
* fix: address the second review pass
All three are in code this branch added.
- accept DISM exit code 3010 as success. It is ERROR_SUCCESS_REBOOT_REQUIRED,
meaning the image was repaired and the change lands on restart, so the exit
code check added in the last pass turned a successful repair into a failed
job. Carried per step, since the same number from chkdsk or sfc does not mean
that, and logged as a warning so the restart is not silent
- say what is happening on the WinGet repair path. Install-WinUtilWinget -Force
runs while WinGet is installed, and printed "WinGet is not installed"
- append to PATH after installing Chocolatey rather than replacing it.
Overwriting with the machine and user values drops whatever this process
added earlier in the session
* fix: treat chkdsk's own exit codes as the outcomes they are
- chkdsk /scan reports 1 and 2 as ordinary results, so aborting the whole
repair on them skipped sfc and dism for no reason
- 3 stays a failure: the disk could not be checked, and the later steps are
not worth running on a disk in that state
- drive the decision off each step's SuccessCodes instead of a branch
hard-coded to DISM's 3010, so the same number means what that step means
- cover chkdsk 0, 1, 2 and 3, and 3010 from the wrong step
* fix: address the Codex review findings on the job layer
- send WPFPanel buttons that carry a function through the job layer: the
system corruption scan waited on chkdsk, sfc and dism on the interface
thread, with nothing to pause, stop or report it
- stop a timed out headless step before starting the next one, and abandon
the run if it will not stop, rather than changing the machine from two
runs at once
- keep the stop watchdog's slot claimed until the worker has actually gone
- skip the install summary reset when the Install tab has not been built,
which offline startup does by opening Tweaks first
- keep Win11ISO out of the tab warmup: building it runs the existing work
check, which reports or prompts while the user is on another tab
- pass --include-unknown when upgrading, since the scan that found the
packages used it
* fix: stop the tab warmup dying on a sync that is still growing
- Reset-WPFCheckBoxes enumerated $sync live while setting IsChecked, whose
handlers add to $sync, and while the warmup was building controls into it;
either one invalidated the enumerator and the warmup reported "Collection
was modified"
- snapshot both loops
- cover it with a checkbox that grows $sync from its own handler, which
reproduces the failure without the fix
* fix: shrink the pause and stop buttons and take them away when idle
- they were sized like the title bar icons, next to a 6px progress bar
- give them a size of their own and the smaller icon font, which font
scaling still applies to
- collapsed unless a job is running: they were only ever disabled, so a
finished or failed run left two dead buttons on screen
- the progress bar still stays to report how the run ended
* fix: colour the progress bar by how the run ended
- only the taskbar item carried the state, so a run that finished with
errors left a full bar in the normal colour, reading as a clean finish
- the fill now follows the bar's Foreground, which the job layer points at
an error or warning colour and back again
- by resource reference, so switching theme repaints it
- add error and warning colours to both themes
* fix: stop rendering the app navigation twice, which left Install dead
- upstream moved the app navigation render into Initialize-WPFUI, and this
branch still rendered it beforehand, so it was built twice
- the second pass clears the target grid, and the "already wired" guard goes
by name, so the replacement buttons counted as wired and never got a click
handler: Install and Uninstall did nothing, with no error anywhere
- leave that render to Initialize-WPFUI
* fix: uninstall apps that belong to the signed in user
- WinGet answers APPINSTALLER_CLI_ERROR_ADMIN_CONTEXT_ACTION_PROHIBITED for
anything installed in user scope while it is running elevated, and WinUtil
is always elevated, so those uninstalls did nothing
- a process cannot drop its own elevation, so hand that one command to a
scheduled task running as the interactive user at limited run level
- retry only on that code, so everything else is untouched
* style: keep the ISO variable names the file already used
- new scriptblock parameters were named in PascalCase, which put 20 lines
into the diff that are otherwise identical to main
- nothing about the behaviour changes
* refactor: take the icon cache out of the job layer change
It is its own feature, not something consolidating background work needs.
Entries go back to assigning the favicon address to the image, as main does.
The work is kept on feat/install-icon-cache and follows once this lands.
* refactor: take pause and stop out of the job layer change
They are a new feature of their own, not part of consolidating background
work, and main has nothing like them today.
- drop the two buttons, their routing and the checkpoints that served them
- keep Stop-WinUtilActiveWork: closing the pool and the headless step
timeout both need to end work, and neither is the user pressing a button
The work is kept on feat/job-pause-stop and follows once this lands.
* refactor: drop changes the job layer does not need
- the icon glyph strings are a rendering fix of their own: main renders a
char, and whether that is right has nothing to do with background work.
Reverted here, kept on fix/ui-glyph-strings
- trim the temp cleanup tweak to the part this change forces: errors have to
be suppressed because the job layer counts a logged error as a failed
step, but counting what was removed is unrelated polish
* refactor: cut comments and wrappers that were not earning their place
- the Recycle switch explained itself over four lines; two say what a reader
needs to know
- drop a .PARAMETER that only restated the parameter name
- Unregister-WinUtilActiveShell had one caller and cost twenty lines, so it
is inlined
- the running check was the same try/catch three times over, now one helper
* refactor: comments describe the code, not how it got here
- remove five comments left pointing at code the icon and pause splits took
away, two of them sitting above unrelated lines
- cut the ones that recounted a bug rather than describing behaviour: the
double rendered navigation, the dropped [action] parameters, the shell
registered too early, the Add-Type shape
- shorten the rest to what a reader needs
* refactor: inline the winget error message at its only call site
- Get-WinUtilWinGetErrorMessage was 26 lines for a one line format string
- Its zero guard was dead: exit code 0 is handled by an earlier branch
- Drop the file and the two test dot-sources of it
* refactor: drop the user scope uninstall fix, it has its own branch
- Invoke-WinUtilUnelevated and the elevation retry are self contained
- They ship on fix/winget-user-scope-uninstall, which does not need the job layer
- Removes a file and 3 tests from a PR that is already large
* docs: tighten function help and comments
- Cut narrative framing from the job layer, queue and shutdown doc blocks
- Kept the technical reasons, dropped the restatements around them
* docs: drop comments that restate the code
- Consent check, powercfg exit codes, shortcut guard, rethrow, single reason
- Compact the UI thread helper's help
* fix: address async job layer review findings
* fix: harden job startup and dependency discovery
* fix: close remaining async review gaps
* fix: finalize shutdown and ISO recovery paths
* fix: guarantee job cleanup and error attribution
* fix: preserve job outcomes during cancellation
* fix: close async rendering and logging races
* fix: bound shutdown and surface UI startup failures
* fix: skip blocked user-scope install updates
* fix: address final PR review findings
* fix: warn on blocked user-scope package actions
* fix: propagate file-backed headless exit codes
* Address final async job review findings
* Resolve latest automated review findings
* Preserve clipboard history in activity tweak
---------
Co-authored-by: Chris Titus <contact@christitus.com>
* chore(tweaks): clarify Activity History tweak description
* fix(tweaks): preserve clipboard history
---------
Co-authored-by: Chris Titus <contact@christitus.com>
* Add tweak to block Logitech Download Assistant auto-install
Mirrors the WPFTweaksRazerBlock folder-deny approach: clear
C:\Program Files\LogiDownloadAssistant, recreate it empty, and deny
Everyone write access so the Windows Update software-component package
cannot re-deliver the payload. UndoScript removes the deny ACE.
Unlike the Razer tweak, no global SearchOrderConfig/DisableCoInstallers
registry changes: those alter driver search system-wide and do not stop
software-component packages.
Fixes#5029
* Harden Logi block tweak per review: SID, 64-bit path, exit codes
- Use the locale-independent *S-1-1-0 SID instead of the English
"Everyone" name, which fails to resolve on non-English Windows.
- Resolve the 64-bit Program Files directory via ProgramW6432 with a
ProgramFiles fallback, so a 32-bit host cannot target the x86 folder.
- Throw when icacls exits non-zero so Invoke-WinUtilScript logs the
failure instead of reporting the tweak as completed.
- Skip the undo icacls call when the folder no longer exists.
* docs: fix typo in contributing image asset and markdown references
* docs: fix typos and grammatical phrasing in documentation
* fix(config): correct typographical errors in tweak and app descriptions
* fix(scripts): resolve typos and grammatical errors in PowerShell sources
* fix: address review feedback on Outlook description, WinUtil capitalization, and grammar
* Update dns.json
* Fix Mullvad DNS review issues
* Add Mullvad secondary resolvers
* Register DoH before changing adapter DNS
* Report DNS failures to tweak workflow
* Handle non-terminating DNS assignment failures
* Preserve DNS fallback and document Mullvad options
---------
Co-authored-by: Chris Titus <contact@christitus.com>
* fix: repair popup install binding, dialog titles, presets switch, radio groups, JSON, tests
- Invoke-WPFInstall: add param block so the right-click app popup binds
-PackagesToInstall. It previously dropped the argument into $args and
installed the whole selected list instead of the clicked app (or warned
that nothing was selected).
- Replace undefined $AppTitle with "WinUtil" in Install/UnInstall warning
boxes, matching the XAML window title and sibling dialogs.
- tweaks.json: remove stray nested "link" inside the WPFToggleScrollbars
registry entry (dead property; registry entries expose only the six
consumed fields).
- Invoke-WPFPresets: fix dead switch cases to the wildcard-pattern
convention so selectedFeatures/selectedToggles clear correctly.
- Invoke-WPFUIElements: store the group StackPanel in radioButtonGroups so
grouped radio buttons share one container (else branch was unreachable).
- sanity.Tests.ps1: pass the Windows PowerShell parser script via
-EncodedCommand; -Command string marshaling corrupted backticks/quotes and
produced false parse failures.
- install-workflow.Tests.ps1: remove the AppTitle workaround and update
title assertions to "WinUtil"; drop orphaned cleanup lines.
- Add CHANGES.md with technical and plain-language explanations.
Verified: each bug reproduced against HEAD, fixes demonstrated to change
behavior, full Pester suite 471/471.
* Delete
* test: cover the explicit popup install parameter path
Add a regression test invoking Invoke-WPFInstall -PackagesToInstall with a
package different from the default sync.selectedApps selection and assert
the runspace receives the explicit object, mirroring the Initialize-WPFUI
popup call shape. Existing default-path coverage is unchanged.
