Macro to determine windows version

[sagarkasture]

Hi,

I am working on porting some code from windows XP to Windows 7.
As per the article there are many API's that are banned in windows 7 as in following link.

http://msdn.microsoft.com/en-us/library/bb288454.aspx

Now I want to use the same code for both XP and Windows 7. But the new API's are not backward compatible. So I am looking for any simple macro's that are available to determine which windows version I am compiling for and will use the API accordingly.

ezample :

#ifdef WINDOWS_XP
   #define MY_STRCPY(src,dest)   strcpy(src,dest);
#elif defined WINDOWS_7
   #define MY_STRCPY(src,dest)   strcpy_s(src,dest,(strlen(src)+1)); 

Please reply if anybody has any idea regarding this.

[Null]

You have to check WINVER and/or WIN32_WINNT macros. Usually _WIN32_WINNT equals to WINVER

#if WINVER==0x0501 // XP
   #define MY_STRCPY(src,dest)   strcpy(src,dest);
#elif WINVER==0x0701 // 7
   #define MY_STRCPY(src,dest)   strcpy_s(src,dest,(strlen(src)+1));  

http://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx#macros_for_conditional_declarations

[modoran]

No, a function like strcpy() is absolutely NOT banned if you are using windows 7 SDK. Microsoft recommends using their crappy *_s() equivalents which are NOT portable and nobody uses except Visual Studio users.

There are no win32 APIs which cannot be used in windows 7 once the same code compiles fine with windows XP SDK.

There is _CRT_SECURE_NO_WARNINGS macro if you want to disable crappy VS warnings when you try to use "non-secure" functions, which btw are standard C functions.

[Computergeek01]

Why the "n" Functions Are Banned
The classic C runtime, "n" functions (such as strncpy and strncat) are banned because they are so hard to call correctly...

I am completely speechless right now... what retard would allow this to be printed on MSDN?!?!?! If this is the mind set that the current MS Development team had going into Windows 7 then I'm not going to wait around for Windows 8. I will keep my fond memories of this once great API and get out before they are all replaced with rage.

[andywestken]

Setting aside whether the _s functions are evil, I think you are worrying about the Windows version too much. strcpy_s, etc are CRT functions, not Win32 API calls, so their availability depends on the CRT you are linking against, not the version of Windows you run on.

The macros proposed above should really be switching on the version of Visual C++, not Windows. The secure functions turned up with Visual Studio 2005.

The ban referred to in the article mentioned above must refer to Microsoft's coding standards. Windows 7 runs our legacy code -- with loads of old CRT calls -- without complaint!

Andy

PS If you do use (eg) strcpy_s, note that the extra parameter is the buffer size, not the string length. And it's the second, not the third parameter. (And dest comes before src in the param list!)

errno_t strcpy_s(
   char *strDestination,
   size_t numberOfElements,
   const char *strSource 
);

numberOfElements is the size the destination string buffer.

so something like this would work for arrays but NOT char*/wchar_t* pointers to new-ed buffer.

#define MY_STRCPY(dest, src) strcpy_s(dest,sizeof(dest),src);

(wchar_t and TCHAR versions left as exercise for reader)

To handle dynamically allocated buffer, you will need a macro which allows you to provide the buffer size (and just ignores it in the non-_s case).

It might be better to provide a MY_STRCPY_S and then map it to strcpy when strcpy_s is not available.