[Magnetarman]

Windows version recognition consolidation (25H2 / 26H1 / 26H2)

Description

Windows release labels (24H2, 25H2, 26H1, 26H2, …) were derived only from the OS build number through >=-thresholds, with the mapping duplicated across several places.

This caused two real defects:

• On Windows 11 26H2 (build 26300) WinToolkit reported 25H2, because 26300 >= 26200 matched the 25H2 threshold and the map had no 26300 -> 26H2 entry.
• On 25H2 the log header reported 24H2, because the header map lacked the 26200 -> 25H2 entry.

The build-number approach is also fundamentally fragile: 26H1 ships on build 28000 while 26H2 ships on 26300 (different platform branches, Bromine vs Germanium), so the build-number order no longer matches the release-order, and every new release requires a manual map patch.

Fix — single source of truth inside wintoolkit-modules

All version logic now lives in wintoolkit-modules/40-Module.System.ps1:

• Get-WindowsDisplayVersion — authoritative detection, evaluated in this order:
  1. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DisplayVersion (authoritative on Windows 11 21H2+ and automatically future-proof — a 27H1 release needs no code change).
  2. ReleaseId only on build < 22000 (Windows 10). The stale ReleaseId = 2009 shipped on every Windows 11 build is therefore ignored.
  3. A build→version fallback map kept only for upgrades-in-progress / stripped images, now with the corrected, ordered entries:
     28000 = 26H1; 26300 = 26H2; 26200 = 25H2; 26100 = 24H2; 22631 = 23H2; 22621 = 22H2; 22000 = 21H2; …
• Get-WindowsCompatibility — maps the build number to a logical tier (Windows11 / Windows10 / Windows81 / Unsupported) used for the support/compatibility indicator.

The Terminal (30-Module.Logging.ps1 Start-ToolkitLog, 80-Module.UserInteraction.ps1 WinOSCheck) and the GUI now only read and display the already-interpreted value:

• Start-ToolkitLog calls Get-WindowsDisplayVersion -Build $build (its local verMap was removed).
• WinOSCheck selects its message from $si.Compatibility instead of comparing build numbers.
• WinToolkit_GUI.ps1 Update-SystemInformationPanel renders the green / yellow / red LED and label from $si.Compatibility (it no longer evaluates build thresholds).

As a result, adding a future release label means updating one place (the registry first, the fallback map only if needed), and the GUI performs no version interpretation at all.

Bug fix for the reported mis-detection of 26H2 as 25H2, plus correct recognition of 25H2.

Fixes # (no linked issue)

---

Type of Change

• 🐛 Bug fix
• ✨ New feature
• ♻️ Refactoring (no functional change)
• 🧹 Cleanup / Maintenance
• 📖 Documentation

---

Files Modified

Source modules (single source of truth):

• wintoolkit-modules/40-Module.System.ps1 — added Get-WindowsDisplayVersion (registry-first, with corrected build fallback covering 26H1/26H2/25H2 and future-proof via the DisplayVersion registry value) and Get-WindowsCompatibility; Get-SystemInfo now returns DisplayVersion and a logical Compatibility field.
• wintoolkit-modules/30-Module.Logging.ps1 — Start-ToolkitLog uses Get-WindowsDisplayVersion (removed the duplicated verMap).
• wintoolkit-modules/80-Module.UserInteraction.ps1 — WinOSCheck selects its compatibility message from $si.Compatibility instead of build thresholds.

Presentation layer (display only):

• WinToolkit_GUI.ps1 — Update-SystemInformationPanel renders the compatibility tier from $si.Compatibility (green/yellow/red LED + text); no build-number interpretation remains.

Generated artifact (rebuilt, not hand-edited — per repo policy):

• WinToolkit.ps1 — regenerated by compiler.ps1 (commit ✅ Build WinToolkit) so the compiled core reflects the module changes. Not edited manually.

Feature-gating minimum-build checks that are not version labeling were intentionally left as-is, since they correctly pass on 26H2/25H2:

• wintoolkit-modules/40-Module.Winget.ps1 Test-WingetCompatibility (>= 17763)
• start-modules/50-Module.Installers.ps1 Test-WindowsTerminalDefaultSupported
• tools/Uninstall-Office.ps1 Get-WindowsVersion (coarse Windows11_23H2_Plus bucket; already covers 25H2/26H2).

---

Tests & Verification

• Verified locally via the relevant build/test command
• Regenerated the artifact with compiler.ps1 and confirmed parse + behavior
• Execution logs attached (snippet or screenshot)

Environment: Windows 11 Pro 26H2 (build 26300.9457), PowerShell 7.6.6.

=== Parse check (all modified files) ===
OK   WinToolkit.ps1
OK   wintoolkit-modules/30-Module.Logging.ps1
OK   wintoolkit-modules/40-Module.System.ps1
OK   wintoolkit-modules/80-Module.UserInteraction.ps1
OK   WinToolkit_GUI.ps1

=== Functional (machine is 26H2, build 26300, DisplayVersion=26H2, ReleaseId=2009) ===
Get-WindowsDisplayVersion -> 26H2
Get-SystemInfo.DisplayVersion -> 26H2 (build 26300)
Get-SystemInfo.Compatibility  -> Windows11

=== Build-number fallback map (registry shadowed) ===
build 28000 -> 26H1
build 26300 -> 26H2
build 26200 -> 25H2
build 26100 -> 24H2
build 22631 -> 23H2
build 22000 -> 21H2
build 19045 -> 22H2
build 10586 -> 1511
build 10240 -> 1507
build 9600  -> N/A

=== ReleaseId guard (stale 2009 on Win11 must be ignored) ===
build 22621 + ReleaseId '21H2' (Win11, stale) -> 22H2   (falls to map, not ReleaseId)
build 19044 + ReleaseId '21H2' (Win10)        -> 21H2   (ReleaseId used)

=== Log header produced by Start-ToolkitLog ===
OS                      : Microsoft Windows 11 Pro
    Version                 : Version 26H2 (OS build 26300)

=== PSScriptAnalyzer (CI settings, Error/Warning) ===
OK  wintoolkit-modules/30-Module.Logging.ps1
OK  wintoolkit-modules/40-Module.System.ps1
OK  wintoolkit-modules/80-Module.UserInteraction.ps1

=== Pester (CI smoke suite) ===
Tests Passed: 5, Failed: 0

---

Checklist

Missing a checkbox or violating a rule will result in automatic PR rejection.

• PR targets Dev (commits are on the Dev branch)
• Atomic change: one issue/feature per PR
• WinToolkit.ps1 not modified manually (handled by CI automation — rebuilt with compiler.ps1)
• Generated artifacts (WinToolkit.ps1, start-core.ps1) are not edited manually
• No changes to .github/, start.ps1 or start-modules/ (so no extra maintainer review required there)
• Existing code style respected, no debug code left behind
• Parse-clean and PSScriptAnalyzer-clean (CI settings), Pester CI-Smoke passes

[github-actions]

👀 Heads Up — Manual Review Required

Hi @Magnetarman,
thanks for your contribution! This PR was accepted and can proceed normally through the review flow.

However, the automated check detected that one or more sensitive WinToolkit files were modified, which affect the user interface, the main template or the project's static resources:

Sensitive files modified

• WinToolkit_GUI.ps1
• wintoolkit-modules/30-Module.Logging.ps1
• wintoolkit-modules/40-Module.System.ps1
• wintoolkit-modules/80-Module.UserInteraction.ps1
• .github/ISSUE_TEMPLATE/bug_report.yml

Why this notice?

These files are not blocked for contributors, but they require additional verification by the maintainer before merging, because unexpected changes could:

• Alter the interface behaviour (WinToolkit_GUI.ps1, start.ps1)
• Impact compilation or the framework core functions (wintoolkit-modules/)
• Introduce unverified resources into the distribution (assets/)

Next steps

No action is required from you. The maintainer will review the changes with extra care before merging.

---

Automated notification from the WinToolkit CI/CD system — PR #196.