GNOME Bugzilla – Bug 756179
gwin32.c: Replace VerifyVersionInfoW() with RtlGetVersion() due to API deprecation
Last modified: 2015-10-27 01:41:30 UTC
Hi, In Windows 10, VerifyVersionInfoW() has been deprecated, so using that API on Windows 10 will return version info for Windows 8.1 unless a compatibility manifest is used. This patch updates g_win32_check_windows_version() to use RtlGetVersion(). The other benefit of using RtlGetVersion() is that it is listed as a Universal Windows API, over VerifyVersionInfoW(), which is for Win32/Desktop apps only.
Created attachment 312815 [details] [review] gwin32.c: Switch to RtlGetVersion() for g_win32_check_windows_version() Hi, Here goes the patch.
Review of attachment 312815 [details] [review]: See some nitpicks ::: glib/gwin32.c @@ +50,3 @@ #endif /* _MSC_VER || __DMC__ */ +#if WINAPI_FAMILY == 2 can we get a define for this magic 2? @@ +578,3 @@ +#if WINAPI_FAMILY != 2 + hmodule = LoadLibraryW (L"ntdll.dll"); + g_return_val_if_fail (hmodule, FALSE); be explicit and use != NULL @@ +581,3 @@ + + RtlGetVersion = (fRtlGetVersion *) GetProcAddress (hmodule, "RtlGetVersion"); + g_return_val_if_fail (RtlGetVersion, FALSE); same here with != NULL @@ +627,3 @@ + + if (is_ver_checked && is_type_checked) + return TRUE; just do return is_ver_checked && is_type_checked;
Created attachment 312818 [details] [review] gwin32.c: Switch to RtlGetVersion() for g_win32_check_windows_version() [take ii] Hi Nacho, Here's the updated patch with the suggested changes. With blessings, thank you!
Review of attachment 312818 [details] [review]: Looks good to me. I'd say you should also backport it
Hi Nacho, Thanks for the review, the patch was pushed as: master: 46a2047 glib-2-46: 2b8b936 glib-2-44: f0e1817 I will close this bug now.
Hi Fan, I just tested 3.18.2 and gtk seems to fail calling to this method (i.e launching gtk3-demo.exe). Can you please double check it? Thanks
Hi Nacho, I presume you are having this problem on 32-bit builds, not 64-bit builds. The problem is that RtlGetVersion() is actually a function that is declared with the WINAPI decoration, meaning that it is a __stdcall function. While this does not affect the symbol on 64-bit builds, but on 32-bit builds the symbol is mangled with a @4 suffix, which was why the program crashed because the symbol is not correctly loaded from ntdll.dll. The problem should now be fixed in master, glib-2-46 and glib-2-44, by adding the WINAPI decoration that is needed.[1] Thanks for letting me know about this-and let me know whether this fixes the issue for you. With blessings, thank you! [1]: Fixed in commits on master: d52625a glib-2-46: a2cd99b glib-2-44: ea06279