can't excute on other computer

i compiled a program with VS2008, the exe is working like it should on my computer, but i tested it on 3 other computers, and i got this error :

http://www.pictures-upload.com/up/4d07u6b02009820161912od00ljr2.bmp

"this application couldnt start cuz config of the application is not correct. reinstalling the application may solve this problem".

i don't think it's a problem with .net framework.(two of the computers have 3.5)..
so anyone can think of a possible reason of the error? what should i do i'm stuck.

thx.
You need to install this in any computer that will run the program: http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

It's also possible to distribute only the DLLs, but I haven't quite figured out how to do it.
Last edited on
Why do microsoft do it like this?
It reduces executable sizes. This is actually very common, and even GCC does it like this.
is there a way not to use it? i don't know, what about using c++ 2005 express? instead of 2008?? would it work??


Edit : i got it installed but still with the same error. thx for the reply though.
Last edited on
any other idea?? thx^^
Nope. No other way.
Unless you're willing to compile with MinGW, which statically links everything.
Edit : i got it installed but still with the same error. thx for the reply though.

some one told me to go to properties, configuration, c/c++, code generation and set runtime librarby to (/MT). but this brough me hell alot of errors, i can't even compile.
You can choose the Runtime Library type under Compiler settings in Visual Studio.
i just translated the hole thing to delphi. starting to feel VS sucks. thx guys for your replys.
Firstly, you should've googled your error. It's very easy to fix by packaging a couple of files with your app:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/36971526-95f3-4a9f-a601-1843c86332c1

Secondly, AFAIK this should only be an issue when your compiling it as a .NET application. As a native (sorry I don't know MS term) application it shouldn't matter.

It reduces executable sizes. This is actually very common, and even GCC does it like this.

This is misleading. You should explain what is happening as to give context. The problem is that his application is being compiled with shared linking to external libraries. This means the libraries are not part of the application and are looked for when the application executes.

The alternative is to link against static libraries. Which can be done on any compiler. So this isn't a Microsoft "issue" at all.

Nope. No other way.
Unless you're willing to compile with MinGW, which statically links everything.

A load of shit. You'll need to change what your linking against to a static version, MinGW does NO link everything statically, that is the same as MSVC++ in that it depends on the actual library your linking against.

i just translated the hole thing to delphi. starting to feel VS sucks. thx guys for your replys.

Something doesn't "suck" because of your lack of knowledge about the development techniques required to get it to work. Delphi is exactly the same, the only difference is that by default Delphi IDE links against static libraries instead of shared ones. This makes it a bit easier for people who don't understand external linking, but it doesn't remove/overcome the situation.
This is misleading. You should explain what is happening as to give context. The problem is that his application is being compiled with shared linking to external libraries. This means the libraries are not part of the application and are looked for when the application executes.
How is that misleading? It's true. Linking dynamically reduces the size of the executable. Or am I missing something?

A load of shit. You'll need to change what your linking against to a static version, MinGW does NO link everything statically, that is the same as MSVC++ in that it depends on the actual library your linking against.
Well, excuuuuse me for having forgotten that it's possible to link the VC++ runtime statically. Geez.
And what exactly does MinGW not link statically (excluding third party libraries, obviously)? I've never had to drag around DLLs with a MinGW executable.
Do I see a programming feud erupting between helios and Zaita? I think you two should have a competition where you both create the most complex program you can and see which is better.
Err... Given the time and resources, I think Helios would be up to making an operating system, get ready to wait a little while.
Zaita I don't know about you, having never conversed.
closed account (z05DSL3A)
Do I see a programming feud erupting between helios and Zaita?


nought new there. ;0)

welcome back Zaita.
How is that misleading? It's true. Linking dynamically reduces the size of the executable. Or am I missing something?


It's misleading in that you didn't give any context with your answer outside of "it reduces the size of the executable". You could've taken the time to actually explain what was happening with shared vs static linking; as this is an issue in many programming languages. Especially when working with 3rd party libraries.

Well, excuuuuse me for having forgotten that it's possible to link the VC++ runtime statically. Geez. And what exactly does MinGW not link statically (excluding third party libraries, obviously)? I've never had to drag around DLLs with a MinGW executable.


VC++ links std runtime libs statically, in the same was as MingW. But the .NET stuff is 3rd party, and likely dynamic in much the same way as any 3rd party library can be with any compiler.

As I said initially, a simple google of the error (like most errors) provides an easy solution.

Do I see a programming feud erupting between helios and Zaita?

I am just trying to bring some more context to the original problem, more than a quick solution but an actual explanation so the OP can understand the cause and avoid it in the future.

I think you two should have a competition where you both create the most complex program you can and see which is better.

Competitions are for students and people still learning C++. You don't have a lot of motivation to code for sport when you spend all day working with the stuff. Also, I see no need in proving my ability to this (or any forum). People can take my answers as they wish and if they feel the need for a second opinion by all means ask another poster. C++ and software devlepment is an extremely vast and complex field. There are many ways to skin the same cat.

welcome back Zaita.

Thanks man! Been a bit busy with work and Scuba diving courses, so have kinda dropped off the radar. Hopefully will post some more. Also been doing some more hands-off development lately with a client, so most of my time spent in the trenches has been advising on proper develoment and quality techniques to meet FDA guidelines.




Last edited on
It's misleading in that you didn't give any context with your answer outside of "it reduces the size of the executable". You could've taken the time to actually explain what was happening with shared vs static linking; as this is an issue in many programming languages. Especially when working with 3rd party libraries.
That doesn't make the answer misleading. It makes it incomplete.
I could have explained all that, but I didn't feel it was necessary. Simple answers for simple questions.

VC++ links std runtime libs statically
Not necessarily. Otherwise, OP wouldn't have this problem.

But the .NET stuff is 3rd party, and likely dynamic in much the same way as any 3rd party library can be with any compiler.
A third party library is a library provided by someone other than the compiler vendor or the user.
The .NET runtime is dynamic in the same way an interpreter is dynamic. In other words, yes, it's dynamic, but in the case of .NET it's not really relevant, since it isn't a native language.
Topic archived. No new replies allowed.