platform() is not able to detect windows 11

[sahsariga111]

BPO	45382
Nosy	@malemburg, @pfmoore, @tjguk, @ambv, @zware, @eryksun, @zooba, @miss-islington, @Evernow
PRs	bpo-45382: test.pythoninfo logs more Windows versions #30817 bpo-45382: test.pythoninfo: set wmic.exe encoding to OEM #30890 [3.10] bpo-45382: test.pythoninfo logs more Windows versions #30891 [3.9] [3.10] bpo-45382: test.pythoninfo logs more Windows versions (GH-30891) #30894
Files	demo.py import subprocess.py main.py main.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-10-05.19:43:57.181>
labels = ['library', '3.10']
title = 'platform() is not able to detect windows 11'
updated_at = <Date 2022-03-28.07:10:50.170>
user = 'https://bugs.python.org/sahsariga111'

bugs.python.org fields:

activity = <Date 2022-03-28.07:10:50.170>
actor = 'tim.golden'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-10-05.19:43:57.181>
creator = 'sahsariga111'
dependencies = []
files = ['50327', '50329', '50330', '50331']
hgrepos = []
issue_num = 45382
keywords = ['patch']
message_count = 38.0
messages = ['403260', '403261', '403262', '403263', '403264', '403265', '403267', '403271', '403272', '403357', '403358', '403379', '403386', '403452', '403459', '403471', '404451', '404591', '411331', '411336', '411474', '411498', '411659', '411661', '411663', '411671', '411694', '411696', '411704', '411711', '411712', '411714', '411762', '411763', '411764', '415333', '416142', '416146']
nosy_count = 10.0
nosy_names = ['lemburg', 'paul.moore', 'tim.golden', 'lukasz.langa', 'zach.ware', 'eryksun', 'steve.dower', 'miss-islington', 'sahsariga111', 'Evernow']
pr_nums = ['30817', '30890', '30891', '30894']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue45382'
versions = ['Python 3.10']

[sahsariga111]

I am updated to windows 11 . Now I am trying to write script that will detect is user use windows 11 or windows 10 .
I was using the simplest way as possible:
import platform
print(platform.platform())
The result I got is : Windows-10-10.0.22000-SP0
That is quite correct . The build version is correct ,but the windows version is still not .

[sahsariga111]

The
platform.win32_ver() returns same answer

[sahsariga111]

The bug comes from Microsoft terminal bug : If I type there : ver it will return Microsoft Windows [Version 10.0.22000.194] only one patch is if that will check the build .
so :
info = subprocess.check_output(cmd,
stdin=subprocess.DEVNULL,
stderr=subprocess.DEVNULL,
text=True,
shell=True)
if(int(info.strip(".")[2])==22000):
return "Windows [Version 11.0.22000.194]

[sahsariga111]

demo.py contains dirty hack that can be used as a fix for some time before microsoft will not fix it.

[malemburg]

win32_ver() should be using the internal Windows APIs to figure out the version. I do wonder why those don't return the same version as the "ver" command line tool.

Adding our Windows experts to the noisy list.

[zooba]

The version number for "Windows 11" still starts with 10.0. Just like how Windows 5.x and 6.x were around for a very long time each ;)

There are tables in platform module that map the specific version to the release name. These probably need to be updated to return "11" for versions 10.0.22000 and greater.

[malemburg]

On 05.10.2021 22:30, Steve Dower wrote:

The version number for "Windows 11" still starts with 10.0. Just like how Windows 5.x and 6.x were around for a very long time each ;)

There are tables in platform module that map the specific version to the release name. These probably need to be updated to return "11" for versions 10.0.22000 and greater.

Hmm, but the "ver" output seems to have more information than those
APIs.

Note: The tables for mapping to releases for Windows only take the
major.minor versions as key. Unfortunately, those did not change. It's
actually the build version which provides the indicator, it seems.

Any idea, whether a patch will fix this on Windows soonish ?

[eryksun]

The _WIN32_CLIENT_RELEASES table based on major.minor version number isn't helpful since Windows 10 and 11 have the same version number. win32_ver() needs a workaround to return release "11" if the build number is 22000 or greater. Is there any need/desire to also identify Server 2016, 2019, and 2022?

[zooba]

Hmm, but the "ver" output seems to have more information than those APIs.

It's always had build numbers, which the regular APIs do not, because the regular APIs are meant for detecting incompatibilities rather than reporting.

Since there are some incompatibilities, I hope they'll rev the minor version number, but I have no idea if that's planned yet. In theory I have early access to the release build already, but I haven't installed it on anything.

Eventually I think we're going to need some kind of WMI call in the platform module to get the right data for reporting. Until then, we're making best guesses from heuristics.

[sahsariga111]

systeminfo can be option

[malemburg]

It's probably time to extend the marketing version detection mechanism to use
the build number as reference instead of the major.minor system version numbers.

Here's a good reference for this:

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

MS resources:

https://docs.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version
https://docs.microsoft.com/en-us/windows/release-health/release-information