On 16/03/2020 15:52, Nikolay Sivov wrote:
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?
Yeah, I'll have to duplicate everything from WIN8 and up, so that's 3 versions currently. Do you think that's better?
Another issue is VerifyVersionInfo. We'd have to duplicate the entire RtlVerifyVersionInfo function in kernel32 (but use GetVersionEx).
Also, setting it to anything below WIN8.1 has no effect as far as I'm aware, at least with respect to these APIs. It will still report WIN8.