Sign in to follow this  
smallGame

exe from Vista to Xp?

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
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
Quote:
Original post by Raghar
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.

Nope. The best idea is to make sure all plugins are linked with the same CRT. That's how all modern C++ based plugin systems work. Some do in fact wrap allocators (usually through global new/delete operators). But this is not so much to avoid the CRT problem (which doesn't exist if dynamically linking with the CRT), but more to be able to manage allocations internally through a custom allocator.

Share this post


Link to post
Share on other sites
Well it's not like a programer always have the choice. Companies could disappear, and recompilation of theirs plugins is impossible. Users could create theirs own plugins, and then...

Share this post


Link to post
Share on other sites
Quote:
Original post by Raghar
Well it's not like a programer always have the choice. Companies could disappear, and recompilation of theirs plugins is impossible. Users could create theirs own plugins, and then...

And ? All major plugin based applications require a certain compiler to engineer their plugins. It's part of the SDKs system requirements. As long as everybody adheres to these requirements, everything will work out just fine. Of course, there won't be binary compatibility between an old plugin and a new version of your application/game. But since the slightest modification to your plugin interface in itself will require a recompile anyway, it doesn't make any difference at all.

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
All major plugin based applications require a certain compiler to engineer their plugins. It's part of the SDKs system requirements. As long as everybody adheres to these requirements, everything will work out just fine. Of course, there won't be binary compatibility between an old plugin and a new version of your application/game. But since the slightest modification to your plugin interface in itself will require a recompile anyway, it doesn't make any difference at all.


That's not nessecarily true. For example, Firefox doesn't require a particular compiler/version for their plugins, and in fact all plugins are binary compatible for a given major release (i.e. 2.x, 3.x etc). That's because Firefox uses XPCOM as it's plugin-interface.

Windows explorer extensions are the same, too. Explorer uses COM for it's plugin architecture and so it doesn't require a particular compiler/version either (as long as the compiler you chose can compile COM components).

It depends on the host application. For a game, it's OK to require a particular compiler/version because a game doesn't last especially long on the market (not compared to Windows Explorer, for example). Also, with a game the host application itself doesn't typically get updated all that much. It was quite a pain when Firefox 3.x was first released and we had to wait for all the add-ons to get recompiled for them to work -- imagine if they broke with each minor release as well!

In my personal opinion, a component-based plugin architecture makes more sense than a OO-one anyway (i.e. implementing an interface rather than inheriting from a base class). You can provide a "default" implementation of the interface for your plugin authors to base their work, but I think that would be optional...

Share this post


Link to post
Share on other sites
COM and its various ripoffs are things apart. They surely are an alternative to standard OO inheritance interfaces. Some people like them, others hate them. I'm part of the latter group, but YMMV of course. And FF certainly isn't the best example, if you consider the really bad compatibility problems they have from one version to the next...

Maybe I wasn't clear enough about my points being more about highly closed commercial systems that operate in a strictly controlled development environment, which I am a very strong proponent of. From personal experience, I grew really sick of the constant compatibility problems you run into when trying to make different compilers cooperate on large projects ("Your SDK doesn't work with my gcc 4.3.5 beta nightly build 8765 ! Why ?!"). You want to write plugins for my software ? Well, you'll use MSVC 2008, and period. This made development much easier and more consistent.

Games usually fit very well into the above category, as well as applications such as AutoCAD, 3DS Max, Photoshop, etc. Essentially, you (the developer) decide what kind of dev tools your plugin writers will have to use. This has a lot of advantages, especially when it comes to quality control, consistency, support and developer licensing / DRM. It also offers easy and clean ways to extend functionality through natural OO constructs, usually without major restrictions in complex data types you can throw around your modules (STL and Boost types come to mind). While you can do similar things with COM type interfaces, it can be much harder to achieve. And it's not as flexible, at least in my opinion.

Of course this means that you force a certain language (C++ in this case) on your plugin writers. Whether that is a disadvantage or not depends on your particular situation.

In the end, it's mostly individual preference.

Oh, and using a closed system as described above usually helps to keep the open source hippies out, which I find an invaluable advantage [wink]

Share this post


Link to post
Share on other sites
Right, as I said it depends on the host application. I was just trying to counter the "all major plugin based applications" comment since obviously Firefox and Explorer are two notable plugin-based applications which don't require a particular compiler/version.

In any case, this is getting somewhat off-topic now, but I certainly agree with you that requiring the same compiler and CRT (and dynamically linking to it) make life a lot easier on a number of fronts...

Share this post


Link to post
Share on other sites
Quote:
Original post by Codeka
In any case, this is getting somewhat off-topic now, but I certainly agree with you that requiring the same compiler and CRT (and dynamically linking to it) make life a lot easier on a number of fronts...


Especially since the thread starter seems to be a hobbyist. I think both arguments apply to certain products that are used over the world and extended by alot of developers.
But when it comes to non-professional programs, I would really suggest dynamically linking to the runtime library, it's easier to work with the dynamic version...

Share this post


Link to post
Share on other sites
Hi,

Sorry for late reply,

I understand more things; thanks to your replies but I still can't resolve my problem, I am using my own DLL this one is linked to glaux.lib
And my main is using WS2_32.Lib and myOwnLib.lib.

My DLL and my main are compiled with /MD.

So I copy glaux.dll, ws_32.dll and myOwnLib.dll with my.exe, and I get still the same problem on few computer, on an other one is woking just with myOwnLib.dll.


Any help will be appreciated.

NB: I observed how Yann L said I have a crash on runtime with /MT when I process a new.

Share this post


Link to post
Share on other sites
Install NET Framework, the same You have in Vista.
It helped for me.
Anyway...
Anybody knows why using ws2_32.dll requires NET Framework?
I thought it is windows system library. ???

Share this post


Link to post
Share on other sites
99% of the time you may still at the very least need access to the MSVCR90.DLL
to link to MSVCR90.LIB with /MD. yes/no?: go to link provided below for your answer and more info.

The solution may lie back at the original question and very first response from
from SiCane:
"Did you install the MSVC 2008 redistributable on the computer? Did you make sure to use a release build?"

(1) A quick at dirty version of this has always been to copy the MS redist dlls to your exe's folder. In our .Net days it is as easy: copy the Microsoft.VC90.CRT folder into the same folder(s) where you app .exe and/or dlls(e.g. for plugins and anything else that needs it?) reside. [to ensure MSVCR90.DLL is available at runtime]

It has always worked for me (with either /MD or /MT since both MSVCR90.DLL and MSVCM90.DLL [respectively] are in the Microsoft.VC90.CRT folder).

If you need to be a miser (re /MD) you may only need MSVCM90.DLL?

you will find all the MS redist files you could need typically in redist/x86:

e.g. at: C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86

So, you could try (1), and then look at 'Better' strategies.

You should know that it's always good to actually check which files your app would actually need (you may still need more). See:

http://msdn.microsoft.com/en-us/library/8kche8ah.aspx

And then for a better strategy, decide for yourself on one, by reading the docs related (sort of) to the link above (RE: Deployment).

anyhow, in the meantime you could try (1) above and let us know?

Oh, yes ps:
RE: Install NET Framework, the same You have in Vista.
I consider this a mandatory step one: It must be installed (At least the version your app targets) on the pc using you app!

[Edited by - steven katic on December 18, 2008 7:26:05 PM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this