Skip to content

platform() is not able to detect windows 11 #89545

Closed
Closed
platform() is not able to detect windows 11#89545
Assignees
zooba
Labels
3.10 (EOL)end of life3.11only security fixes3.12only security fixesOS-windowsstdlibStandard Library Python modules in the Lib/ directory

Description

@sahsariga111
sahsariga111
mannequin
opened on Oct 5, 2021
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']

    Activity

    1. sahsariga111 commented on Oct 5, 2021

      @sahsariga111
      sahsariga111mannequin
      on Oct 5, 2021
      MannequinAuthor

      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 .

    2. sahsariga111
      added
      3.10 (EOL)end of life
      stdlibStandard Library Python modules in the Lib/ directory
      on Oct 5, 2021

    3. sahsariga111 commented on Oct 5, 2021

      @sahsariga111
      sahsariga111mannequin
      on Oct 5, 2021
      MannequinAuthor

      The
      platform.win32_ver() returns same answer

    4. sahsariga111 commented on Oct 5, 2021

      @sahsariga111
      sahsariga111mannequin
      on Oct 5, 2021
      MannequinAuthor

      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]

    5. sahsariga111 commented on Oct 5, 2021

      @sahsariga111
      sahsariga111mannequin
      on Oct 5, 2021
      MannequinAuthor

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

    6. malemburg commented on Oct 5, 2021

      @malemburg
      malemburg
      on Oct 5, 2021
      Member

      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.

    7. zooba commented on Oct 5, 2021

      @zooba
      zooba
      on Oct 5, 2021
      Member

      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.

    8. malemburg commented on Oct 5, 2021

      @malemburg
      malemburg
      on Oct 5, 2021
      Member

      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 ?

    9. eryksun commented on Oct 5, 2021

      @eryksun
      eryksun
      on Oct 5, 2021
      Contributor

      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?

    10. zooba commented on Oct 5, 2021

      @zooba
      zooba
      on Oct 5, 2021
      Member

      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.

    11. sahsariga111 commented on Oct 7, 2021

      @sahsariga111
      sahsariga111mannequin
      on Oct 7, 2021
      MannequinAuthor

      systeminfo can be option

    12. malemburg commented on Oct 7, 2021

      @malemburg
      malemburg
      on Oct 7, 2021
      Member

      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

    13. 42 remaining items

    14. zooba
      added
      OS-windows
      on Aug 31, 2022
    15. zooba
      added 3 commits that reference this issue on Sep 2, 2022

      Merge remote-tracking branch 'cpython/main' into pythongh-89545

      98e3080

      Merge branch 'main' into pythongh-89545

      653f152

      gh-89545: Updates platform module to use new internal _wmi module on …

      de33df2

    16. zooba commented on Sep 7, 2022

      @zooba
      zooba
      on Sep 7, 2022
      Member

      The fix for this (not including getwindowsversion()) has been merged for 3.12, but should probably be considered for 3.11 and 3.10 as well.

      I don't think it's important enough to hold up 3.11.0, so we'd be looking at 3.11.1. And we just missed 3.10.7, so no rush for 3.10.8. But I'll leave this open until the backports are done.

    17. zooba
      self-assigned this
      on Sep 7, 2022

    18. vstinner commented on Sep 7, 2022

      @vstinner
      vstinner
      on Sep 7, 2022
      Member

      Because of the side effects of the calling the _wmi module, I would prefer to only target Python 3.12. I would prefer to get more feedback to see if everything goes well. It's too late to add new feateures to Python 3.11.

      The workaround on older Python versions is to run the ver command, as done by test.pythoninfo: see collect_windows().

    19. zooba commented on Sep 7, 2022

      @zooba
      zooba
      on Sep 7, 2022
      Member

      Fair enough, consider this closed.

    20. zooba
      closed this as completedon Sep 7, 2022

    21. vstinner commented on Sep 8, 2022

      @vstinner
      vstinner
      on Sep 8, 2022
      Member

      Thanks for fixing this issue, it's good to have an easy way to retrieve the real Windows version ;-)

      Maybe _wmi can be used for other purposed later. Maybe we can expose it somehow later.

    22. v-python commented on Feb 11, 2023

      @v-python
      v-python
      on Feb 11, 2023

      Why shell out or use _wmi rather than the registry HKLM\software\Microsoft\windows nt\CurrentVersion ProductName

    23. zooba commented on Feb 13, 2023

      @zooba
      zooba
      on Feb 13, 2023
      Member

      Because the registry key is unsupported and primarily for compatibility reasons.

      Also, for example, the value of ProductName on my Windows 11 machine is "Windows 10 Enterprise", which is exactly the bug we were trying to fix here.

      The platform module is intended to get true information, not compatibility shims.

    24. charliermarsh
      added a commit that references this issue on Oct 28, 2024

      Regenerate known_stdlibs.rs with stdlibs 2024.10.25 (#13963)

      c593ccb
    25. abdnh
      added a commit that references this issue on Apr 1, 2026

      Support WindowsRTTTSFilePlayer on Windows 11 (#4512)

      4d199d9
    26. KotlinIsland
      added a commit that references this issue on May 1, 2026

      Regenerate known_stdlibs.rs with stdlibs 2024.10.25 (#13963)

      31e82aa
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    3.10 (EOL)end of life3.11only security fixes3.12only security fixesOS-windowsstdlibStandard Library Python modules in the Lib/ directory

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions