Jump to content
  • Advertisement
Sign in to follow this  
smallGame

exe from Vista to Xp?

This topic is 3502 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I am using: - Visual Studio 2008 Express Editions - Windows Vista - openGL I generate an exe I copy it on a Windows XP system, I get the following error: "The application can not be launched, configuration incorrect. Reinstall the application it can solve the problem" Why do I get this problem?

Share this post


Link to post
Share on other sites
Advertisement
Did you install the MSVC 2008 redistributable on the computer? Did you make sure to use a release build?

Share this post


Link to post
Share on other sites
Probably because you are dynamically linking the runtime library (i.e. the Standard Library). You can statically link it (I think you can do it in the Express Edition, but I personally can't guarantee it) by going to Project->Properties->Configuration Properties->C/C++->Code Generation and changing the "Runtime Library" to "Multi-threaded (/MT)". Programs which don't do this require the user to install the Redistributable Package from Microsoft, which contains the DLLs that your dynamically linked program requires.

Share this post


Link to post
Share on other sites
Quote:
Original post by MikeTacular
Probably because you are dynamically linking the runtime library (i.e. the Standard Library). You can statically link it (I think you can do it in the Express Edition, but I personally can't guarantee it) by going to Project->Properties->Configuration Properties->C/C++->Code Generation and changing the "Runtime Library" to "Multi-threaded (/MT)". Programs which don't do this require the user to install the Redistributable Package from Microsoft, which contains the DLLs that your dynamically linked program requires.

Although it probably won't (yet) affect the OP, it's still worth noting that statically linking to the CRT libs can create some really nasty bugs when working with DLLs. The static CRT is fine as long as you're working with very simple or small projects. But for anything larger, it's usually not a good idea.

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
Quote:
Original post by MikeTacular
Probably because you are dynamically linking the runtime library (i.e. the Standard Library). You can statically link it (I think you can do it in the Express Edition, but I personally can't guarantee it) by going to Project->Properties->Configuration Properties->C/C++->Code Generation and changing the "Runtime Library" to "Multi-threaded (/MT)". Programs which don't do this require the user to install the Redistributable Package from Microsoft, which contains the DLLs that your dynamically linked program requires.

Although it probably won't (yet) affect the OP, it's still worth noting that statically linking to the CRT libs can create some really nasty bugs when working with DLLs. The static CRT is fine as long as you're working with very simple or small projects. But for anything larger, it's usually not a good idea.


I was actually thinking about starting a thread asking why you would want to dynamically link the CRT. Can you elaborate on these bugs?

Share this post


Link to post
Share on other sites
Quote:
Original post by MikeTacular
I was actually thinking about starting a thread asking why you would want to dynamically link the CRT. Can you elaborate on these bugs?

The CRT libraries have static data areas they use to store control structures for resources allocated and serviced by the CRT: memory management (malloc/free and new/delete), file allocators (everything from FILE to std::fstream types), etc.

Now, suppose you have an application that uses two DLLs. Say you statically link the CRT with your application and the DLLs. What will happen is that your host app and the two DLLs will each instanciate local versions of the static CRT control data structures. Basically, there will be three entirely separate CRTs existing simultaneously, that know nothing about each other.

In practice that means that you cannot use a resource created by one of these isolated CRTs in another CRT, if such usage would access the CRT control structures. Otherwise, you will get anything from a crash, over heap corruption to totally weird and unpredictable effects. For example, you cannot open a file in one DLL, and read from/write to it from another DLL. You cannot allocate memory in one DLL and free it in another (or in your host application). And so on. It is very hard to ensure this, especially when using modern C++ containers and C++ interfaces between the DLLs. You don't always know what resources will access internal CRT control structures, and it can change from one CRT version to the next. Mistakes are subtle and very hard to avoid. The bugs generated by such small mistakes can be extremely challenging to track.

If you link with the dynamic CRT, only one single version of the static CRT data will ever be instanciated by your process - the one in the CRT DLL.

Oh, and your executable + DLLs will be considerably smaller too.

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
Oh, and your executable + DLLs will be considerably smaller too.


But then that is one more thing that the user can ignore to install. Though I guess you could just have the installer run the redist package in silent mode.

Share this post


Link to post
Share on other sites
If you want to talk across different binaries you should probably have a standardized interface in the first place. This way they can be implemented in any language and compiler instead of being forced to use MSVC. You shouldn't really share C++ classes at all IMO. It's really the problem COM tried to solve. I wouldn't say dynamic linking is the solution. All runtime libraries are versioned anyways (msvcr90.dll, msvcp90.dll, ...) since you can't really expect the classes to have the same binary layout across compiler version changes so you won't get a huge saving with just 1 DLL instance loaded. Statically linking it will likely mean that your application will need to load less code into memory as some things can be eliminated at link time. However the executable will get smaller with dynamic linking, usually a couple of 100 KB.

Share this post


Link to post
Share on other sites
Quote:
Original post by asp_
since you can't really expect the classes to have the same binary layout across compiler version changes so you won't get a huge saving with just 1 DLL instance loaded.

Consider a modern DLL and plugin heavy application such as 3DSMax. My current (relatively clean) 3DSMax 2009 installation consists of around 290 DLLs. This will significantly increase if you install third party plugins. I'll let you do the math, if every single one of these DLLs had a local copy of the CRT linked in...

And it's not just about memory savings. As I mentioned above, creating clean and modern OO interfaces with DLLs, that support inheritance, polymorphism and generic containers is extremely difficult, error prone and chaotic if you use static CRTs. It becomes trivial with dynamic linked CRTs. The choice shouldn't be too difficult, unless your application is so small that it doesn't use any external DLL.

Quote:
Original post by asp_
You shouldn't really share C++ classes at all IMO.

Of course you should. OOP interfaces are mostly relevant in the context of tightly coupled modules, such as plugins. Plugin modules will always be loaded by the application they were designed for. There is no reason to avoid elegant C++ interfaces and stay with primitive and unintuitive lists of hundreds of extern "C"-style functions in this day and age.

And you don't have to force the use of a single compiler either. All what is important, is that all binary modules for one platform are compiled using the same compiler. So compiling everything in MSVC or everything in gcc are both fine. It's only the attempt to mix compiled binaries that will fail. But this is mostly irrelevant anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
Now, suppose you have an application that uses two DLLs. Say you statically link the CRT with your application and the DLLs.

If you link with the dynamic CRT, only one single version of the static CRT data will ever be instanciated by your process - the one in the CRT DLL.


And what would happen when one library was compiled with expectation of CRT6, and another with expectation of CRT8.1?

The best idea is either disalow plugin architecture completly, or run the plug in in sandbox mode, and NEVER allow plugin to allocate, or free memory directly.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!