It’s interesting and perhaps a bit puzzling. For “compatibility reasons” — some having to do with browsing the Web — Windows 11 has long reported itself as a kind of Windows 10. Indeed, one must examine Build numbers, mostly, to figure out which version of Windows is really driving the bus. To see this enduring Windows 10 hangover try this string in PowerShell:

[System.Environment]::OSVersion.Version

You can, of course, get the real skinny by running winver.exe, or a more nuanced Get-ItemProperty command in PowerShell:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Select-Object DisplayVersion, EditionID, CurrentBuild

You can see the results of these two commands in this blog post’s lead-in graphic. It still shows my production Windows 11 PC (Build 26200) with a Major version number of “10,” while the Get-ItemProperly output shows the “real deal” on this machine.

Will Enduring Windows 10 Hangover Get Fixed?

Now that Windows 10 is past its End of Service date, will MS fix this strange reporting practice? Probably not. There are reasons upon reasons why this reporting quirk is likely to remain unaltered.

The whole compatibility thing is HUGE: lots of driver models, apps and applications, and enterprise tools assume that Windows 10 is the end-all and be-all for modern Windows versions. Indeed, it’s much, much more than a browser user-agent assumption. According to Copilot, “enterprise environments rely on registry keys such as ProductName and ReleaseId for automation,” so “those keys are often left untouched in Insider Builds to avoid disrupting telemetry and deployment pipelines.”

Hence the following, also from PowerShell using this command sequence:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Notice that my Production Win11 system reports in this command as Windows 10 Pro, version 2009, with correct build number.

At least, I now know why this apparent misreporting occurs, and understand that it’s for good cause. Here in Windows-World there are plenty of apparent mysteries whose simple explanations lie in the many twists and turns in Windows history. This is one of those, I reckon.

There’s been a lot of coverage in the Windows trade press around Windows 10’s tenth birthday. It made its debut on July 29, 2015. As I’m pondering Windows 10 turns 10 — and its upcoming EOS on October 14 — I asked myself “How does a 10-year lifespan compare to other Windows versions?” Obligingly enough, Copilot provided me with a text-based histogram that lays things out as far back as Windows 1.x versions. It serves as the lead-in graphic for this post.

Pondering Window 10 Turns 10: Lifespans Compared

Here’s what I see when I look at that chart:

• Only two versions have had longer runs than Windows 10 — namely, Windows XP (13 years) and Windows 7 (11 years). Both are arguably the Windows champs as far as versions go, and I used the heck out of them during their heydays.
• I’d have to say that a life span of under 7 years pretty clearly separates winning Windows avatars from losing ones. That group includes Windows 1.x, 2.x, 95, ME, Vista, 8 and 8.1. Of those, Windows 95 is the only one I remember fondly, but I moved to 98 long before it got close to EOL.
• Over this set, the distribution is pretty scattered and broad. The min is 2 years, the max is 13 years, the mean is 7.25 years, and the median is 6 years. Given my preceding observation about lifespans under 7 years, does that mean Windows is rather less than more successful? Interesting question, but I don’t think the answer is “Yes.” Arguably, Windows 7 persisted because neither 8 nor 8.1 could really pick up and run with the ball.

It’s interesting to step back and look at how many versions have come and gone and how each one has had its own lifecycle. My gut feel is that Windows 10 deserves to be in the same cohort as XP and 7. I’d argue further that Windows 11 could be in the same company — but of course it’s too early to say just yet. After all, it’s only just a bit over 4 years old.

I learned some new Windows-speak this morning, I think. First, I read stories at WindowsLatest and Thurrott.com that mention “inbox” and “in-box” apps respectively. Then, I read the MS Tech Community post that inspired their interesting assertions. Seems that Thurrott’s use of “in-box” is probably the most appropriate nomenclature. What’s under discussion is the update status of MS Store apps as a new install of Windows runs for the first time. Indeed, a new 24H2 install includes up-to-date Store apps, for ISOs and installers (e.g. the Windows 11 Installation Assistant)  dated June, 2025, or later.

Why 24H2 Install Includes Up-to-date Store Apps Matters

In earlier Windows 11 installs, one of the first post-OOBE tasks the OS undertakes is a full-scale update of built-in Store apps. This occurs via the Store’s update facility. WindowsLatest observes this means that up to 36 apps are covered. In turn, that saves time and bandwidth. Under this new regime, apps included in the OS image get newer versions. Here’s what the afore-linked blog post says:

…newer versions of the inbox Microsoft Store apps [come] preinstalled instead of the release-to-manufacturing (RTM) version. This includes updated ISO images, virtual hard disks (VHDs), and Azure Marketplace images.

Basically, this means that MS now provides images with more up-to-date versions of Store apps. My take is that the actual update count depends on when download images got built.  MS replaces them on at least a quarterly schedule. Thus, this means fewer Store updates than in earlier Windows versions (23H2 and lower).

Good news, of a singular and restricted sort, here in Windows-World. I’ll raise a small cheer, and a word of thanks, to the Windows team in response.YAY!