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; At the end of the day we may be talking about a small percentage of file growth here. As far ...

  1. #31
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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.

  2. #32
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,546
    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.
    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.

  3. #33
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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.

  4. #34
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,546
    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 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.

  5. #35
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by master5001 View Post
    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
    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.

  6. #36
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,546
    Quote Originally Posted by manav View Post
    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.
    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. #37
    Banned
    Join Date
    Nov 2007
    Posts
    678
    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.

  8. #38
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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.

  9. #39
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by master5001 View Post
    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.
    Last edited by medievalelks; 05-09-2008 at 05:33 AM.

  10. #40
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,546
    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).
    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 3 of 3 FirstFirst 123
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