Newest SDK doesn't work with VS6.0


  • Recently i was working on a new small watch-dog program using VC++ 6.0 (forgive me, i still use VS6.0, we will move to VS2010 soon but we need to maintain old softwares which were programmed with VC 6.0).

    In this watch-dog program, i need to terminate process under some very special and rare case when the main program crashs with exception. However, to use SDK procedures such as EnumProcesses(), TerminateProcess(), we need psapi.h and psapi.lib, which are included in Platform SDK. As it is said that it's better to use newest SDK. So i downloaded SDK v7.0 for Windows 7. In psapi.h, there are many type definitions, such as __out_bcount  __in  __out, which i don't where they are defined. Finally, I got Windows Platform SDK for Windows Server 2003 R2, in this SDK, there is no such type definitions at all.

    So, i guess the newest SDK requires i move to newest Visual Studio version, such as VS2010? If so, how comes the conclusion "it's better to use newest SDKs", seems there is no back-compatiblity with older Visual Studio versions.



    Wednesday, March 06, 2013 3:23 PM

All replies

  • At this point, VC 6.0 is 15 years old and there have been six major Visual Studio releases since then.

    The oldest VC toolset version supported by the Windows SDK 7.0 is Visual Studio 2005.

    The oldest VC toolset version supported by the Window  SDK 8.0 is Visual Studio 2010.

    The last Windows SDK / Platform SDK to officially support Visual Studio 6.0 was the February 2003 release.

    The modern Windows SDK makes use of SAL annotations for use with the /analyze static code analysis which are implemented by the compiler toolset. That is why VS 2005 or later is required because the older toolsets (VS 6.0 VS .NET 2002, VS .NET 2003) do not support this technology which is an essential part of Microsoft's Secure Development Lifecycle strategy.

    The tradeoff for ignoring generations of compiler changes is that the effort to move to newer tools is significantly larger than the incremental cost of moving from release to release. It's probably well past time to move up to something more recent. The main strong technical reason to stay on significantly older toolsets is to support old and unsupported releases of Windows. These days that's mostly folks staying with VS 2010 to support Windows 2000 legacy systems since VS 2012 only supports Windows XP or later. I would hope you aren't trying to support Windows 9x or Windows ME systems still.

    Wednesday, March 06, 2013 6:47 PM