mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-08-29 10:09:43 +02:00
## Summary of the Pull Request Adds **Update and restart** and **Update and shut down** to the Windows System Commands extension, matching what Windows shows in the Start menu power flyout when updates are waiting for a reboot. Both only show up while Windows Update is actually waiting on a restart. When nothing is pending, the command list is exactly what it is today. ## PR Checklist - [x] Closes: #48849 - [x] **Communication:** commented on the issue before starting; zadjii-msft had greenlit the idea as long as the commands actually do something rather than just report status - [x] **Tests:** added and passing (27/27) - [ ] **Localization:** 6 new resx strings, each with a translator comment - [ ] **Dev docs:** n/a - [ ] **New binaries:** n/a ## Detailed Description of the Pull Request / Additional comments **Detecting the pending update.** `WindowsUpdateHelper.IsUpdatePending()` reads `ISystemInformation::RebootRequired` from WUAPI, which is the same signal the Start menu uses, so the commands appear exactly when Windows would offer them itself. A few notes on that file, since the interop is a bit unusual: - I used `[GeneratedComInterface]` rather than `ComImport` to keep it AOT-compatible. - `ISystemInformation` is a dual interface, so its first four vtable slots belong to `IDispatch`. They're declared as placeholder methods that are never called, and the two real members follow in vtable order. - The result is cached for 5 seconds. `GetItems()` runs on every keystroke and would otherwise create a COM object each time — same reasoning as the existing network info cache in this extension. - If anything goes wrong (COM creation fails, an exception is thrown) it falls back to "no update pending", so the commands stay hidden and the extension behaves exactly as it does now. The failure is logged through `ExtensionHost.LogMessage`. **Running the command.** `InitiateShutdown` with `SHUTDOWN_INSTALL_UPDATES` plus either `SHUTDOWN_RESTART` (0x44) or `SHUTDOWN_POWEROFF` (0x48). That first flag is what makes this "update and restart" instead of a plain restart. `SeShutdownPrivilege` is disabled by default on the process token, so it gets enabled first. **Wiring.** Both items use the existing `ExecuteCommandConfirmation` flow, so they respect the "confirm system commands" setting like the other commands here. They're registered on the System Commands page and the top-level search fallback, with stable ids (`...system.update_restart`, `...system.update_shutdown`). ## One question for reviewers `ShowDialogToConfirmCommand` defaults to `false`, so out of the box these run immediately when you press Enter, the same as the existing Shutdown and Restart commands. I kept them consistent rather than special-casing them, but I hit this myself while testing — I pressed Enter and my machine started updating and rebooting straight away, which was a bit of a surprise. Happy to force a confirmation for these two regardless of the setting if you'd prefer that. ## Validation Steps Performed 27/27 unit tests pass. The 5 new test methods cover the commands being present/absent in both states, query matching, stable ids, the 0x44 / 0x48 flag values, and that the real WUAPI call doesn't throw. I also tested it on a machine with a genuine pending update, confirmed via WUAPI `RebootRequired` and the Windows Update and CBS registry keys: 1. **Before** — the installed 0.11 build, same machine, same pending update: no update commands. 2. **After** — this build: both commands show up, in the same situation the Start menu offers them. 3. **Search** — typing `update` matches both, which is the discoverability gap the issue is about. 4. **Actually ran it** — pressing Enter on "Update and restart" installed the pending update (KB5121767) and restarted the machine. After it came back up, `RebootRequired` was false and the two commands were correctly gone from the list. ### Screenshots **1. Before** <img width="785" height="473" alt="Screenshot 2026-07-21 214038" src="https://github.com/user-attachments/assets/27b12a4c-f636-4815-b8e2-fc918282959b" /> **After** <img width="762" height="445" alt="Screenshot 2026-07-21 215452" src="https://github.com/user-attachments/assets/80e1936d-af67-48ab-91b4-59b94fb56827" /> <img width="762" height="149" alt="pr48849-search-update" src="https://github.com/user-attachments/assets/53b7f065-4b7c-4317-9e66-e621eed44e61" /> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7b3fb20d-6e9d-4fef-a5cd-f8921d28c220
PowerToys Source Code
Code organization
The PowerToys are split into DLLs for each PowerToy module (modules folder), and an executable (runner folder) that loads and manages those DLLs.
The settings window is a separate executable, contained in settings-ui folder. It utilizes a WebView to display an HTML-based settings window.
The common contains code for a static library with helper functions, used by both the runner and the PowerToys modules.