Problems running compiled .exe on other machines.

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.