Problems running compiled .exe on other machines.

This is a discussion on Problems running compiled .exe on other machines. within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by Elysia Of course, this is just a small program. The bigger it is, the bigger the static ...

  1. #16
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  2. #17
    Registered User
    Join Date
    May 2008
    Posts
    2
    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

  3. #18
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Why does the static version grow?

  4. #19
    Banned
    Join Date
    Nov 2007
    Posts
    678
    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?

  5. #20
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by manav View Post
    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.

  6. #21
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,455
    Quote Originally Posted by matsp View Post
    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.

    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 View Post
    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 View Post
    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 View Post
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #22
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by Elysia View Post
    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?

    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.

    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.

  8. #23
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by medievalelks View Post
    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 ~~~.',` *_* .`,';~~~

  9. #24
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,455
    Quote Originally Posted by medievalelks View Post
    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.

    Sure, and the bigger the chance that you break something with a different version.
    There are always chances to break something. Just keep compability.

    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #25
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by Elysia View Post
    There are always chances to break something. Just keep compability.
    Which involves *lots* of extra testing on your part.

    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...?

  11. #26
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,455
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #27
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    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.
    Last edited by medievalelks; 05-08-2008 at 06:55 AM.

  13. #28
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,455
    Although, I am not familiar to any of those solutions. But it's as you say, there are advantages and disadvantages to everything.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #29
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,638
    Elysia, are you familiar with the term DLL hell?

  15. #30
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,455
    Heard of it, yes, but lost much knowledge over time.
    I also never truly ran into the problem myself but was aware it existed.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Switching Machines .... creating problems
    By SkinneyEd in forum C++ Programming
    Replies: 1
    Last Post: 10-12-2005, 02:37 PM
  2. Some Socket Problems...?
    By Tal0n in forum Linux Programming
    Replies: 1
    Last Post: 04-01-2004, 04:31 AM
  3. .exe problems
    By ZakkWylde969 in forum C Programming
    Replies: 7
    Last Post: 06-17-2003, 06:09 PM
  4. Help- Problems running outside of compiler
    By Derek5272 in forum C++ Programming
    Replies: 17
    Last Post: 05-07-2003, 08:19 AM
  5. Running Into Two Problems...Help Needed
    By Halo in forum C Programming
    Replies: 5
    Last Post: 04-18-2002, 08:14 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21