[PATCH 1/4] kernelbase: Implement compatibility mode for GetVersionEx.
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
>>> 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
>> 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.
More information about the wine-devel