Compiling 32-bit application using Visual Studio on a 64-bit machine

I'm trying to compile a simple 32-bit Hello W开发者_运维百科orld application written in C using Visual Studio 2010 on a 64-bit machine on a Windows 7 fresh install. I also installed the "Windows SDK for Windows 7 and .NET Framework 4" after installing Visual Studio. I built the application selecting "Win32" as platform. It works on Windows 7 but if I run the application on my 32-bit machine with Windows XP Professional (fresh install also this, without softwares and Service Packs) it seems not working getting this error:

"This application has failed to start because msvcr100.dll was not found"

If it can be useful Dependency Walker detects 2 errors (see the linked picture for details):

"Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module."
"Error: Modules with different CPU types were found."

http://img820.imageshack.us/img820/4725/errordp.png (PIcture)

How can I solve it? Thanks!

The machine on which it is run needs the runtime libraries. See this MSDN information.

Don't trust Dependency Walker on this... It clearly shows your exe is 32 bit. Your problem is with the VC redistributables, which are the CRT dlls - look for vcredist_x86.exe in your VS installation. You should run it before you run your app.

Another option is to statically link the CRT. See the /MT option. Will make your exe larger, but save the vcredist stuff.

The problem here is the C runtime used by the compiled program is missing on the Windows XP machine. Visual Studio 2010 will by default us the 10.0 (msvcr100.dll) runtime which is not available on XP by default. You need to manually deploy the C runtime on your machine in order for your program to run.

You may want to read the following MSDN article which discusses the issues around deploying C applications built with Visual Studio 2010

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

There may be additional 32 / 64 issues at work but this appears to be the primary problem

The answers about the runtime library are correct. Another possible solution is to link to the static runtime libraries rather than to the DLL versions. This way you can build an executable that you can drop onto any machine without extra deployment hassles.

It's a trade-off, but, without knowing more about your situation, it might be worth considering.