Running the application (.exe) files on other PCs

This is a discussion on Running the application (.exe) files on other PCs within the Windows Programming forums, part of the Platform Specific Boards category; After compile-run at least once an exe file is created in the debug folder.. Copying this file to a different ...

  1. #1
    Registered User
    Join Date
    Apr 2008
    Posts
    610

    Running the application (.exe) files on other PCs

    After compile-run at least once an exe file is created in the debug folder.. Copying this file to a different PC won't execute, any reason for this?

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Yes, the reason is that the debug C runtime library is not distributed (and I believe it's not even legal to distribute, but I'm not even 75% sure of that). When distributing your code, you should do so with a release build, not a debug build. You may still need to have certain DLL's installed on the other machine or link statically (so it is not relying on DLL's).

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

  3. #3
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by matsp View Post
    Yes, the reason is that the debug C runtime library is not distributed (and I believe it's not even legal to distribute, but I'm not even 75% sure of that). When distributing your code, you should do so with a release build, not a debug build. You may still need to have certain DLL's installed on the other machine or link statically (so it is not relying on DLL's).

    --
    Mats
    Went to Build>Configuration Manager>Active Solution Configuration and changed it from debug to release... Compiles-Run but output showed blocks instead of ':' & '.', and some letters... Noticed the release folder is created but no exe file

  4. #4
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    The "blocks" problem may be due to your source (bad code).
    And if the compile suceeds, the EXE will generally be in your_project_dir\Release folder, but can be changed. If you go into project settings, look at the output directory. That's where your executable likely will end up.
    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. #5
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by Elysia View Post
    The "blocks" problem may be due to your source (bad code).
    This happens only when i change from debug to release... Compiling on this mode gives this warning
    Code:
    ofn.lpstrFilter = "Binary Files (*.dat)\0*.dat\0All Files (*.*)\0*.*\0";
    // Warning 1
    '=' : incompatible types - from 'char [48]' to 'LPCWSTR'
    
    char szFileName[] = "blah blah";
    WriteToFile(hwnd, szFileName);
    // Warning 2
    incompatible types - from 'char [260]' to 'LPCTSTR'
    
    // WriteToFile(...., LPCTSTR fname);
    This could be part of the problem in displaying blocks rather than proper characters... In my settings, i use Multi-code...

  6. #6
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by csonx_p View Post
    This happens only when i change from debug to release... Compiling on this mode gives this warning
    Code:
    ofn.lpstrFilter = "Binary Files (*.dat)\0*.dat\0All Files (*.*)\0*.*\0";
    // Warning 1
    '=' : incompatible types - from 'char [48]' to 'LPCWSTR'
    
    char szFileName[] = "blah blah";
    WriteToFile(hwnd, szFileName);
    // Warning 2
    incompatible types - from 'char [260]' to 'LPCTSTR'
    
    // WriteToFile(...., LPCTSTR fname);
    This could be part of the problem in displaying blocks rather than proper characters... In my settings, i use Multi-code...
    Picked up the problem, when i change from debug to release, all my current project settings are reset... So i had to change again to Multi-code and also define deprecated code (or whatever than means) as this was also removed... Not sure why's that!

  7. #7
    Technical Lead QuantumPete's Avatar
    Join Date
    Aug 2007
    Location
    London, UK
    Posts
    894
    Debug and Release are two different kinds of build. Specifically so that you can for example use macros and asserts in while you're writing code, but automatically remove them when you build the release version.
    I once saw a project where they had their own version of malloc linked into the Debug version to spot memory problems. When they switched to the Release version all the debug trace was removed at the flip of a switch.

    QuantumPete
    "No-one else has reported this problem, you're either crazy or a liar" - Dogbert Technical Support
    "Have you tried turning it off and on again?" - The IT Crowd

  8. #8
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by QuantumPete View Post
    Debug and Release are two different kinds of build. Specifically so that you can for example use macros and asserts in while you're writing code, but automatically remove them when you build the release version.
    I once saw a project where they had their own version of malloc linked into the Debug version to spot memory problems. When they switched to the Release version all the debug trace was removed at the flip of a switch.

    QuantumPete
    I tried using release in order to distribute my application to other PCs... Both the debug & release .exe files would not run... Anything i need to install on other PCs?

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    It will (normally) tell you which DLL's are missing, so that's what you need to install.

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

  10. #10
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by matsp View Post
    It will (normally) tell you which DLL's are missing, so that's what you need to install.

    --
    Mats
    works now, thnx

  11. #11
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    Quote Originally Posted by csonx_p View Post
    This happens only when i change from debug to release... Compiling on this mode gives this warning
    Code:
    ofn.lpstrFilter = "Binary Files (*.dat)\0*.dat\0All Files (*.*)\0*.*\0";
    // Warning 1
    '=' : incompatible types - from 'char [48]' to 'LPCWSTR'
    
    char szFileName[] = "blah blah";
    WriteToFile(hwnd, szFileName);
    // Warning 2
    incompatible types - from 'char [260]' to 'LPCTSTR'
    
    // WriteToFile(...., LPCTSTR fname);
    This could be part of the problem in displaying blocks rather than proper characters... In my settings, i use Multi-code...
    This means:
    "Cannot convert from char to wchar_t"
    Or in other words - cannot convert from multi-byte (char) to unicode (wchar_t).
    You should remember that. It's a common error.
    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. #12
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Anything after MSVC 2003 will NOT tell you which DLLs it cannot find. It will say the program failed to run because the application configuration was incorrect. The admin logs will tell you it's a side-by-side assembly error. Simply put - the code is attempting to use functions in a DLL but the DLL cannot be found or the code links to the wrong version of the DLL. Usually wrong versions will result in an error something like 'The value of ESP was not preserved across a function call.'

    The only ways I've found to take any code compiled from MSVC 2005 + to another system and run it is to either completely rebuild it or create a setup and deployment project that creates a setup program so it can be installed on other computers. I've tried other ways and usually it takes 30 min to 1 hour to get the code to finally run correctly. Just ran into this today as a matter of fact.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Application in Nt Native Api
    By sousasamir in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 01-30-2009, 05:41 PM
  2. Replies: 13
    Last Post: 12-09-2008, 10:09 AM
  3. icons for compiled .exe files
    By inonusin in forum C Programming
    Replies: 6
    Last Post: 04-06-2002, 06:55 PM
  4. Problem creating .exe files
    By Unregistered in forum C Programming
    Replies: 1
    Last Post: 03-22-2002, 01:25 PM
  5. Win application not very portable
    By swed in forum Windows Programming
    Replies: 5
    Last Post: 10-01-2001, 11:17 AM

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