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.

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.

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.

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!)