mirror of
https://github.com/ChrisTitusTech/winutil.git
synced 2026-10-08 11:39:10 +11:00
MyDriftandChris Titus
283b9954f1
* 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>
40 lines
1.8 KiB
PowerShell
40 lines
1.8 KiB
PowerShell
#===========================================================================
|
|
# Tests - Generated control lifetime
|
|
|
|
BeforeAll {
|
|
$script:repoRoot = (Resolve-Path (Join-Path $PSScriptRoot "..")).Path
|
|
$script:xamlText = Get-Content -Path (Join-Path $script:repoRoot "xaml\inputXML.xaml") -Raw
|
|
|
|
# Names that exist only once a tab has been built from config
|
|
$script:generatedNames = @(
|
|
Get-ChildItem -Path (Join-Path $script:repoRoot "config") -Filter *.json | ForEach-Object {
|
|
$config = Get-Content -Path $_.FullName -Raw | ConvertFrom-Json
|
|
$config.PSObject.Properties.Name
|
|
}
|
|
) | Sort-Object -Unique | Where-Object { $script:xamlText -notmatch "Name=`"$([regex]::Escape($_))`"" }
|
|
}
|
|
|
|
Describe "Generated controls" {
|
|
# Tab content is built after first paint, so anything referencing a generated control from
|
|
# the interface build runs while that control is still $null. That produced three silent
|
|
# "You cannot call a method on a null-valued expression" errors.
|
|
It "are not touched while the interface is being built" {
|
|
$uiScript = Get-Content -Path (Join-Path $script:repoRoot "functions\private\Start-WinUtilUserInterface.ps1") -Raw
|
|
|
|
$referenced = @(
|
|
[regex]::Matches($uiScript, '\$sync(?:\["([A-Za-z_][A-Za-z0-9_]*)"\]|\.([A-Za-z_][A-Za-z0-9_]*))') |
|
|
ForEach-Object { if ($_.Groups[1].Success) { $_.Groups[1].Value } else { $_.Groups[2].Value } }
|
|
) | Sort-Object -Unique
|
|
|
|
$tooEarly = @($referenced | Where-Object { $script:generatedNames -contains $_ })
|
|
|
|
if ($tooEarly.Count -gt 0) {
|
|
throw "Start-WinUtilUserInterface touches generated control(s) that do not exist yet: $($tooEarly -join ', '). Wire them from Initialize-WinUtilInstallTabControls or the tab that creates them."
|
|
}
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|