[PATCH 1/4] kernelbase: Implement compatibility mode for GetVersionEx.

Nikolay Sivov nsivov at codeweavers.com
Mon Mar 16 08:52:25 CDT 2020



On 3/16/20 4:44 PM, Gabriel Ivăncescu wrote:
> Hi Nikolay,
>
> On 16/03/2020 15:21, Nikolay Sivov wrote:
>> On 3/16/20 4:05 PM, Gabriel Ivăncescu wrote:
>>> I'm introducing an exported internal ntdll function, since I didn't 
>>> want to
>>> duplicate the table for kernelbase. I don't know if this is the best 
>>> way,
>>> so let me know if I should proceed differently.
>> I think custom export is unnecessary in this case. You only need a 
>> public ntdll call that returns unaltered version,
>> that you can later clamp to Windows 8.1, unless manifest version is 
>> specified. Is RtlGetVersion() itself affected by manifest?
>>
>
> Only the functions changed by the patch series are affected. Just 
> clamping to Windows 8 isn't going to work, consider the case where:
>
> - We have Windows 10 prefix.
> - Application only specifies GUID for Windows 8.1, not Windows 10.
> - Returned Version must be Windows 8.1, not Windows 8 (no manifest).
>
> The reason I exported it from ntdll was to have access to the version 
> table there. Otherwise we'd have to duplicate the table from WIN8 and up.
>
> It also makes it trivial to extend it, should Microsoft release new 
> Windows versions: just add new GUIDs.
Guid/version mapping is not going to be used from ntdll, right? So far 
you'll only need to duplicate two 8.1 and 10, with a good chance that no 
version will follow as Windows continues to be 10. By the way if you set 
manifest entry to anything below Win 8.1 (Vista/7/8), does it affect 
reported version?
>
>
>>
>> P.S. another question is if PEB fields are left intact.
>>
>
> Good question, I'll test it. Though of course it would be a separate 
> patch if so.
>
> Thanks,
> Gabriel




More information about the wine-devel mailing list