Zach Burlingame

Programming, Computers, and Other Notes on Technology

Targeting Windows 2000/XP RTM/XP SP1 from Visual Studio 2010

I’m currently working on a little native C application using the C-runtime libraries (CRT) to detect Windows power events. I ran into a problem when testing my application on Windows XP Professional 32-bit RTM (e.g. “Gold Release”, no service packs). When I attempt to run the application, I get the following error message:

Entry Point Not Found

Entry Point Not Found. The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll.

Huh?!

After a little digging, it turns out the Microsoft rather quietly discontinued targeting the Windows 2000 and Windows XP RTM/SP1 platforms with Visual Studio 2010. The last release that will target these platforms is Visual Studio 2008.

There were various suggestions on how to workaround this issue including recompiling the CRT, implementing the missing functions in your own w2kcompat.lib, FASM/MASM assembly magic, and reverting to using Visual Studio 2008.  However all of these offered significant drawbacks for me. I do not want to be in the business of supporting a custom compiled version of the CRT. I don’t understand the assembly editing based solutions sufficiently to feel comfortable supporting them on x86 and x64 platforms in the field.

The workaround that works for me and that I ultimately used is to target the Visual Studio 2008 (VC 9.0) Platform Toolset from within my Visual Studio 2010 projects as suggested here and here. There were three key upsides for me with this solution:

  1. This seems like the most reasonable option to support in deployments. No custom builds and no assembly hacking.
  2. I can continue to use VS2k10 and all it’s goodness. (Well, almost. Any feature added in the VC10 runtime won’t be available. )
  3. This modification can be done on a per project (and actually, per Build Configuration) basis, so I don’t have to make system-wide changes to my VS install.

The major downside to this option is that it requires me to have Visual Studio 2008 installed, but this was something I was willing to live with.

One way to accomplish this workaround that was suggested is to place the path to the Visual Studio 2008 VC libs (e.g. “C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib” for 32-bit builds) first in the Additional Library Directories under the Linker options for your project. This messy because you have to do this for every configuration of every project in your solution that needs it and it varies for x86 versus x64 builds. Making matters worse is that the location of these files may vary from system to system, so what works for one developer’s machine may not work for another. Not ideal.

The cleaner and easier way to do this is to set the Platform Toolset in the project’s general properties pane. You still need to do this for each project as well as all configurations and all platforms. However, unlike the previous method, this one uses the same value across configurations and platforms and it’s portable across machines.

Setting the Platform Toolset in Visual Studio 2010

Setting the Platform Toolset in Visual Studio 2010

Tags: ,

3 Responses to “Targeting Windows 2000/XP RTM/XP SP1 from Visual Studio 2010”

  • Jay says:

    Thanks! This post saved me a lot of time. I’m hitting the same issue.

  • Oliver says:

    Just wondering, wouldn’t the respective SDK version work, too? Well, as long as you don’t require any libraries from VS 2008, that is.

    From my experience the SDK compilers suddenly become optimizing compilers when the VS SKUs are installed on the system, while standalone they will be non-optimizing compilers. Haven’t had the time to check what exactly makes the difference (I presume some DLLs and perhaps registry settings). Either way, they are a full replacement for the compilers that ship with VS as long as some VS SKU is installed in parallel.

  • ZachB says:

    @Oliver targeting the SDK from Windows 2000 or XP should work. I was under the impression that the compiler in Visual Studio matches one from an SDK exactly and that all compiler optimizations are available via the SDK (Windows Vista/Server 2003 SDK – VS2K5, Windows 7/Server 2008 – VS2k8, etc.) I haven’t tried it though, so there may be differences.

    That said, I generally don’t use an SDK as my platform toolset because there are improvements to the CRT that I want to leverage and it can be a pain for others to reuse code if they have to install the SDK. The option of using VS2k8 has downsides as well, since it requires a second IDE be installed, however I already had both installed on my machine. The combination of statically linking against the CRT and using the configuration above lets me use the VS2k10 IDE, compile for Win2K/XP RTM forward (via VS2k8’s toolset) and use improvements from the CRT.

  • Leave a Reply

    *