Why is my release exe 32 kb with only 14 lines of code?

[Craisins]

#include < windows.h >
#include < string >
using namespace std;

void alert( const string& title, const string& message ) 
{
	MessageBox( NULL, message.c_str(), title.c_str(), MB_OK | MB_ICONINFORMATION );
}

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd ) 
{
	alert("Okay", "Working!");
	return 0;
}

I just downgraded from MSVC++2008, which had my release exe 33kb with around 1000 or more lines of code, Im trying to learn how to use MSVC++6.0 and its giving me such a hard time with everything, I chose active config to release and hit build, and the exe in the folder is 32 kb with only this.

Edit: Apparently 2008 strips unused functions and discards code and things from header files, any way to do this in 2006? Should I try mingw for stripping?

[OReubens]

Is that 32K a debug build ? or a release build ?

VC2008 is a bit more aggressive in stripping out unused parts as opposed to VC6. Particularly when dealing with templates.
In this case, using the string class, this is probably dragging in the entire string class including the somewhat expensive formatting functions.

[Craisins]

Debug is much bigger and release is around 32kb. What can be done to get VC2008 style cleanup?

Only reason I switched to VC6 is because VC2008 required some computers to have MSVC90.dll as a runtime library and is very annoying to the end user to have to install that, so I chose VC6. I wish 2008 had a way to build exe as VC6 does however.

[laserlight]

Only reason I switched to VC6 is because VC2008 required some computers to have MSVC90.dll as a runtime library and is very annoying to the end user to have to install that, so I chose VC6.

It is a one time install, and since it is redistributable you should be able to make it part of your installer, if I am not wrong.

[Skizmo]

If the .exe filesize is a issue you could take a look at UPX.

[Craisins]

Installer? It's just a standalone exe that uses messagebox. UPX works great but honestly a messagebox code shouldn't end up 16kb after UPXing. Hopefully when my program gets larger the filesize evens out.

[Krishnaa]

You should check your project settings, may be something like debug info etc is on and is causing addition to size.

[Lindley]

If you set your VS2008 project to link the runtime library statically, then the DLL should not be required (but the exe size may be slightly larger).

[Craisins]

Im in VC6.0 now, not using 2008 anymore.

[laserlight]

Im in VC6.0 now, not using 2008 anymore.

Are you aware that MSVC6 is pre-standard?

[olivthill2]

Should I try mingw for stripping?

I have tested your program with dev-cpp and mingw.
With the default options, size of exe is 102 kb.
With options set for optimizations, size of exe is 49 kb.

With arrays of characters instead of strings, size of exe is 6kb (6144 bytes).

#include <windows.h>

void alert(char *title, char *message)
{
	MessageBox( NULL, message, title, MB_OK | MB_ICONINFORMATION );
}

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd )
{
	alert("Okay", "Working!");
	return 0;
}

[Lindley]

Im in VC6.0 now, not using 2008 anymore.

....but, VC6 is the devil.

Well, at least it has enough problems that I'd advise choosing 2005 over it if you really *can't* use VC2008 for some reason. Personally, I think you haven't sufficiently explored its options yet.

[Paul McKenzie]

Im in VC6.0 now, not using 2008 anymore.

VC 6.0 -- a compiler that is:

1) Unsupported by Microsoft, and truthfully a dwindling number of people here use it regularly.
2) Over 10 years old, therefore non-ANSI compliant
3) Compiles buggy C++ code, and fails to compile legitimate ANSI C++ code (this is related to item 2).

Here is an example of the problem, and it was brought up in a thread a few weeks ago.

Visual C++ 6.0 will compile broken code -- code that will not work with any later version of Visual C++, as well as any ANSI compiler. The problem is that the broken code that it compiles can be very pervasive -- especially the invalid for-loop scope that 6.0 uses. A poster had a program written in Visual C++ 6.0, and none of us could get the code to compile, since we are all using modern ANSI C++ compilers. There were literally hundreds of errors when compiled using a later version of Visual Studio.

Practically speaking, VC 6.0 should only be used for legacy applications that were already built with 6.0 way back when, and for some reason, those apps were never upgraded so that they were built with a later version of Visual Studio. New apps shouldn't be created with VC 6.0.

Many companies that used to build libraries using VC 6.0 have dropped support for it -- because it is not an industrial strength compiler for this day and age, maybe 12 or so years ago it was state of the art, but not now. Failure to compile templated code, and even legitimate non-templated ANSI C++ code is the reason why.

Regards,

Paul McKenzie

[OReubens]

Installer? It's just a standalone exe that uses messagebox. UPX works great but honestly a messagebox code shouldn't end up 16kb after UPXing. Hopefully when my program gets larger the filesize evens out.

it is NOT the messagebox. MessageBox is a call tot he Windows API so it shouldn't even add any extra code other than the necessary framework to get the DLL loaded and the function imported.

The problem here is the use of the string class.

VC6 library design is know to be somewhat sloppy, and just creating a single string and not even using it other than the creation, drags the whole class tree and everything that class uses into your exe.


-> remove/comment out the alert function and the call to alert. And compile, you should get an exe somewhere 4-8K, even with VC6.


If exe size is important to you, then you need to be concerned about what classes you are importing. Write your own simple string class if you have to.

You can use an exe compresion tool, but know that this typically makes the exe smaller, but has a negative impact on actual memory used and the swap file since it ends up having the entire code and static data part of your exe loaded into private comitted data rather than shared/mapped memory space.

If you are worried about the MFC dll. you can link to MFC statically. This will make your exe larger, but it'll still be smaller than the size of your exe+dll it makes your distribution smaller and easier at the cost of more memory used.

[Arjay]

Be a professional - write an installer (and don't write software with a 12 year old, non-compliant compiler).