feat(ui-windows-winui): render-backend dispatch seam + startup probe (#4680 step 3)#4897
Open
proggeramlug wants to merge 3 commits into
Open
feat(ui-windows-winui): render-backend dispatch seam + startup probe (#4680 step 3)#4897proggeramlug wants to merge 3 commits into
proggeramlug wants to merge 3 commits into
Conversation
added 3 commits
June 10, 2026 12:16
…4680 step 3) Builds on the merged step-2 bootstrap probe (#4896). Add winui::backend, the single decision point the per-widget WinUI 3 mapping reads: active() returns RenderBackend::Fluent when the bootstrap probe is Ready, else RenderBackend::Win32. Register a CRT static initializer (.CRT$XCU, anchored with #[used]) that runs the probe at process start for any binary linking this staticlib - i.e. exactly the --target windows-winui builds, never the default --target windows builds (which don't link the crate) - so the first widget construction reads an already-resolved backend. PERRY_WINUI_DIAG prints the chosen backend at launch. The initializer never panics (runs before main). Verified on a Windows host without the SDK: the initializer fires in a linked binary ([perry-winui] render backend: win32 observed via PERRY_WINUI_DIAG), the .CRT$XCU section is present in the WHOLEARCHIVE'd perry_ui_windows_winui.lib, and active() mirrors the bootstrap verdict and is stable. Real Microsoft.UI.Xaml controls still need the WinAppSDK winmd projections + runtime and are the next step; today the seam always resolves to Win32. Default --target windows unaffected.
…#4680) The backend probe could say Ready/Missing but not *why* it was missing. Capture the bootstrap outcome detail (sentinels for DLL-missing / no-entry-point / success, otherwise the raw MddBootstrapInitialize HRESULT) and print it under PERRY_WINUI_DIAG: e.g. "render backend: fluent (bootstrap detail: ready)" or "win32 (bootstrap detail: MddBootstrapInitialize failed, HRESULT 0x80670016)". This made the step-2 success path verifiable against the real runtime: with the Windows App SDK 1.6 dev NuGet restored (bootstrap DLL next to the exe) and the DDLM/Main/Singleton runtime packages registered, initialize() flips from RuntimeMissing to Ready/fluent - so both arms of the merged MddBootstrapInitialize2 FFI (#4896) are now exercised. The 0x80670016 case was exactly a registered framework package with no DDLM, which the new diagnostic pinpoints. Adds a unit test for the detail formatter (pure function, environment-agnostic).
This was referenced Jun 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Implements the step-3 dispatch seam for #4680 (opt-in WinUI 3 / Fluent Windows target), building directly on the step-2 bootstrap probe merged in #4896.
Adds
winui::backend— the single decision point the per-widget WinUI 3 mapping reads — plus a process-startup probe so--target windows-winuibinaries resolve their render backend at launch.How
winui::backend::active() -> RenderBackend— returnsRenderBackend::Fluentwhen the Windows App SDK bootstrap probe (bootstrap::initialize()) isReady, elseRenderBackend::Win32. Cheap and stable (memoized by the bootstrap cache). Each XAML widget lands behind this check: build aMicrosoft.UI.Xamlcontrol onFluent, else delegate to the existing Win32 constructor..CRT$XCU, anchored with#[used]) registered in the crate runs the probe at process start for any binary that links this staticlib — i.e. exactly the--target windows-winuibuilds, and never the default--target windowsbuilds (which don't link the crate). So the first widget construction reads an already-resolved backend rather than probing lazily. It never panics (runs beforemain).PERRY_WINUI_DIAGprints the chosen backend at launch:[perry-winui] render backend: win32|fluent.Testing
cargo test -p perry-ui-windows-winui→ green (active_backend_matches_bootstrap_verdict,initialize_is_total_and_idempotent).active()mirrors the bootstrap verdict and is stable; off Windows it is alwaysWin32.PERRY_WINUI_DIAG=1emitted[perry-winui] render backend: win32..CRT$XCUsection (8 bytes — one initializer pointer) is present in the WHOLEARCHIVE'dperry_ui_windows_winui.lib(llvm-objdump --headers).Scope / not in this PR
Real
Microsoft.UI.Xamlcontrols need the WinAppSDK winmd projections + runtime (the stockwindowscrate at 0.58 ships only UWPWindows.UI.Xaml, not WinUI 3'sMicrosoft.UI.Xaml), so they're the next step. Today the seam always resolves toWin32. Win32 (--target windows) remains the default and is untouched.