The Windows Template Library is geared towards what you want to do. It's a light-weight, template-based C++ wrapper for the Win32 API. With it, you don't have to go through the pain of direct Win32 coding, but it doesn't add a lot of overhead like MFC.
uTorrent is written in C++ and uses the old fashioned Win32 API. Google Chrome is also written this way, so why not download the source code and learn from their code?
If you want to optimize for the smallest possible memory footprint and you don't mind jumping through a bunch of hoops that the .NET CLR was invented to take care of for you, then writing a direct Win32API app and hooking to GDI+ is the way to go. Petzold was the definitive reference.
Really, though, it's sort of a fool's errand, since the .NET runtime is going to be loaded into the OS's memory whether your app uses it or not, so you may as well link to it.
The Demo Scene is a group of people who spend their free time trying to make impressive and very small executables, which usually render something in 3d to music. Often the entire demo (code, music, 3d data) compiles into a single executable that is compressed to 64k or an impressively small size for the content.
You might draw some inspiration from the demos and learning about how they are made will inform your obsession to create small executables.
Often, the key is to leverage as many 3rd party DLLs as possible that are installed with windows. Also, low level, custom coding of everything else is required.
General: For smaller executables, #define WIN32_LEAN_AND_MEAN and VC_EXTRALEAN (assuming VS). Don't compile with debug symbols (you probably knew this). Use fewer libraries, and be user to only link the parts of libraries you need (VC's linker is pretty good about this, but don't touch optlink if you can help it).
Strip the relocation headers : Go to http://www.paehl.de/cms/oldtools and search for "ReduceEXE" (direct download link: http://www.paehl.de/reduce.zip ).
Run an executable packer: http://upx.sourceforge.net/ ... It uses up more memory at runtime and starts a bit slower, but the file is MUCH smaller.
If you care about file size more than speed, VC has an option to "optimize for size", which turns off some things like loop unrolling and function inling.
If you want to go hardcore (and don't care about all the software engineering advantages), try using fewer classes, preferring POS types without virtual functions instead. Wikipedia suggests that 6-13% of a program's execution time is spent doing virtual calls. Further, the vtables themselves take up (a LITTLE) memory, and size_t worth of memory at the beginning of every class instance (that has a virtual function) is allocated for the vtable pointer. IOW, "pure C" can end up being slightly faster (though if you find yourself emulating classes with function pointers, go back to C++).
The old "LIBCTiny" trick still works. With modern VC++ releases, you might need to turn of a few features.
Another good trick to know is the lstr*
collection of functions in Kernel32. That's already in memory, so those functions might be a leaner choice.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With