http://bugs.winehq.org/show_bug.cgi?id=59525 Bug ID: 59525 Summary: Apps running with Win10 or Win11 compatibility detect Win8.1 Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: winehq-bugs@brocky.net Distribution: --- Created attachment 80549 --> http://bugs.winehq.org/attachment.cgi?id=80549 Patch to add Win10 compatibility to msiexec.manifest that doesn't seem to work I'm dealing with a suite of applications that only work on Windows 10 or 11 (as a software-defined block from what I can tell), but when I run them, they detect the version as Windows 8.1 (6.2) and abort, even when running with the Windows Version set to Windows 11 both as the default, and specifically for the .exe I try to run. I was even unable to install the app because msiexec.exe had the same issue, where the installer would check the `Environment.OSVersion.Version` (C#, which calls `GetVersionEx` under the hood) and abort because it got 6.2 instead of 10.0. There seems to be several parts to this problem: 1. The application I'm trying to run has the MajorOperatingSystemVersion.MinorOperatingSystemVersion in the OptionalHeader set to 6.0, and the manifest doesn't declare a `supportedOS`, so Wine seems to be thinking it needs to limit the compatibility level to Win8.1. I'm not really sure what's standard or normal, but I checked a few other programs I have (only in a hex editor, not in Wine) that also require Windows 10, and none of them seem to fit that criteria. They all have versions less than 10 in their EXE headers and nothing in the manifest saying otherwise either. 2. Even if I try to force the compatibility level for the specific EXEs in winecfg to be Win10 or Win11, that setting is ignored. This is because the compatibility that has been selected is done in RtlGetVersion(), but then the init_current_version() that is used for GetVersionEx (in init_current_version) applies the backwards-compatibility logic afterwards, essentially ignoring the configuration. 3. msiexec has the same problem as point 1, but has the MajorOperatingSystemVersion.MinorOperatingSystemVersion set to 4.0 and also doesn't declare a supportedOS in the manifest. Presumably, any installer that checks the OS version would fail if it requires Win10 or later, even if the programs it installs do set the image headers or manifest correctly. I tried adding the below to msiexec.manifest (also attached as a patch), but it didn't seem to help with the installer detecting the desired 10.0 version. From what I can understand of the code in init_current_version (dlls\kernelbase\version.c), this should have worked, but didn't. Not sure if I messed something up or I misunderstood how to declare this. <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <!-- ... existing manifest ... --> <application> <!-- Windows 10 --> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /> </application> </compatibility> </assembly> The only way I was able to get my program to install and run was to delete the final `if` statement that updates the `current_version` to the downgraded `ver`, effectively disabling the entire compatibility stuff. After that, the programs seem to install and run just fine. -- 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.