The two 'correct' options are adding the manifest or doing nothing (based on a number of very passionate internal discussions I was able to dig up).

Without the manifest, various APIs may behave differently - it's the new way that Windows decides whether to apply compatibility settings. If sys.getwindowsversion() reports the actual version number and people are getting old APIs through ctypes, more problems are caused than solved. The theory is that if you apply the manifest, you are stating that you have tested the application against that version (helped by having an unpredictable scheme without supersets).

Without the manifest, Python is always going to be run in compatibility mode for Windows 8, even as breaking changes are made in the future.

It would be quite a reasonable position (compatibility-wise) for Python to only manifest for the earliest version it supported. That way, all Python scripts are going to behave the same on later versions of Windows, even as the API behaviours change. (Note that I'm not advocating this - I'm just trying to explain the rationale better than our docs have done it.)

But basically, the result of sys.getwindowsversion() should return the behaviour that the program is going to get. If python.exe itself is manifested to support Windows 8.1, or if it isn't, both the behaviour and the version will match. IMO, and the Windows dev's opinion, this is correct.


The one concession that the Windows dev is willing to make is for logging, in which case the version number should be read as a string from a standard DLL like kernel32.dll. This would be appropriate for platform.win32_ver(), but as discussed above, not for sys.getwindowsversion().

Reading the registry is not recommended - the argument is roughly "GetVersionEx was being misused so we 'fixed' it, and when the registry starts being misused we'll 'fix' that too".