On 8/05/2015 10:39, Gevorg Voskanyan wrote:
On 06.05.2015 14:03, Niall Douglas wrote:
[snip]
However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP,
Slight note on the above: that doesn't apply to all types of binaries, but only to EXE files. DLLs produced with a non-"_xp" toolset work just fine under Windows XP. In one of my projects I've put all the code in a DLL that is built regularly with the default toolset, and then I have a minimal EXE built with the _xp toolset that just forwards main()'s arguments to the DLL. That way the EXE never has to change, so there is no need to invoke the _xp toolset ever again even though the application undergoes heavy development and continues to work fine under Win XP.
This might eventually bite you. Granted that I haven't verified this myself, but one of the reasons announced for the "_xp" vs. not-"_xp" toolsets was that the SDK team had removed XP support from the latest Platform SDK. So one of the things that _xp does is to select the older Platform SDK headers that still do support XP. Most APIs are the same between XP and Vista/7, so *most of the time* you can get away with using the wrong version, just like most of the time you can get away with running code compiled with _WIN32_WINNT=0x0601 on XP. If you happen to use one of the APIs that doesn't exist on XP, though, or (harder to track down) if you use one of the APIs that does exist on both but has had a structure size change, then you'll get code that mysteriously fails on XP by using the wrong toolset and/or wrong _WIN32_WINNT setting. The toolset also affects which version of ATL/MFC are linked to, and again since the newer versions of these do make use of non-XP-compatible APIs in some classes, if you happen to use these in your own code then you'll have problems on XP. (And since this is an implementation detail, it's not documented which classes are "safe" on XP when using the non-XP toolset.)