How to compile .exe without trash ?
-
When I compile any of mine projects with MS Visual C++ 6.0 there is alot of trash inside .exe file. Its looking like debug information although I'm building a release version (there are lots paths and filenames inside executable clearly viewable). How to remove it all, to reduce .exe size ? Why is it there ?
-
When I compile any of mine projects with MS Visual C++ 6.0 there is alot of trash inside .exe file. Its looking like debug information although I'm building a release version (there are lots paths and filenames inside executable clearly viewable). How to remove it all, to reduce .exe size ? Why is it there ?
Exactly how are you viewing the .exe? with a hex viewer? I know that you can still usually find strings in most .exe's using the Win32 disassembler, (I think that's how some people find a message like "you have entered an invalid code" and use a hex viewer to change the 'jmp' statement to a 'nop'... or so I hear :suss: ). If I write code in my sleep, does that make me brilliant, or just a lazy programmer? My articles www.stillwaterexpress.com BlackDice
-
Exactly how are you viewing the .exe? with a hex viewer? I know that you can still usually find strings in most .exe's using the Win32 disassembler, (I think that's how some people find a message like "you have entered an invalid code" and use a hex viewer to change the 'jmp' statement to a 'nop'... or so I hear :suss: ). If I write code in my sleep, does that make me brilliant, or just a lazy programmer? My articles www.stillwaterexpress.com BlackDice
Yup I view it with hexviewer, but i bet it is visible with notepad too :) Yea you can crack programs by hexviewers, but disassemblers / hexview+dissaembler (like HIEW or DN) are better, trust me. But anyhow, question is how to compile without the trash ? Now anyone can see my developement directories, and it grows my .exe too much. Is there some compiler switch or something ?
-
Yup I view it with hexviewer, but i bet it is visible with notepad too :) Yea you can crack programs by hexviewers, but disassemblers / hexview+dissaembler (like HIEW or DN) are better, trust me. But anyhow, question is how to compile without the trash ? Now anyone can see my developement directories, and it grows my .exe too much. Is there some compiler switch or something ?
Yes, you need to disable the inclusion of the information for the PDB files. Go to the Project menu and select settings. A tabbed dialog called 'Project Settings' appears. Make sure, on the left, the 'settings for' is set to something like "Win32 Release". Go to tab marked 'Link'. In 'Category' drop list box select 'Debug'. Under 'Debug Info' group, make sure the 'Debug Info' check box is NOT checked. Go to the 'C/C++' tab. In 'Category' drop list box select 'Preprocessor'. In the edit field 'Preprocessor definitions' make sure you see NDEBUG. If it is missing, then add it to end of list of other options. If you see DEBUG or _DEBUG in the list of items, then remove it. That should help.
-
Yes, you need to disable the inclusion of the information for the PDB files. Go to the Project menu and select settings. A tabbed dialog called 'Project Settings' appears. Make sure, on the left, the 'settings for' is set to something like "Win32 Release". Go to tab marked 'Link'. In 'Category' drop list box select 'Debug'. Under 'Debug Info' group, make sure the 'Debug Info' check box is NOT checked. Go to the 'C/C++' tab. In 'Category' drop list box select 'Preprocessor'. In the edit field 'Preprocessor definitions' make sure you see NDEBUG. If it is missing, then add it to end of list of other options. If you see DEBUG or _DEBUG in the list of items, then remove it. That should help.
-
Thank you, but actually it didnt, because all those things were like that from the start, those are default Release settings. :(
I forgot to mention one more that might be different. On the Project Settings : C/C++ with the drop down list box set to "General" There is a 'debug info' drop down list box and that should be set to 'None'. Since you said that it seems all the file paths are in your EXE, maybe this is set to 'Program Database' for your project. I can't really think of another reason all the source paths are in your EXE unless someone has put something like static char s_FilePath[] = __FILE__; in all of your source files, which would automatically cause them all to be included.
-
I forgot to mention one more that might be different. On the Project Settings : C/C++ with the drop down list box set to "General" There is a 'debug info' drop down list box and that should be set to 'None'. Since you said that it seems all the file paths are in your EXE, maybe this is set to 'Program Database' for your project. I can't really think of another reason all the source paths are in your EXE unless someone has put something like static char s_FilePath[] = __FILE__; in all of your source files, which would automatically cause them all to be included.
-
Yup 'debug info' was set to 'none' Of course im not using "static char s_FilePath[] = __FILE__;" that would be pretty dumb :) why would I need absolute path to my project in the proggy :) generally absolute paths are bad thing. Uh oh then ...
Take most C++ files generated by MFC AppWizards and you will find code similar to this at top of every source file... #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif So.... Why would you want to do that? These are the only reasons I could locate... #define TRACE ::AfxTrace #define THIS_FILE __FILE__ #define ASSERT(f) \ do \ { \ if (!(f) && AfxAssertFailedLine(THIS_FILE, __LINE__)) \ AfxDebugBreak(); \ } while (0) \ #define VERIFY(f) ASSERT(f) #define ASSERT_VALID(pOb) (::AfxAssertValidObject(pOb, THIS_FILE, __LINE__)) #define DEBUG_ONLY(f) (f) // Memory tracking allocation void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine); #define DEBUG_NEW new(THIS_FILE, __LINE__) #if _MSC_VER >= 1200 void AFX_CDECL operator delete(void* p, LPCSTR lpszFileName, int nLine); #endif #ifdef _DEBUG #define DAO_CHECK(f) AfxDaoCheck(f, #f, THIS_FILE, __LINE__) #define DAO_CHECK_ERROR(f, err) AfxDaoCheck(f, #f, THIS_FILE, __LINE__, err) #define DAO_CHECK_MEM(f) AfxDaoCheck(f, #f, THIS_FILE, __LINE__, \ NO_AFX_DAO_ERROR, TRUE) #define DAO_TRACE(f) AfxDaoTrace(f, #f, THIS_FILE, __LINE__) #else #define DAO_CHECK(f) AfxDaoCheck(f, NULL, NULL, 0) #define DAO_CHECK_ERROR(f, err) AfxDaoCheck(f, NULL, NULL, 0, err) #define DAO_CHECK_MEM(f) AfxDaoCheck(f, NULL, NULL, 0, \ NO_AFX_DAO_ERROR, TRUE) #define DAO_TRACE(f) f #endif Anyways, I mentioned it in case you had included a macro in some header file that had something similar to a statement such as that, so your full file path was ending up as a static variable in every source file.
-
Take most C++ files generated by MFC AppWizards and you will find code similar to this at top of every source file... #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif So.... Why would you want to do that? These are the only reasons I could locate... #define TRACE ::AfxTrace #define THIS_FILE __FILE__ #define ASSERT(f) \ do \ { \ if (!(f) && AfxAssertFailedLine(THIS_FILE, __LINE__)) \ AfxDebugBreak(); \ } while (0) \ #define VERIFY(f) ASSERT(f) #define ASSERT_VALID(pOb) (::AfxAssertValidObject(pOb, THIS_FILE, __LINE__)) #define DEBUG_ONLY(f) (f) // Memory tracking allocation void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine); #define DEBUG_NEW new(THIS_FILE, __LINE__) #if _MSC_VER >= 1200 void AFX_CDECL operator delete(void* p, LPCSTR lpszFileName, int nLine); #endif #ifdef _DEBUG #define DAO_CHECK(f) AfxDaoCheck(f, #f, THIS_FILE, __LINE__) #define DAO_CHECK_ERROR(f, err) AfxDaoCheck(f, #f, THIS_FILE, __LINE__, err) #define DAO_CHECK_MEM(f) AfxDaoCheck(f, #f, THIS_FILE, __LINE__, \ NO_AFX_DAO_ERROR, TRUE) #define DAO_TRACE(f) AfxDaoTrace(f, #f, THIS_FILE, __LINE__) #else #define DAO_CHECK(f) AfxDaoCheck(f, NULL, NULL, 0) #define DAO_CHECK_ERROR(f, err) AfxDaoCheck(f, NULL, NULL, 0, err) #define DAO_CHECK_MEM(f) AfxDaoCheck(f, NULL, NULL, 0, \ NO_AFX_DAO_ERROR, TRUE) #define DAO_TRACE(f) f #endif Anyways, I mentioned it in case you had included a macro in some header file that had something similar to a statement such as that, so your full file path was ending up as a static variable in every source file.