visual c++ - warning C4996: 'GetVersionExW': was declared deprecated -

i working on vs 2013 in win 8.1. how solve warning?

the basic question "why calling getversionexw in first place?" answer question determines should instead.

the deprecation warning there give developers heads-up appcompat behavior change started in windows 8.1. see windows , windows server compatibility cookbook: windows 8, windows 8.1, , windows server 2012. in short, function doesn't return think returns default.

historically, badly written os version checks primary source of appcompat bugs windows os upgrades. there've been number of different approaches trying mitigate problem (the appverifier version lie, verifyversioninfo api, etc.), , aggressive date.

the versionhelpers.h mentioned in comments in windows 8.1 sdk comes visual studio 2013. not new api; utility code makes use of verifyversioninfo api introduced in windows 2000. these functions doing "you must high ride ride" style checks class of version checks badly written. code pretty simple. example, iswindowsvistasp2orgreater test is:

versionhelperapi iswindowsversionorgreater(word wmajorversion, word wminorversion, word wservicepackmajor) {     osversioninfoexw osvi = { sizeof(osvi), 0, 0, 0, 0, {0}, 0, 0 };     dwordlong        const dwlconditionmask = versetconditionmask(         versetconditionmask(         versetconditionmask(             0, ver_majorversion, ver_greater_equal),                ver_minorversion, ver_greater_equal),                ver_servicepackmajor, ver_greater_equal);      osvi.dwmajorversion = wmajorversion;     osvi.dwminorversion = wminorversion;     osvi.wservicepackmajor = wservicepackmajor;      return verifyversioninfow(&osvi, ver_majorversion | ver_minorversion | ver_servicepackmajor, dwlconditionmask) != false; }  versionhelperapi iswindowsvistasp2orgreater() {     return iswindowsversionorgreater(hibyte(_win32_winnt_vista), lobyte(_win32_winnt_vista), 2); } 

you don't need use versionhelpers.h kind of code yourself, convenient if using vs 2013 compiler. games, have article what's in version number? uses verifyversioninfo kind of reasonable checks 1 should game deployment.

note if using vs 2013 v120_xp platform toolset target windows xp, you'll using windows 7.1a sdk , #include <versionhelpers.h> won't work. can of course use verifyversioninfo directly.

the other major use of getversionexw diagnostic logs , telemetry. in case, 1 option continue use api , make sure have right manifest entries in application ensure reasonably accurate results. see manifest madness details on here achieve this. main thing keep in mind unless routinely update code, stop getting accurate information in future version of os.

note recommended put <compatibility> section in embedded manifest whether or not care results of getversionex general best practice. allows os automatically apply future appcompat fixes based on knowing how app tested.

for diagnostic logs, approach might bit more robust grab version number out of system dll kernel32.dll using getfileversioninfow. approach has major caveet: do not try parsing, doing comparisons, or making code assumptions based on file version obtain way; write out somewhere. otherwise risk recreating same bad os version check problem better solved verifyversioninfo. option not available windows store apps, windows phone apps, etc. should work win32 desktop apps.

#include <windows.h> #include <stdint.h> #include <memory>  #pragma comment(lib, "version.lib" )  bool getosversionstring( wchar* version, size_t maxlen ) {     wchar path[ _max_path ];     if ( !getsystemdirectoryw( path, _max_path ) )         return false;      wcscat_s( path, l"\\kernel32.dll" );      //     // based on example code article     // http://support.microsoft.com/kb/167597     //      dword handle; #if (_win32_winnt >= _win32_winnt_vista)     dword len = getfileversioninfosizeexw( file_ver_get_neutral, path, &handle ); #else     dword len = getfileversioninfosizew( path, &handle ); #endif     if ( !len )         return false;      std::unique_ptr<uint8_t> buff( new (std::nothrow) uint8_t[ len ] );     if ( !buff )         return false;  #if (_win32_winnt >= _win32_winnt_vista)     if ( !getfileversioninfoexw( file_ver_get_neutral, path, 0, len, buff.get() ) ) #else     if ( !getfileversioninfow( path, 0, len, buff.get() ) ) #endif         return false;      vs_fixedfileinfo *vinfo = nullptr;     uint infosize;      if ( !verqueryvaluew( buff.get(), l"\\", reinterpret_cast<lpvoid*>( &vinfo ), &infosize ) )         return false;      if ( !infosize )         return false;      swprintf_s( version, maxlen, l"%u.%u.%u.%u",                 hiword( vinfo->dwfileversionms ),                 loword(vinfo->dwfileversionms),                 hiword(vinfo->dwfileversionls),                 loword(vinfo->dwfileversionls) );      return true; } 

if there other reason calling getversionexw, shouldn't calling it. checking component might missing shouldn't tied version check. example, if application requires media foundation, should set "you must high ride ride check" versionhelpers.h iswindowsvistaorgreater deployment, @ runtime should use explicit linking via loadlibrary or loadlibaryex report error or use fallback if mfplat.dll not found.

explicit linking not option windows store apps. windows 8.x solves particular problem having stub mfplat.dll , mfstartup return e_notimpl. see "who moved [windows media] cheese"?

another example: if application wants use direct3d 11.2 if available , otherwise uses directx 11.0, you'd use set iswindowsvistasp2orgreater minimum bar deployment perhaps using d3d11installhelper. @ runtime, you'd create directx 11.0 device , if fails, you'd report error. if obtain id3d11device, you'd queryinterface id3d11device2 if succeeds means using os supports directx 11.2. see anatomy of direct3d 11 create device.

if hypothetical direct3d application supports windows xp, you'd use deployment bar of iswindowsxpsp2orgreater or iswindowsxpsp3orgreater, , @ run time use explicit linking try find d3d11.dll. if wasn't present, you'd fall using direct3d 9--since set minimum bar, know directx 9.0c or later present.

they key point here in cases, should not use getversionex.

note windows 10, verifyversioninfo , getting file version stamp via getfileversioninfo kernel32.lib subject same manifest based behavior getversionex (i.e. without manifest guid windows 10, returns results if os version 6.2 rather 10.0).

for universal windows apps on windows 10, can new winrt api analyticsinfo version stamp string diagnostic logs , telemetry.