Archived

This topic is now archived and is closed to further replies.

trigger

very small win32 programs with vc++.

Recommended Posts

hi all! just some days ago i compiled a program with an empty WinMain function. *shock* totally 24kb exe file only for an empty WinMain program!? after asking on irc i found out that there are some helpfull linker settings that dont linke the not needed stuff. so the exe file shrinked from 24kb to 16kb. when i use upx with the 16kb version i can get the file size down to ~4kb ! the only problem is that i cant really understand how this linker options work! is there anybody out who can explain them to me!? i also got, that when you use that linker option you have to specify the wanted libs or dlls manually. anybody out there who can tell me wich libs are important and why they are???? so you see that i am really interested in how it works and not only in using some linker options somebody told me to use. best regards trigger

Share this post


Link to post
Share on other sites
Look up a function on MSDN. At the end of every document function, it tells you what header the prototype is contained and what lib is required.

Share this post


Link to post
Share on other sites
well, that wasn''t my question!

i need informations about the following libs and why i have to link them:

kernel32.lib user32.lib gdi32.lib opengl32.lib msvcrt.lib

for example kernel32 or user32. i think that they arent used for any function but have to be used for a win23 programm. and saying to search the msdn is a very bad answer to this question. searching the internet would be faster. msdn is only a reference. but this is another topic. you guys should know that if msdn really is that good, nobody would need books on programming! hope you got that

best regards
trigger

Share this post


Link to post
Share on other sites
Under the linker options, specify /OPT:REF and /OPT:NOWIN98.

That''ll shave of some of the size. Also, make sure you compile in Release mode.

Now if the size isn''t small enough for you,. you might want to link the C runtime using a DLL. Go to Project->Settings->Compiler->C/C++ and select the Multithreaded DLL.

That''ll bring your basic windows app down to 4 KB.

Now for some advice. Don''t ever use UPX (or any executable packer). Never EVER. Its bad. It makes your exe smaller (by up to 75%) but it makes the programs memory requirement jump up to 10 times more (about 1000%)!!! That''s not worth it. I''ve seen it happen to my programs. Just look at your program memory usage under a program lik Win2k Task Manager or Norton Utilities System Info.

Share this post


Link to post
Share on other sites
well, thanx for the first real reply!

>Now if the size isn''t small enough for you,. you might want to
>link the C runtime using a DLL. Go to
>Project->Settings->Compiler->C/C++ and select the Multithreaded
>DLL.

using the c runtime using a dll!? doesnt this mean that the dll has to be in the system folder?? i heared that only windows 98 and higher has this runtime. win95 wont work! is that right?

later

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
thanx for all!

i really enjoyed reading the text :D !

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Add this to yer main .c file, it will
not add in all the useless windows
stuff that it doesnt need. but this
does require you to specifically add
windows includes...


#define WIN32_LEAN_AND_MEAN

Share this post


Link to post
Share on other sites
That just speeds up the compiler time (if at all). It doesn''t reduce the exe size, unless of course, my copy of MSVC is broken.

Share this post


Link to post
Share on other sites
Actually, it will shrink the executable size a little bit, but usually since the exe is a multiple of 4Kb, you won''t notice any size change (and also because the compiler does optimize most of it out of the final exe), unless you include functions that are part of the non lean and mean versions. If you do define win32_lean_and_mean, certain header files are not built in, such as windowsx.h.

Share this post


Link to post
Share on other sites
quote:
Original post by Nytegard
Actually, it will shrink the executable size a little bit, but usually since the exe is a multiple of 4Kb, you won''t notice any size change (and also because the compiler does optimize most of it out of the final exe), unless you include functions that are part of the non lean and mean versions. If you do define win32_lean_and_mean, certain header files are not built in, such as windowsx.h.

Nope, windowsx.h has nothing to do with WIN32_LEAN_AND_MEAN. That def only means that you won''t be using any MFC in your program.

Share this post


Link to post
Share on other sites
From MSDN:
--------------------------------------------------------------
To speed the build process, Visual C++ provides the following defines that reduce the size of the Win32 header files.

VC_EXTRALEAN


WIN32_LEAN_AND_MEAN
Newly generated Visual C++ AppWizard applications automatically benefit from VC_EXTRALEAN. You can also manually define VC_EXTRALEAN to speed the build process of many legacy MFC applications.

Non-MFC C++ and C applications can define WIN32_LEAN_AND_MEAN and any applicable NOservice defines, such as NOSOUND (see ProgramFiles\Microsoft Visual Studio\VC98\include\Windows.h and ProgramFiles\Microsoft Visual Studio\VC98\MFC\Include\afxv_w32.h), to reduce their build times.
--------------------------------------------------------------
Certain functions will be included in header files such as mmsystem.h and other header files that will force you to incorporate them into the program if WIN32_LEAN_AND_MEAN is defined. It doesn't only have to do with MFC.

Sorry, my mistake, it was MMSYSTEM.H.

Granted, its defined for MFC, but according to the definition of WIN32_LEAN_AND_MEAN, the following would not be included in the build:


#ifndef WIN32_LEAN_AND_MEAN
#include <cderr.h>
#include <dde.h>
#include <ddeml.h>
#include <dlgs.h>
#ifndef _MAC
#include <lzexpand.h>
#include <mmsystem.h>
#include <nb30.h>
#include <rpc.h>
#endif
#include <shellapi.h>
#ifndef _MAC
#include <winperf.h>

#if(_WIN32_WINNT >= 0x0400)
#include <winsock2.h>
#include <mswsock.h>
#else
#include <winsock.h>
#endif /* _WIN32_WINNT >= 0x0400 */

#endif
#ifndef NOCRYPT
#include <wincrypt.h>
#endif

#ifndef NOGDI
#include <commdlg.h>
#ifndef _MAC
#include <winspool.h>
#ifdef INC_OLE1
#include <ole.h>
#else
#include <ole2.h>
#endif /* !INC_OLE1 */
#endif /* !MAC */
#endif /* !NOGDI */
#endif /* WIN32_LEAN_AND_MEAN */

If you include it, it will just exclude those header files.
And one last thing, if you want to see

#define WIN32_LEAN_AND_MEAN

in action, in a non MFC program, go to my homepage

http://www.geocities.com/nytegard

and download the sample midi player. Try taking out the win32_lean_and_mean, along with the comdlg.h and mmsystem.h, and then put back #define win32_lean_and_mean, and you will see how it's used.

(Plus, it also will demonstrate a openfile dialog box and the mciSendCommand, which seem to be common questions).

Bah, my html skills are no where near up to par.

Edited by - Nytegard on June 30, 2001 6:25:34 PM

Share this post


Link to post
Share on other sites
I like to use WIN32_SKINNY_AND_PISSED

It''s the same like lean and mean but it just sounds better

Humanity''s first sin was faith; the first virtue was doubt

Share this post


Link to post
Share on other sites
NuffSaid: are you sure about upx''s memory usage? The homepage claims otherwise:

UPX is a free, portable, extendable, high-performance executable packer for several different executable formats. It achieves an excellent compression ratio and offers very fast decompression. Your executables suffer no memory overhead or other drawbacks.

Share this post


Link to post
Share on other sites
And cigarette companies don't say much about cancer .

Do a simple experiment yourself. Run a compressed and an uncompressed program and look at the run time image under Task Manager or some other program if you don't have Win2K (I'd suggest Norton System Info, it comes with Norton Utilities).

From experience, memory footprint can increase from anywhere between 30% - 1000%. For my programs, it is usually somewhere in the region of 300 - 500%. To me, that's HUGE.



Edited by - NuffSaid on July 1, 2001 12:31:34 PM

Share this post


Link to post
Share on other sites
Just a quick point, but excluding header files will rarely have an effect on the final executable''s size. Header files are almost entirely composed of function prototypes and external variable declarations. These things are just provided so that the compiler knows what types to use when a function or variable is used in your code. If you never use those globals or functions in your source file, they won''t get linked in anyway.

Share this post


Link to post
Share on other sites
Microsoft Excel 97''s executable is about 5.5 megs. After upx, just under 3 megs.

Let''s take a look using the System Information tool...

System resources beforehand: 50% free
Running excel.exe: 48% free
Running upx''d excel.exe: 45% free

You''re absolutely right.

Share this post


Link to post
Share on other sites
quote:
Original post by trigger
well, that wasn''t my question!

i need informations about the following libs and why i have to link them:

kernel32.lib user32.lib gdi32.lib opengl32.lib msvcrt.lib

for example kernel32 or user32. i think that they arent used for any function but have to be used for a win23 programm. and saying to search the msdn is a very bad answer to this question. searching the internet would be faster. msdn is only a reference. but this is another topic. you guys should know that if msdn really is that good, nobody would need books on programming! hope you got that

best regards
trigger



You can find all the answers to the questions you were asking in ( you guessed it ) MSDN. Now, I don''t think that anybody will want to write a 15 page message explaining all those libs when you can easily look it up in MSDN which comes with Visual Studio. ( Which I take for granted that you have since you were talking about it''s compiler options. )



"And that''s the bottom line cause I said so!"

Cyberdrek
Headhunter Soft
A division of DLC Multimedia

Resist Windows XP''s Invasive Production Activation Technology!

Share this post


Link to post
Share on other sites
You can also find out what lib''s your program NEEDS by running the depends program that comes with MSVC it''s under the tool menu. It''ll look at the executable and tell you what dll''s the program is actually useing, you can then remove all the rest from the libs and remove the extra size from the exeutable. Depends also list''s what functions are being used from what dll for your program and any dll''s the dll is loading will show up in the tree and show what functions are being used by that dll, etc... It''s actually quite usefull.

Share this post


Link to post
Share on other sites
/FILEALIGN:512

Add that line to build options when linking. Will shrink your file size greatly.

Share this post


Link to post
Share on other sites
avianRR: Anything in the libraries that are not used by your program will simply not be placed in the executable when it is generated. Removing unused libraries will speed up linking time, but have no effect on file size.

Share this post


Link to post
Share on other sites
Ok - exactly why this obsession about reducing the size of a 24k program anyway?

You know, I never wanted to be a programmer...

Alexandre Moura

Share this post


Link to post
Share on other sites
lo all!

why this obsession about reducing the size of a 24k program anyway? - simple question. its needed for a little 64k intro. every free byte is needed so i need to get all possible ones !

best regards
trigger

Share this post


Link to post
Share on other sites
/FILEALIGN:512 is the same is /OPT:NOWIN98. At least, thats what I got from the docs.

The effects of UPX will be even more scary when you get the memory runtime size in kilobytes (or Megabytes), instead of percentages of system resources.

That''s because most of us developers have hundreds of megs of ram installed, and a 2% increase on our machines may actually be a very big jump for the end user''s machine.

Share this post


Link to post
Share on other sites
Nuffsaid: I agree. 2% of my memory is about 4.5 megs. Sorry if I sounded sarcastic or anything in my last post - that wasn''t my intention.

Makes me wonder what the decompressor''s doing.

Share this post


Link to post
Share on other sites