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

Code:

---

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

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.

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.

Quote:

---

Originally Posted by Craisins

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.

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

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.

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

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

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

Quote:

---

Originally Posted by Craisins

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

---

Are you aware that MSVC6 is pre-standard?

Quote:

---

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

Code:

---

#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;
}

---

Quote:

---

Originally Posted by Craisins

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.

Quote:

---

Originally Posted by Craisins

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

Quote:

---

Originally Posted by 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.

---

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.

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

Quote:

---

Originally Posted by Craisins

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

---

Nothing special, you know. You just spend a few years to learn C++, and magic comes ultimately. :D

35.cpp here below is your 14 lines. Look what good /MD switch brings in. :)

Code:

---

D:\Temp\35>cl 35.cpp user32.lib
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

35.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:35.exe
35.obj
user32.lib

D:\Temp\35>dir
 Volume in drive D is WORK
 Volume Serial Number is 4067-668D

 Directory of D:\Temp\35

02/09/2010  12:45 AM    <DIR>          .
02/09/2010  12:45 AM    <DIR>          ..
02/09/2010  12:45 AM              284 35.cpp
02/09/2010  12:51 AM            45,056 35.exe
02/09/2010  12:45 AM              382 35.exe.manifest
02/09/2010  12:51 AM              803 35.obj
              4 File(s)        46,525 bytes
              2 Dir(s)  37,164,232,704 bytes free

---

Code:

---

D:\Temp\35>cl 35.cpp /MD user32.lib
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

35.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:35.exe
35.obj
user32.lib

D:\Temp\35>dir
 Volume in drive D is WORK
 Volume Serial Number is 4067-668D

 Directory of D:\Temp\35

02/09/2010  12:45 AM    <DIR>          .
02/09/2010  12:45 AM    <DIR>          ..
02/09/2010  12:45 AM              284 35.cpp
02/09/2010  12:45 AM            5,632 35.exe
02/09/2010  12:45 AM              382 35.exe.manifest
02/09/2010  12:45 AM              950 35.obj
              4 File(s)          7,248 bytes
              2 Dir(s)  37,164,273,664 bytes free

---

Quote:

---

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.

---

Sure it will, by twelve years afraid though.

Quote:

---

Originally Posted by 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).

---

Wait really? How do I link MSVC90.dll statically??? Am I typing /MD or /CRT somewhere? And how big of a exe file size jump are we talking about if we link statically?

@ everybody else: thank you for the great tips, I am testing them all right now!

And about going back to 2008, I will go back to it once I figure out how to statically link the DLL it requires so that those errors do not pop up.

Quote:

---

Originally Posted by Igor Vartanov

Sure it will, by twelve years afraid though.

---

The /MD actually cut the file size by 80-90%! If I use it in VC6.0, the program should still be able to run in XP and above without those dependency errors?

Quote:

---

Originally Posted by Craisins

If I use it in VC6.0, the program should still be able to run in XP and above without those dependency errors?

---

It sounds like you are looking at the wrong approach.

Hoping that a 12 year old set of vc dlls remain on the OS is just asking for trouble because there is no guarantee that the VC dlls will be available in future OS versions.

The smart way to approach this would be to:

1) Statically link
2) Create an install program that installs the necessary dependencies.[/

I am coding ONLY for XP and Vista though, its a simple app and anything past Vista or below XP is not my target for this release, and is also not necessary, just trust me on
that part :P.

Quote:

---

Originally Posted by Craisins

Wait really? How do I link MSVC90.dll statically???

---

I don't have 2008, but if it's at all similar to 2005, then there's an option in the project properties, under C/C++ -> Code Generation. There should be four options in a drop-down menu: Multithreaded, Multithreaded Debug, and two DLL variants of those. Choosing one of the non-DLL versions will statically link the runtime library.

If size is a concern and just a Mesagebox is what you need to display
-C/C++->Advanced->Compile as C Code
- Linker->Input->YES/(NODEFAULTLIBS)

i.e donot use CRT, remove the string class reference. build as C code, the size of exe will be around 4 KB in release mode.

Quote:

---

Originally Posted by anuvk

If size is a concern and just a Mesagebox is what you need to display
-C/C++->Advanced->Compile as C Code
- Linker->Input->YES/(NODEFAULTLIBS)

i.e donot use CRT, remove the string class reference. build as C code, the size of exe will be around 4 KB in release mode.

---

Its not just messagebox, its around 1000 lines of code but I was wondering why the filesize was so huge with only messagebox and string. After enabling /MD all works well though, 32kb before UPX compression. I was gonna convert all strings to char but then it got complicated when I needed to join two to ten char arrays together and stuff.

Okay, I was waiting all the time the question: why /MD produses such an effect? what I pay for the shrinking? Is it a trap? And I waited in vain. There were only cheers with no trying to understand implications. That's so sad, you know..

Quote:

---

Originally Posted by Igor Vartanov

Okay, I was waiting all the time the question: why /MD produses such an effect? what I pay for the shrinking? Is it a trap? And I waited in vain. There were only cheers with no trying to understand implications. That's so sad, you know..

---

Because, I've already researched /MD myself on MSDN, but if you really wanted to answer it please do, I'm sure you'll explain it much better since MSDN is sometimes a pain to understand. Please, tell me :), why does /MD produce such a small file size, and what are the implications? The switch was /MLd before I changed to /MD.

/MT Multi-threaded (statically linked)
/MTd (same as above only "debug")
/MD Multi-threaded DLL (dynamically linked)
/MDd (same as above only "debug")

"Statically linked" means that the runtime libraries are linked to the final exe (lots of extra bloat). "Dynamically linked" means that the runtime libraries are in a separate dll and it only appears that your exe is smaller, but it will need the runtime dlls and "dll hell" may ensue.

I think the real question is...

Why is this thread larger than my source code?