Side-by-side error if compiled under Windows 7 but not XP??

[steveq]

Hey All,

I have written a 32 bit MFC Dialog based program. It is written using Visual Studio 2005 v8.0.50727.867.

If I compile this software using on an 32bit XP based PC, then everything is fine and user can run the software with no worries.
If however I compile it using my Windows 7 64bit PC, using the exact same compiler, then it will run on the PC that compiled it, but I get side by side errors on any other machine that tries to run it (well at least those I have asked to test it)?

Does anyone have any ideas on what may cause this please?

It's doing my head in!

Thanks heaps in advance for your help,

Steve Q.

[VictorN]

Do you use the same compiler/linker options on Windows 7 64bit PC as you used on 32bit XP based PC?

[steveq]

Hey VictorN,

Thanks for your help.

Yep, they are. I copied the project folder from my XP PC to my Win 7 PC, loaded the .sln and did a re-build.
I just went through every option int the project properties in the solution and compare them with both machines. They are identical.

Steve Q.

[John E]

If you can view the executable modules without damaging them, search for the word "Manifest". You'll probably find that when you compile on the XP machine it's specifying some manifest that's later than 867 (probably 4053) which happens to be on the other person's machine. But when you build it on Windows 7, an even later manifest gets specified (which isn't on the other person's machine). By default, your compiler will specify the latest version 8 runtime that it finds on the build machine - but....

If that's the case I can show you how to specify an exact manifest in your build (although I'm not at the right PC just at the moment). It's just a matter of adding some lines to a header file.

[steveq]

Hi John E,

Thanks for your reply. It sounds like this may be the case. I can't check it until Monday, if you wouldn't mind posting your header fix in the mean time, I'd greatly appreciate it.

Many thanks,

Steve Q

[John E]

No problem. You need to create a special header file which will be "force indluded" in your project(s). The header file can be called anything you like and can be located anywhere that's convenient. On my system, the file is:-F:\+GTK-SOURCES\gnu-win32\include\targetsxs.h

The contents look like this:-

#ifndef _TARGETSXS_H_
#define _TARGETSXS_H_

#pragma warning( disable : 4996 )

#ifndef __midl
#define _SXS_ASSEMBLY_VERSION "8.0.50727.4053"
#define _CRT_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
#define _MFC_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
#define _ATL_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION

#ifdef __cplusplus
extern "C" {
#endif
__declspec(selectany) int _forceCRTManifest;
__declspec(selectany) int _forceMFCManifest;
__declspec(selectany) int _forceAtlDllManifest;
__declspec(selectany) int _forceCRTManifestRTM;
__declspec(selectany) int _forceMFCManifestRTM;
__declspec(selectany) int _forceAtlDllManifestRTM;
#ifdef __cplusplus
}
#endif
#endif

#endif /*_TARGETSXS_H_*/

After you create the header file you'll need to ensure that every module in your project includes it. Strictly speaking, you only need to do this for executable modules (DLLs and EXEs). It isn't necessary for any static libs you build.

You can force it to get included by opening the Properties window for each project in your solution, then select Configuration Properties->C/C++->Command Line. Add this line to the box that's labelled Additional options:

/FIF:\+GTK-SOURCES\gnu-win32\include\targetsxs.h

Obviously, adapt that to suit your own path.

Note that the header file only specifies the minimum specification for your app's 'C' runtime. If your end user's system has a more recent version, the most recent version applicable will get used. The general idea is to specify a value that's low enough to be available on everyone's system.