classification
Title: platform() is not able to detect windows 11
Type: Stage:
Components: Library (Lib) Versions: Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eryksun, lemburg, paul.moore, sahsariga111, steve.dower, tim.golden, vstinner, zach.ware
Priority: normal Keywords:

Created on 2021-10-05 19:43 by sahsariga111, last changed 2021-10-21 12:14 by sahsariga111.

Files
File name Uploaded Description Edit
demo.py sahsariga111, 2021-10-05 19:58
import subprocess.py sahsariga111, 2021-10-07 07:49
main.py sahsariga111, 2021-10-07 10:20
main.py sahsariga111, 2021-10-07 11:05
Messages (18)
msg403260 - (view) Author: Alex Zaslavskis (sahsariga111) Date: 2021-10-05 19:43
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 .
msg403261 - (view) Author: Alex Zaslavskis (sahsariga111) Date: 2021-10-05 19:46
The 
platform.win32_ver() returns same answer
msg403262 - (view) Author: Alex Zaslavskis (sahsariga111) Date: 2021-10-05 19:52
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]
msg403263 - (view) Author: Alex Zaslavskis (sahsariga111) Date: 2021-10-05 19:58
demo.py contains dirty hack that can be used as a fix for some time before microsoft will not fix it.
msg403264 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2021-10-05 20:17
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.
msg403265 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-10-05 20:30
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.
msg403267 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2021-10-05 20:35
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 ?
msg403271 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-10-05 21:31
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?
msg403272 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-10-05 21:41
> 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.
msg403357 - (view) Author: Alex Zaslavskis (sahsariga111) Date: 2021-10-07 07:49
systeminfo can be option
msg403358 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2021-10-07 07:58
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
msg403379 - (view) Author: Alex Zaslavskis (sahsariga111) Date: 2021-10-07 10:20
That nice idea . So the dist can contain the minimal build required to say that is for example windows 11 . The simplest solution that came in mind is . Is far from perfect but it works.
msg403386 - (view) Author: Alex Zaslavskis (sahsariga111) Date: 2021-10-07 11:05
Beter solution . Using match in python 3.10
msg403452 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-10-08 00:15
> use the build number as reference instead of the major.minor

It could check the (major, minor, build) tuple, which allows reporting 10.1+ as "post11" and minimizes hard coding of build numbers. For example, given win32_ver() iterates by (major, minor, build) thresholds:

    _WIN32_CLIENT_RELEASES = [
        ((10, 1, 0), "post11"),
        ((10, 0, 22000), "11"),
        ((6, 4, 0), "10"),
        ((6, 3, 0), "8.1"),
        ((6, 2, 0), "8"),
        ((6, 1, 0), "7"),
        ((6, 0, 0), "Vista"),
        ((5, 2, 3790), "XP64"),
        ((5, 2, 0), "XPMedia"),
        ((5, 1, 0), "XP"),
        ((5, 0, 0), "2000"),
    ]

    _WIN32_SERVER_RELEASES = [
        ((10, 1, 0), "post2022Server"),
        ((10, 0, 20348), "2022Server"),
        ((10, 0, 17763), "2019Server"),
        ((6, 4, 0), "2016Server"),
        ((6, 3, 0), "2012ServerR2"),
        ((6, 2, 0), "2012Server"),
        ((6, 1, 0), "2008ServerR2"),
        ((6, 0, 0), "2008Server"),
        ((5, 2, 0), "2003Server"),
        ((5, 0, 0), "2000Server"),
    ]

In win32_ver():

    if major >= 5: # NT systems
        if getattr(winver, 'product_type', None) == 3: # VER_NT_SERVER
            release_list = _WIN32_SERVER_RELEASES
        else:
            release_list = _WIN32_CLIENT_RELEASES
        ver = major, minor, build
        for release_ver, release_name in release_list:
            if ver >= release_ver:
                release = release_name
                break
msg403459 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2021-10-08 07:18
On 08.10.2021 02:15, Eryk Sun wrote:
> 
>> use the build number as reference instead of the major.minor
> 
> It could check the (major, minor, build) tuple, which allows reporting 10.1+ as "post11" and minimizes hard coding of build numbers. For example, given win32_ver() iterates by (major, minor, build) thresholds:

Great idea.

Could you prepare a PR for this ?
msg403471 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-10-08 12:10
macOS has a similar issue in the platform module. Previously, platform gave the darwin kernel version, whereas most users only know macOS versions. See bpo-35344.

Even if Microsoft decided to internally stay at 10.x, IMO users really expect "Windows 11" when requesting the Windows version, especially in platform.platform().
msg404451 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-10-20 13:45
All that said, if we're going to shell out to "ver", we may as well try "wmic os get Caption,Version /value" first and parse its output. For me, it looks like the below (with a number of blank lines around it):

Caption=Microsoft Windows 10 Enterprise
Version=10.0.19043

I would assume the output is in MBCS, and there doesn't appear to be an option to change that - the "/locale" option appears to influence translations, rather than encoding.

We'd still want the "ver" fallback I think. The wmic command is deprecated in favour of PowerShell commands, which means we would have to implement native calls to get equivalent functionality. But I expect neither cmd.exe nor wmic.exe will actually disappear for a long time.
msg404591 - (view) Author: Alex Zaslavskis (sahsariga111) Date: 2021-10-21 12:14
On my Win11 it returns me :

C:\Users\Win10Home>wmic os get Caption,Version /value


Caption=Microsoft Windows 11 Home Single Language
Version=10.0.22000
History
Date User Action Args
2021-10-21 12:14:35sahsariga111setmessages: + msg404591
2021-10-20 13:45:41steve.dowersetmessages: + msg404451
2021-10-08 12:10:40vstinnersetnosy: + vstinner
messages: + msg403471
2021-10-08 07:18:56lemburgsetmessages: + msg403459
2021-10-08 00:15:13eryksunsetmessages: + msg403452
2021-10-07 11:05:47sahsariga111setfiles: + main.py

messages: + msg403386
2021-10-07 10:20:02sahsariga111setfiles: + main.py

messages: + msg403379
2021-10-07 07:58:49lemburgsetmessages: + msg403358
2021-10-07 07:49:14sahsariga111setfiles: + import subprocess.py

messages: + msg403357
2021-10-05 21:43:48zach.waresetnosy: + eryksun
2021-10-05 21:41:33steve.dowersetnosy: - eryksun
messages: + msg403272
2021-10-05 21:31:26eryksunsetnosy: + eryksun
messages: + msg403271
2021-10-05 20:35:06lemburgsetmessages: + msg403267
2021-10-05 20:30:35steve.dowersetmessages: + msg403265
2021-10-05 20:17:15lemburgsetnosy: + lemburg, paul.moore, tim.golden, zach.ware, steve.dower
messages: + msg403264
2021-10-05 19:58:45sahsariga111setfiles: + demo.py

messages: + msg403263
2021-10-05 19:52:28sahsariga111setmessages: + msg403262
2021-10-05 19:46:01sahsariga111setmessages: + msg403261
2021-10-05 19:43:57sahsariga111create