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@winehq.org Reporter: gillg02@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()
https://bugs.winehq.org/show_bug.cgi?id=44728
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- I don't really understand what's wrong. What does happen on windows, what does happen on wine?
https://bugs.winehq.org/show_bug.cgi?id=44728
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=44728
--- Comment #2 from GG gillg02@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)
https://bugs.winehq.org/show_bug.cgi?id=44728
--- Comment #3 from Nikolay Sivov bunglehead@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.
https://bugs.winehq.org/show_bug.cgi?id=44728
--- Comment #4 from GG gillg02@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.
https://bugs.winehq.org/show_bug.cgi?id=44728
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #5 from Zebediah Figura z.figura12@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...
https://bugs.winehq.org/show_bug.cgi?id=44728
--- Comment #6 from Fabian Maurer dark.shadow4@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?
https://bugs.winehq.org/show_bug.cgi?id=44728
--- Comment #7 from Zebediah Figura z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=44728
--- Comment #8 from Nikolay Sivov bunglehead@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.
https://bugs.winehq.org/show_bug.cgi?id=44728
--- Comment #9 from GG gillg02@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.
https://bugs.winehq.org/show_bug.cgi?id=44728
GG gillg02@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
https://bugs.winehq.org/show_bug.cgi?id=44728
tinywrkbee tinywrkbee@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tinywrkbee@gmail.com
--- Comment #10 from tinywrkbee tinywrkbee@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&...
https://bugs.winehq.org/show_bug.cgi?id=44728
Tony763 tony762@gmx.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tony762@gmx.com
--- Comment #11 from Tony763 tony762@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
https://bugs.winehq.org/show_bug.cgi?id=44728
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1
--- Comment #12 from Nikolay Sivov bunglehead@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.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla