3

I want a program to determine which OS and its version is running on the computer. I was really confused when platform.release() returned '8' since my computer was originally running on windows 8 but I updated on windows 10 several months ago.

My guess would be that it is more of a windows issue than a python problem. Is there a way o fix this? Or should I use a different module than platform?

I am using python 3.4.3. The whole version name platform.platform() returns is 'Windows-8-6.2.9200' but I can't tell whether it is the very first version on the computer or the last one before the Update.

r0w
  • 155
  • 1
  • 13
  • 3.4.4 python returns "10" on my windows 10 box, and "Windows-10-10.0.14393" (release()) – Jean-François Fabre Aug 19 '17 at 19:59
  • um can you please explain why my answer is wrong? does sys.platform not work? – Victor Li Aug 19 '17 at 20:01
  • @ Jean-François Fabre: which version of the platform.py file do you have? – r0w Aug 19 '17 at 20:07
  • it's 1.0.7 for python 3.4.4 – Jean-François Fabre Aug 19 '17 at 20:09
  • I have 1.0.7 too. I'm not sure but starting with line 589 there are some if statements and the last one determines 8. there is nothing with 10. – r0w Aug 19 '17 at 20:12
  • can you try `platform._get_real_winver(10,10,10)` and post the results? also try `platform.uname()` and post results – Jean-François Fabre Aug 19 '17 at 20:19
  • `Traceback (most recent call last): File "", line 1, in platform._get_real_winver(10,10,10) AttributeError: 'module' object has no attribute '_get_real_winver'` – r0w Aug 19 '17 at 20:23
  • can you print `platform.__file__` ? since you have the same version this function _should_ exist. What about uname? my guess: some "patch" platform.py file overriding the official one or a remaining .pyc file somewhere – Jean-François Fabre Aug 19 '17 at 20:24
  • Well... uname() exists but still returns the wrong version. And __file__ returns the correct path like it should – r0w Aug 19 '17 at 20:33
  • @RobinWeiland The version "6.2.9200" is actually the version number of Windows 8, according to the [Wikipédia site](https://en.wikipedia.org/wiki/Ver_(command)). What is the ouput of the `ver` command on your updated PC? – Laurent LAPORTE Aug 19 '17 at 20:50
  • `Microsoft Windows [Version 10.0.14393]` – r0w Aug 19 '17 at 20:58
  • can you check that `_get_real_winver` is actually present (or not) in `platform.__file__` ? it _should_ be, and since it's not found, there's a problem! – Jean-François Fabre Aug 19 '17 at 21:08
  • there is no string `_get_real_winver` in the file according to pycharm – r0w Aug 19 '17 at 21:24

3 Answers3

2

From the Python Changelog Documentation for 3.4.4-release-candidate-1

bpo-19143: platform module now reads Windows version from kernel32.dll to avoid compatibility shims.

which fixes the referenced bug:

Python is returning incorrect version info under Windows 8.1. ... it appears MS is "deprecating" GetVersionEx()

which references a StackOverflow question.

robert_x44
  • 9,224
  • 1
  • 32
  • 37
0
import platform
platform.platform()

That gives me the number 10, I assume since I'm running windows 10.

platform.system()

That returns windows.

El-Chief
  • 383
  • 3
  • 15
-1

Windows 10 is notorious exactly for this issue, hardship of detecting the true Windows version via previously known API. To make the long story short (sorry if this doesn't sound like a 'quality' answer) one needs either a OS compatibility element in the app manifest, or egregious hacks. Previously known API (GetVersionEx, VerifyVersionInfo) declared deprecated. So, what the Python interpreter gets, depends likely on whether it is built with a suitable manifest.

Recent Python executables have Win10 listed in the manifest (yes, I've checked, on v. 3.6.1) so they can get the correct Win10 version in a normal way... Until Microsoft breaks it again.

ddbug
  • 1,392
  • 1
  • 11
  • 25
  • 1
    The backwards-compatibility behaviour you're talking about was introduced in Windows 8.1. No "egregious hacks" are necessary; there's a [documented solution](https://msdn.microsoft.com/en-us/library/windows/desktop/ms724429(v=vs.85).aspx). Python *should* be doing the right thing by now, and it seems to be working for Jean. – Harry Johnston Aug 19 '17 at 23:43
  • @HarryJohnston - your 'documented solution' link (version helpers) is based on API which is now declared deprecated. Without a proper manifest the 'version helpers' won't work. Recently built Python executables (3.6.1 for example) have the manifest with Win10 compatibility (there are also other reasons to do this - long paths support for one). But if someone has to run old executables on Win10 for some reason - sorry, no luck. – ddbug Aug 20 '17 at 00:08
  • Quoting from my link: "To obtain the full version number for the operating system, call the GetFileVersionInfo function on one of the system DLLs, such as Kernel32.dll, then call VerQueryValue to obtain the \\StringFileInfo\\\\ProductVersion subblock of the file version information." That's the correct solution, does not depend on the manifest, and [Python does indeed use it](https://stackoverflow.com/a/45777288/886887). The problem is just that the OP is using a seriously out-of-date version of Python. – Harry Johnston Aug 20 '17 at 00:12
  • On this I completely agree. The OP likely is using an old binary without the proper manifest. Reading the version of kernel32.dll is one of egregious hacks. It is shocking to read advises like this on MSDN, But compared to other woes these days, it's nonsense. – ddbug Aug 20 '17 at 00:16
  • Reading the version number from kernel32.dll isn't a hack, the decision to make that the only supported method (for logging purposes, pretty much the only case when you need the actual version number) was quite deliberate. Whether or not it will work, i.e., persuade programmers to use the helper functions rather than continuing to write their own broken version number checks, I don't know, but it wasn't something that was done gratuitously or carelessly. – Harry Johnston Aug 20 '17 at 01:36