Mailing List Archive

Change by Shreyan Avigyan <shreyan.avigyan@gmail.com>:


----------
nosy: +shreyanavigyan

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

When we're talking about version are we talking about the kernel32.dll version or the Windows version? If we're talking about Windows version then why not use the return value of sys.getwindowsversion() itself? How is that function getting the Windows version? Moreover shouldn't the documentation provide the information that sys.getwindowsversion().platform_version returns the kernel32.dll version?

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Eryk Sun <eryksun@gmail.com> added the comment:

> shouldn't the documentation provide the information that
> sys.getwindowsversion().platform_version returns the
> kernel32.dll version?

platform_version is documented as an "accurate major version, minor version and build number of the current operating system, rather than the version that is being emulated for the process". That's it's currently using the file version of "kernel32.dll" is an implementation detail, one that needs to be changed to something more reliable.

Keep in mind that the Python DLL can be embedded in any application, which may not be manifested to get the true OS version via GetVersionExW(). For example, when running in Windows 10, the default with no manifest reports Windows 8 (NT 6.2):

>>> sys.getwindowsversion()
sys.getwindowsversion(major=6, minor=2, build=9200, platform=2, service_pack='')

Here it is with a manifest that supports Windows 8.1 (NT 6.3):

>>> sys.getwindowsversion()
sys.getwindowsversion(major=6, minor=3, build=9600, platform=2, service_pack='')

This is the OS version that's relevant to the application, but for logging and other diagnostics, platform_version is provided to get the real version, at least if all goes according to plan.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

@eryksun described "Apparently the developers do not want to guarantee that the version information on any particular system DLL can be used to get the system version. Apparently they also do not want to officially sanction using the "CurrentMajorVersionNumber", "CurrentMinorVersionNumber", and "CurrentBuildNumber" values in the registry."

If that's the case why not get the version from CurrentBuild registry key present in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion. This key at least goes back to Windows 7 and this is the key that's currently being used by winver command. And I don't think anyone at all uses windows version older than Windows 7. And chances are that the key maybe present even before Windows 7. At least the CurrentBuild is accurate.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

I researched a little more and found that before Vista the winver command used the CurrentBuildNumber key instead of CurrentBuild key. In fact before Vista CurrentBuild was marked as obsolete by Microsoft. But that changed in Vista, when Microsoft started using CurrentBuild key instead of the CurrentBuildNumber key. Though still today CurrentBuildNumber key actually gives the exact version (for backward compatibilities maybe?). Therefore why not use CurrentBuildNumber? At least CurrentBuildNumber gives the right info. The only problem is that we have to only use that key to determine the windows version (Eg - Windows 10, 8.1, 8, 7, Vista, etc.) and to do that we have to use a very long switch or if-else statement.

https://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions#Windows_NT has the whole list with the column "RTM build" as the CurrentBuildNumber value.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Eryk Sun <eryksun@gmail.com> added the comment:

The "CurrentBuild" and "CurrentVersion" values go back to the first release of Windows NT 3.1 in 1993 (build 511, which was quickly replaced by build 528). In NT 3.1 (build 528), the "CurrentBuild" value was "1.528.1 () (July 1993)". In NT 3.5, this awkward string was replaced by the "CurrentBuildNumber" value, and up to NT 5.2 the old "CurrentBuild" value was set to the string "1.511.1 () (Obsolete data - do not use)". It was brought back as the build number starting with Windows Vista (NT 6.0). However, in Windows 10 the related "CurrentVersion" value is now obsolete and frozen at "6.3". The true value is now split into "CurrentMajorVersionNumber" and "CurrentMinorVersionNumber".

These registry values aren't a reliable source source of truth. The reliable values are the kernel global variables NtMajorVersion, NtMinorVersion, and NtBuildNumber, which are compiled into the kernel image. They get copied into the process environment block (PEB) of each process as OSMajorVersion, OSMinorVersion, and OSBuildNumber. If the application manifest supports the current OS version, then GetVersion() and GetVersionExW() will simply return these values from the PEB. That's why it was suggested to spawn an instance of the system CMD shell and parse the output of its VER command.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

But kernel32.dll (since it's of a different version) isn't accurate at all right? To find the accurate result we have to use the CurrentBuildNumber registry key. I think this key will not be removed so easily by Microsoft. This key have been in existence from NT 3.5 till today. I think it's the safest and reliable way to get the version number other than WMI query. I know the key can be removed in the future but if it that happens what about reimplementing the kernel32.dll then. We need a way to get the accurate version right?

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Eryk Sun <eryksun@gmail.com> added the comment:

> But kernel32.dll (since it's of a different version) isn't
> accurate at all right?

To clarify, CMD's VER command calls GetVersion(). It has nothing to do with the file version of any system DLL. Because CMD is a system component, the GetVersion() call returns the true OS version number and build number, directly from its PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber values. When the PEB for a process is created, these values are copied from the kernel's NtMajorVersion, NtMinorVersion, and NtBuildNumber values.

While the latter may be and most likely are the same as the "CurrentMajorVersionNumber", "CurrentMinorVersionNumber", and "CurrentBuildNumber" values in the registry, the kernel values are not based on the registry. They're compiled into the kernel image when it's built. At boot, the configuration manager sets the registry values to the current values, so that's all fine -- unless someone with admin or system access changes the values (but if a hacker has admin or system access; they own the OS, so such a prank would be the least of one's problems).

My concern, if you read my previous comments, is that an engineer at Microsoft rejected someone's attempt to recommend using "CurrentBuildNumber" as a replacement for the old advice to use the file version of "kernel32.dll". That's enough to make me worry about what's planned for a future release. So I'd rather just parse the output from CMD.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

But isn't calling CMD's VER command risky? A process can overwrite its PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber. If the cmd has been set to compatibility mode somehow then the same problem will occur since it will then overwrite its PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber. Using a DLL or registry key bypasses this risk.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Eryk Sun <eryksun@gmail.com> added the comment:

> But isn't calling CMD's VER command risky? A process can overwrite its
> PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber.

As long as VER is executed without quotes, the shell will not search for an external command. CMD is not going to intentionally overwrite the OS version and build number in the PEB, so that would be due to some kind of weird, unlikely bug. (CMD's code base is stable. It hasn't seen a new feature since MKLINK was added 15 years ago.) If malware messes with this, for some strange reason, it's not Python's problem. For example, I'll attach a debugger and do just that:

0:000> ?? @$peb->OSMajorVersion = 11
unsigned long 0xb
0:000> ?? @$peb->OSMinorVersion = 0
unsigned long 0
0:000> ?? @$peb->OSBuildNumber = 0x8000
unsigned short 0x8000

C:\>ver
Microsoft Windows [Version 11.0.32768.0]

Hi from the future. :)

> If the cmd has been set to compatibility mode

"%SystemRoot%\System32\cmd.exe" is exempt from compatibility mode (e.g. the "__COMPAT_LAYER" environment variable).

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

Ok. So are you planning to implement this fix?

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Steve Dower <steve.dower@python.org> added the comment:

Python is a volunteer built project, so someone will need to volunteer
to write the fix. Until there is a volunteer, there is no plan. (One of
the core devs might volunteer, but there's no guarantee of that.)

If we're going to launch cmd.exe, I'd prefer to only do that in the
platform module and not the sys function. Nothing in sys should start a
subprocess (if we can at all avoid it).

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Eryk Sun <eryksun@gmail.com> added the comment:

> If we're going to launch cmd.exe, I'd prefer to only do that in the
> platform module and not the sys function. Nothing in sys should
> start a subprocess (if we can at all avoid it).

In that case, would you want to deprecate sys.getwindowsversion().platform_version?

platform._syscmd_ver() is already implemented to parse the output of CMD's VER command. The result has to be post-processed because the regex isn't as exact as it could be. It supports versions back to Windows 2000, which returned "Microsoft Windows 2000 [Version maj.min.build]". Starting with Windows Vista up to early versions of Windows 10, the format is "Microsoft Windows [Version maj.min.build]". In more recent versions of Windows 10, it includes the update build revision number -- "Microsoft Windows [Version maj.min.build.ubr]".

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Steve Dower <steve.dower@python.org> added the comment:

> In that case, would you want to deprecate sys.getwindowsversion().platform_version?

Yeah, but I'm not so concerned about raising a warning on use. Just in
the docs will be fine. We should also add a mention that it is
extracting the value from efficient but unstable system locations that
may change in future releases. (That is not my suggested wording btw,
just the gist of what we should mention.)

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

I would like to help to write the fix for this issue.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

For Windows 10.0.17134 (1803) or above why don't we use the format "maj.min.build.ubr" in platform._norm_version (the function that post-processes the version string and then returns the version string in the format "maj.min.build")?

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

I have a patch for this issue. Should I attach it or should I directly open a PR?

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Steve Dower <steve.dower@python.org> added the comment:

Opening a PR against the master branch would be ideal. (Make sure you
forked from that branch too, or you may see lots of irrelevant changes,
which will make it impossible to review.)

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Change by Shreyan Avigyan <shreyan.avigyan@gmail.com>:


----------
keywords: +patch
pull_requests: +24220
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25500

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Shreyan Avigyan <shreyan.avigyan@gmail.com> added the comment:

PR opened against master branch.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Steve Dower <steve.dower@python.org> added the comment:


New changeset 2a3f4899c63806439e5bcea0c30f7e6a6295a763 by Shreyan Avigyan in branch 'master':
bpo-43284: Update platform.win32_ver to use _syscmd_ver instead of sys.getwindowsversion() (GH-25500)
https://github.com/python/cpython/commit/2a3f4899c63806439e5bcea0c30f7e6a6295a763


----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Change by miss-islington <mariatta.wijaya+miss-islington@gmail.com>:


----------
nosy: +miss-islington
nosy_count: 9.0 -> 10.0
pull_requests: +24243
pull_request: https://github.com/python/cpython/pull/25523

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Change by miss-islington <mariatta.wijaya+miss-islington@gmail.com>:


----------
pull_requests: +24244
pull_request: https://github.com/python/cpython/pull/25524

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Steve Dower <steve.dower@python.org> added the comment:

Thanks for doing the patch!

----------
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue43284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com