Problems running compiled .exe on other machines.

Hi C board,

I have a rather weird problem..

I have wrote this game in visual studio '08, and when i compile it, it runs perfect nothing there. It is a simple game with just one source file. The problems srufaces when I send the compiled .exe to anyone else who doesnt have visual studio '08 installed.

I've had another guy compile my source code also with visual studio '08 and that .exe runs fine on any machine.

So this get me thinking that there is proberly some compiler setting that I should change so it includes some .DLLs or something, but I dont know which or how for that matter.

Any help is appreciated, thanks.
-Troels Leth

If you build in release mode and set the linker option to "static linking", then there should be no need to distribute extra DLL's.

--
Mats

I disagree. Just have the other computer install the VS08 runtime and there's no need to install anything for any VS programs later ever (they will all run fine). Static linking will increase the size of the exe by a lot.

Download: http://www.mediafire.com/download.php?zcsjzncbmm1
Install. Never worry about not being able to run programs on the remote machine again.
Remember to compile as release. Debug compiles will not run without VS installed.

Quote:

---

Originally Posted by Elysia

I disagree. Just have the other computer install the VS08 runtime and there's no need to install anything for any VS programs later ever (they will all run fine). Static linking will increase the size of the exe by a lot.

---

What is contained in that runtime and could it possibly overwrite dlls that could break existing programs on the client machine?

I prefer one statically linked .exe. The business of distributing runtimes (whether it's VS, Java, Python, etc.) has to take versioning of said runtimes into account.

Not Visual Studio. I have never seen one broken program due to the runtime that I always install.
Several statically linked executables will in the end override the size of the runtime only installed once.
Static linking shouldn't exist IMHO.
And runtime vendors should be more careful as to put the version in the filename too, to avoid overwriting other dlls.

Quote:

---

Originally Posted by Elysia

I disagree. Just have the other computer install the VS08 runtime and there's no need to install anything for any VS programs later ever (they will all run fine). Static linking will increase the size of the exe by a lot.

Download: http://www.mediafire.com/download.php?zcsjzncbmm1
Install. Never worry about not being able to run programs on the remote machine again.
Remember to compile as release. Debug compiles will not run without VS installed.

---

I s'pose I have to disagree with your disagreement ;) User-friendly and update-friendly are far more valuable than saving a user who probably has at least several gigs to spare an extra few to a few hundred k.

Well yeah, but here is where the silent VS runtime installer comes in handy ;)
You can easily make a setup program to download and install the runtime automatically if it isn't installed already!

I really see no hassle at all. Download a setup program (very small). Installs the runtime if necessary. You're all set! Never more worry about that runtime. Download to your hearts contents!

That's what I call user friendly. Static linking increases size dramatically and in the end, it will end up costing several MB on the target computer!

I am not going to call you an evil developer if I ever have a client use software you have written that does all this, but I myself prefer to eliminate the potential for something unforeseen to go wrong. Obviously its impossible to know what is unforeseen ahead of time, however, I have noticed many patterns of security exploits and/or faulty updates coming from Microsoft. That said, and for once I am not just bashing Microsoft, I have found that any project that uses multiple DLL's introduces new potential possibilities for problems with each new DLL. I.e. MyNetScan.DLL v2.3 seems to dislike MyNetPing.DLL v6.4 even though on 20 of the machines tested the update went smooth, for some odd reason the one that missed one obscure update needed a dreaded reinstallation.

I guess at the end of the day it depends on the scope of the project as well as personal preference :)

Quote:

---

Originally Posted by master5001

...I have found that any project that uses multiple DLL's introduces new potential possibilities for problems with each new DLL. I.e. MyNetScan.DLL v2.3 seems to dislike MyNetPing.DLL v6.4 even though on 20 of the machines tested the update went smooth, for some odd reason the one that missed one obscure update needed a dreaded reinstallation.

---

Yeah, that's pretty much a problem, isn't it? :)
I always take note today to add the version of my dll to the filename to avoid potential problems!
That mentioned, Microsoft does rename their dlls for each version of the runtime for each VS version, and the feature pack or service pack, so far as I know, is backwards compatible, so installing the latest runtime for VS shouldn't hurt at all.

A problem that could so easily be remedied by MVFS. I think the argument is moot since I create all final builds using gcc anyway.

Quote:

---

Originally Posted by Elysia

I really see no hassle at all. Download a setup program (very small). Installs the runtime if necessary. You're all set! Never more worry about that runtime. Download to your hearts contents!

---

And if an older version exists, will the installer regression test all of their existing applications? If a newer version exists, are you sure *your* application works with it?

Quote:

---

Static linking increases size dramatically and in the end, it will end up costing several MB on the target computer!

---

In an age where drives are hundreds of GB, this is a non-issue.

Quote:

---

Originally Posted by medievalelks

And if an older version exists, will the installer regression test all of their existing applications? If a newer version exists, are you sure *your* application works with it?

---

If they don't share the same name, then yes.
Or if they do, and if they're backwards compatible, then yes.
I don't dare imagine Microsoft would break backwards compability for VS runtime seeing as it must be installed, unless the applications are statically linked. I would imagine a nightmare for support if all of a sudden, all applications would break.

Quote:

---

In an age where drives are hundreds of GB, this is a non-issue.

---

So you say, but there's also more factors to consider:
I know people who even today are stuck with small hard drives and old computers.
There are still many people who use dial up!
Bigger hard drives today is no excuse for code bloat IMO (which is exactly what static linking is - code bloat!).

Quote:

---

Originally Posted by Elysia

If they don't share the same name, then yes.
Or if they do, and if they're backwards compatible, then yes.
I don't dare imagine Microsoft would break backwards compability for VS runtime seeing as it must be installed, unless the applications are statically linked. I would imagine a nightmare for support if all of a sudden, all applications would break.


So you say, but there's also more factors to consider:
I know people who even today are stuck with small hard drives and old computers.
There are still many people who use dial up!
Bigger hard drives today is no excuse for code bloat IMO (which is exactly what static linking is - code bloat!).

---

If a user installs a new version of my statically linked program, they get a new .exe installed over the old one. In your case, they get a new DLL installed next to the old one.

Which installation is bloated?

Quote:

---

Originally Posted by medievalelks

If a user installs a new version of my statically linked program, they get a new .exe installed over the old one. In your case, they get a new DLL installed next to the old one.

Which installation is bloated?

---

No, that's the point - they don't.
Runtime is installed once - only if required.
Your static exe will keep adding unnecessary size each time you compile it.

Dynamic route:
1st time: Runtime (2 MB) + App (100 KB) = Total 2.1 MB
2nd time: App (100 KB) = Total 2.2 MB
3rd time: App (100 KB) = Total 2.3 MB
4th time: App (100 KB) = Total 2.4 MB
5th time: App (100 KB) = Total 2.5 MB
6th time: App (100 KB) = Total 2.6 MB
...
100th time: App (100) = 12 MB (100 * 0.1 + 2)

Static route:
1st time: App (500 KB) = Total 0.5 MB
2nd time: App (500 KB) = Total 1 MB
3rd time: App (500 KB) = Total 1.5 MB
4th time: App (500 KB) = Total 2 MB
5th time: App (500 KB) = Total 2.5 MB
6th time: App (500 KB) = Total 3 MB
...
100th time: App (500 KB) = Total 50 MB (0.5 * 100)

Of course, this is just a small program. The bigger it is, the bigger the static size. The static size will just grow exponentially from there.

i agree with Elysia, shared libs/dynamic libs save space.
i just wish they had a more sane (may be a standard) way of dealing with changes, that, may affect old and new applications, after that, they are a win-win solution!

Quote:

---

Originally Posted by Elysia

Of course, this is just a small program. The bigger it is, the bigger the static size. The static size will just grow exponentially from there.

---

Not necessarily true - you only static link what you need from the libraries. So if you expand your application to double the size, there's absolutely no reason why the static size should double - since the majority of the growth is (presumably) in the application code, rather than using more of the library code. This is of course not ALWAYS the case.

The other thing you misunderstood is the point medievalelks said:
If you have App V1.0 + DLL V1.0 = 0.1MB + 2MB, and you develop a second version, App V1.1 + DLL V1.1, then you still have DLL V1.0 on the system as well, taking up 2MB, even if you remove the App V1.0 [unless you also KNOW that no other application is using DLL 1.0 - in which case there is no benefit of using DLL's in the first place].

--
Mats

Hi again C board,

How do I set up visual studio '08 to static linking?
I've tried searching the help part, and looking through the linking option under projekt settings helped nothing.

Thanks in advance
Troels

Why does the static version grow?

as Mats put it, i will still support Elysia's point, but one caveat is there.
if the .dlls etc are used by only one (and only one) application, well, why was that made into a .dll?

Quote:

---

Originally Posted by manav

i agree with Elysia, shared libs/dynamic libs save space.
i just wish they had a more sane (may be a standard) way of dealing with changes, that, may affect old and new applications, after that, they are a win-win solution!

---

Yes, *shared* libs save space, statically linked .exe's save bugs and headaches. I gladly accept the space tradeoff.

Quote:

---

Originally Posted by matsp

Not necessarily true - you only static link what you need from the libraries. So if you expand your application to double the size, there's absolutely no reason why the static size should double - since the majority of the growth is (presumably) in the application code, rather than using more of the library code. This is of course not ALWAYS the case.

---

Yeah, I was hinting at that if your application grows, you will probably use more code inside the runtime, so in that case, the static size would grow. This is not always the case, but it's probably pretty reasonable to think that way.

Quote:

---

The other thing you misunderstood is the point medievalelks said:
If you have App V1.0 + DLL V1.0 = 0.1MB + 2MB, and you develop a second version, App V1.1 + DLL V1.1, then you still have DLL V1.0 on the system as well, taking up 2MB, even if you remove the App V1.0 [unless you also KNOW that no other application is using DLL 1.0 - in which case there is no benefit of using DLL's in the first place].

---

True, but you gain more the more application that uses them. If we'd talk about dlls, would it be better for 2 applications to use the same code or put it in a dll? This argument also goes back to my previous post. The more applications that shares the code, the more you save.

Quote:

---

Originally Posted by medievalelks

Why does the static version grow?

---

I was taking into account that the bigger your application was, the more features of the runtime you would use. Hence the bigger size.

Quote:

---

Originally Posted by manav

if the .dlls etc are used by only one (and only one) application, well, why was that made into a .dll?

---

There can be several reasons to that, I think...
For future share of the same code.
To ensure that you can deliver code to someone (or functionality) without giving them the source.
There are probably more.

Quote:

---

Originally Posted by medievalelks

Yes, *shared* libs save space, statically linked .exe's save bugs and headaches. I gladly accept the space tradeoff.

---

However, I do believe if done properly, there won't be any headaches and bugs. Especially if you separate versions or make them backwards compatible (ie, don't remove or tamper with existing functionality in the dll - derive new interfaces).

Quote:

---

Originally Posted by Elysia

Yeah, I was hinting at that if your application grows, you will probably use more code inside the runtime, so in that case, the static size would grow. This is not always the case, but it's probably pretty reasonable to think that way.

---

But...you've already installed the entire runtime, no?

Quote:

---

The more applications that shares the code, the more you save.

---

Sure, and the bigger the chance that you break something with a different version.

Quote:

---

To ensure that you can deliver code to someone (or functionality) without giving them the source.

---

You can do the same by distributing just an .exe.

Quote:

---

Originally Posted by medievalelks

Yes, *shared* libs save space, statically linked .exe's save bugs and headaches. I gladly accept the space tradeoff.

---

you are absolutely right about bugs & headaches!
i have to face them a lot, nightmares ~~~.',` *_* .`,';~~~

Quote:

---

Originally Posted by medievalelks

But...you've already installed the entire runtime, no?

---

But that's the static way. The more code (inside the runtime) you use, the more static size you add.
For dynamically linked apps, it doesn't matter. They will always remain the same size no matter how much code inside the runtime you use.

Quote:

---

Sure, and the bigger the chance that you break something with a different version.

---

There are always chances to break something. Just keep compability.

Quote:

---

You can do the same by distributing just an .exe.

---

I think you were missing the point. You want to distribute functionality to someone (you don't want to distribute an application!). But you don't want them to have the source. So what do you do if you can't distribute an .exe nor the source?

Quote:

---

Originally Posted by Elysia

There are always chances to break something. Just keep compability.

---

Which involves *lots* of extra testing on your part.

Quote:

---

I think you were missing the point. You want to distribute functionality to someone (you don't want to distribute an application!). But you don't want them to have the source. So what do you do if you can't distribute an .exe nor the source?

---

I'm not sure what your point is here. I'm an application developer, but I can't distribute an .exe because...?

What if someone just want to deliver some code or functionality to someone else (implementation, not some application - like the STL)?
I wasn't hinting at YOU exactly, I was explaining the use of a dll, even if only one application would use it.

You could deliver a shared library or a static library. Anyway, I see your point on some of these issues. There are tradeoffs to either solution, and we just value them differently.

Although, I am not familiar to any of those solutions. But it's as you say, there are advantages and disadvantages to everything.

Elysia, are you familiar with the term DLL hell?

Heard of it, yes, but lost much knowledge over time.
I also never truly ran into the problem myself but was aware it existed.

At the end of the day we may be talking about a small percentage of file growth here. As far as DLL hell goes, that was somewhat my initial point to an extent, but a lot of the DLL quandaries have to do more with design more than anything. A few poorly designed COM libraries combined with two interdependent DLL's can easily lead to DLL hell.

I'd say it's a pretty huge growth. But it does avoid dll hell. However, VS's runtime also avoids dll hell because it uses side-to-side configuration. So there you have it - the runtime is safe.
Your own dlls is another matter, though, sadly.

I assure you that you are perfectly capable of avoiding DLL by doing the following:

- If your program has dependencies, check them.
- If you can avoid using COM objects that need registering, do so.
- If you do any sort of update whatsoever, always unregister, then reregister COMs.
- Simply putting a get_version() or similar function in the library, and checking its return.

I would put avoid using .NET framework in the list, but seeing as that it will surely result in flaming, I won't. Really the main thing is the last point on my list. Naming them is a great idea, right? Wrong! Believe it or not, the above average user will think they can get rid of those nasty start-up errors by simply renaming the DLL to match whatever your program argues is "missing." Users are unpredictable. Never forget that.

I'm no fan of .NET either, but I'd rather use ways around the DLL hell than avoiding dlls. It's 2008 for dll's sake! There should be no more dll hell today, especially not if proper method to avoid it is used.
But now this is turning into a static vs dll topic :|
I think the pros and cons of both ways have been discussed already. For Visual Studio, it's safe to distribute runtime and use dynamic linking. This cannot be assured for other compilers / other dlls.

Quote:

---

Originally Posted by master5001

Naming them is a great idea, right? Wrong! Believe it or not, the above average user will think they can get rid of those nasty start-up errors by simply renaming the DLL to match whatever your program argues is "missing." Users are unpredictable. Never forget that.

---

absolutely right 5001 :D
i have done exactly that, many times, but can not remember how many times i could get it to work correctly.

i like one thing about .dlls that, if found in the same folder as .exe, then, the program runs just fine.

Quote:

---

Originally Posted by manav

i like one thing about .dlls that, if found in the same folder as .exe, then, the program runs just fine.

---

Not always. Read up on the dll hell link. Dlls are shared, even if they are apart. It still doesn't eliminate one dll hell situation.

it is literally dll-hell!!
i just hope that situation is improved now :(

now i figure why those silly errors would come up:
i had a program that would use some common msvc .dlls, but, i would put the needed dll with the program installer, that would put them in the same folder as the program. But. when the installer was run to uninstall my program, then, some times, it would report error (installer), saying that, one or more apps need to be closed, before uninstall could continue.

Well the upshot of Elysia's DLL method is that the user may already have that particulare DLL installed already. If not, you are doing some other program a favor by adding it to the user's system.

There are several ways to link the DLL, but that is a topic for another thread (since even though I am usually always up for writing long winded code for the sake of education, even I get tired at times). The msvc DLL's should be shipped with your program and installed into the system32 directory. You should first dynamically link to the existing DLL (which will additionally tell you if it doesn't even exist) and make sure you aren't overwriting their newer build with your older one.

If your code is likely not to be able to cope with a newer msvc DLL (which would be extremely unlikely) then you should keep your version of the DLL in your own directory. If you do this method there should be no complaints come deleting time.

Quote:

---

Originally Posted by master5001

If your code is likely not to be able to cope with a newer msvc DLL (which would be extremely unlikely)

---

Depends on how old the stomped applications are. My client's machines run applications -- written ten years ago with VC++ -- that won't even compile with Visual Studio 2005. Can't imagine if they were all dynamically linked and we plopped a new runtime on them.

These servers also run Java software that depends on Java 1.4.0. An axis library that one app uses breaks when you upgrade to 1.5 because the exception semantics of a library function changes, so we can't upgrade the VM (i.e. the runtime) for one application without break a seemingly unrelated application.

Sharing runtimes is a nice idea on paper, but when you have multiple applications whose lifetime spans several versions of said runtime, it can create huge problems if you try to upgrade.

Newer versions of VS runtime will not run older versions of VS applications.
Plus VS6 or earlier already has appropriate DLLs installed with XP (as it ships with them).