[Bug 44728] New: Bad windows version detection with python module " platform"
https://bugs.winehq.org/show_bug.cgi?id=44728 Bug ID: 44728 Summary: Bad windows version detection with python module "platform" Product: Wine Version: 3.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gillg02(a)hotmail.com Distribution: --- If you use a python script (for exemple built-in into an installer) wich use native module "platform" to detect OS platform and version, you could have a bad version number regarding your wine config. Here, an extract of native "platform.py" file (python 3.5), and the line wich cause this issue + a test to patch it temporarly. def win32_ver(release='', version='', csd='', ptype=''): try: from sys import getwindowsversion except ImportError: return release, version, csd, ptype try: from winreg import OpenKeyEx, QueryValueEx, CloseKey, HKEY_LOCAL_MACHINE except ImportError: from _winreg import OpenKeyEx, QueryValueEx, CloseKey, HKEY_LOCAL_MACHINE winver = getwindowsversion() maj, min, build = winver._platform_version or winver[:3] ########## Begin PATCH for WineHQ ############ maj, min, build = winver[:3] ########## End PATCH for WineHQ ############ version = '{0}.{1}.{2}'.format(maj, min, build) release = (_WIN32_CLIENT_RELEASES.get((maj, min)) or _WIN32_CLIENT_RELEASES.get((maj, None)) or release) For a win10 configured, see dumps below : winver._platform_version => (5, 1, 2600) winver[:3] => (10, 0, 15063) I don't know exactly why, but somwhere in windows confs or dlls something is wrong. For information, getwindowsversion() seems to be a wrapper of Win function GetVersionEx() -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #1 from Fabian Maurer <dark.shadow4(a)web.de> --- I don't really understand what's wrong. What does happen on windows, what does happen on wine? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 --- Comment #2 from GG <gillg02(a)hotmail.com> --- On normal case, getwindowsversion()._platform_version and getwindowsversion()[:3] should return current splitted windows version. (I don't know exactly why python lib use a fallback) HERE : https://github.com/python/cpython/blob/3.5/Python/sysmodule.c#L818 the code of sys.getwindowsversion() for python. Answer seems near. On Wine (win10 configured) : getwindowsversion()._platform_version return (5, 1, 2600) (XP version) and getwindowsversion()[:3] return (10, 0, 15063) (good windows 10 version) So, if you use a python script to get your plateform version, you have an error. https://docs.python.org/fr/3.5/library/platform.html#module-platform #### Sample python script : import platform print(platform.version()) print(platform.uname()) Here, windows version will be badly detected (see native code of platform module, without my patch above) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 --- Comment #3 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to GG from comment #2)
On normal case,
getwindowsversion()._platform_version and getwindowsversion()[:3] should return current splitted windows version. (I don't know exactly why python lib use a fallback) HERE : https://github.com/python/cpython/blob/3.5/Python/sysmodule.c#L818 the code of sys.getwindowsversion() for python. Answer seems near.
On Wine (win10 configured) :
getwindowsversion()._platform_version return (5, 1, 2600) (XP version) and getwindowsversion()[:3] return (10, 0, 15063) (good windows 10 version)
According to this source file they are reading into kernel32.dll version resource. This data does not change when you switch reported version for your wineprefix. In order to match one to another we'll need some magic to dynamically adjust version blobs, after system modules are loaded. Right now this won't work obviously. I have no idea what was the motivation to ignore what GetVersionEx() returns, and use proper manifests with compatibility sections. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 --- Comment #4 from GG <gillg02(a)hotmail.com> --- Reason seems officialy : // GetVersion will lie if we are running in a compatibility mode. // We need to read the version info from a system file resource // to accurately identify the OS version. If we fail for any reason, // just return whatever GetVersion said. But in fact, goal of compatibility mode is to "lie" at running program... stange reason. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #5 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to GG from comment #4)
Reason seems officialy :
// GetVersion will lie if we are running in a compatibility mode. // We need to read the version info from a system file resource // to accurately identify the OS version. If we fail for any reason, // just return whatever GetVersion said.
But in fact, goal of compatibility mode is to "lie" at running program... stange reason.
Seems to me like it's working as intended, then... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 --- Comment #6 from Fabian Maurer <dark.shadow4(a)web.de> ---
But in fact, goal of compatibility mode is to "lie" at running program... stange reason.
Well, it kinda makes sense when you for example want to give the user a report what OS they are using, or their customers are using. There are moments you really want to know what OS there is. Question is, is that something we want to support, or are we fine with that not working on wine? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 --- Comment #7 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Fabian Maurer from comment #6)
But in fact, goal of compatibility mode is to "lie" at running program... stange reason.
Well, it kinda makes sense when you for example want to give the user a report what OS they are using, or their customers are using. There are moments you really want to know what OS there is.
Question is, is that something we want to support, or are we fine with that not working on wine?
To be more clear... if the goal is to get at the real platform information, then it seems to me that Wine would already be doing the right thing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 --- Comment #8 from Nikolay Sivov <bunglehead(a)gmail.com> --- As a compromise we could implement GetVersion() awareness of compatibility data in activation context, and bump kernel32 to Windows 7. This way application without manifest will get Windows 7 version regardless of version selected in Winecfg. Which is how it's supposed to work I think. That's assuming all that works the way I think it does, and python.exe (is this correct?) does not declare compatibility. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 --- Comment #9 from GG <gillg02(a)hotmail.com> --- (In reply to Nikolay Sivov from comment #8)
As a compromise we could implement GetVersion() awareness of compatibility data in activation context, and bump kernel32 to Windows 7. This way application without manifest will get Windows 7 version regardless of version selected in Winecfg. Which is how it's supposed to work I think. That's assuming all that works the way I think it does, and python.exe (is this correct?) does not declare compatibility.
This solution is enougth in my case. And yes entry point in my case is python.exe or python.dll. To be more precise, my original bug case, is with a software packed with python scripts, and what refuse to install software on older than 7 windows version. But with your solution, if you try to install a software limited on windows 8 for example, problem stay present... Maybe two ideas : * Configure kernel32 internal version by a specific config "file", version could be reloaded at windows "reboot". Do you think it's possible to take compilation consts dynamic ? https://source.winehq.org/source/dlls/kernel32/version.rc * Else... "switch"/"replace" between x compiled kernels versions (eg: c:\windows\kernels\)... then reboot windows after. This 2 solutions are ONLY for "default" config, if you override windows version for a specific software, it's like on a real windows, you change only "GetVersion" return. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 GG <gillg02(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 tinywrkbee <tinywrkbee(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tinywrkbee(a)gmail.com --- Comment #10 from tinywrkbee <tinywrkbee(a)gmail.com> --- Hi, I just want to point out that this is affecting Fusion 360 installation. Fusion 360 is free for students, hobbyists and startups. See the links more details about about Fusion 360 free license qualification: https://www.autodesk.com/products/fusion-360/students-teachers-educators https://www.autodesk.com/campaigns/fusion-360-for-hobbyists I posted a test result with workarounds for getting the application to install and run. https://appdb.winehq.org/objectManager.php?sClass=version&iId=36468&iTesting... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 Tony763 <tony762(a)gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tony762(a)gmx.com --- Comment #11 from Tony763 <tony762(a)gmx.com> --- Hello, for latest version of Fusion Installer bug is fixed as they use Python 3.7. See: https://github.com/cryinkfly/Fusion-360---Linux-Wine-Version-/issues/12 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44728 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 --- Comment #12 from Nikolay Sivov <bunglehead(a)gmail.com> --- GG, could you produce a small python test script that shows the issue? Assuming there is still one, since GetVersion() now supports compatibility configs. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla