Small Size EXE / Graphics Demo Competitions
Author
about five years ago I started to look into the requirements of to take part in a graphics demo competition. Obviously having a small exe size is fundamental if you want to get your exe under 4kb. So I looked into how to achieve this with Visual Studio and C. I upgraded from Visual Studio 2003 to 2005 and suddenly had much bigger exes, so I switched to Pelles-C, a compiler made for embedded and mobile programming. It is free.
It also became harder to switch from DX9 to DX10 because C is not considered a full language anymore and wasting space is not such a big issue for the Microsoft guys. This morning I thought I just publish what I did about a year ago. It is not really relevant to what we guys do here but maybe someone might have some fun looking at it.
http://code.google.com/p/graphicsdemoskeleton/
What is it: it is just a minimum skeleton to start creating your own small-size apps with DX10. At some point I had a particle system running in 1.5kb this way (that was with DX9). If you think about the concept of small exes there is one interesting thing I figured out. When I use DX9 and I compile HLSL shader code to a header file and include it to use it, it is smaller than the equivalent C code. So what I was thinking was: hey let's write a math library in HLSL and use the CPU only with the stub code to launch everything and let it run on the GPU :-) ...
I hope someone has fun with it :-)
A fact not so well known, your choice of linker (commonly link.exe) can have a significant impact on executable size for these small projects.
Microsofts linker produces a jumbo DOS stub, for example. Many linkers produce a relocation table even though for win32 executables there generally is no need for one. Between these two you could save up to 1 kilobyte.
Idealy you would use a combination of a good linker, PE manipulators (StripReloc, PE Optimizer, ...), and assembly language. You would not use a compiler for this sort of thing, and even with assemblers some hardcoded DB's are often necessary to get the smallest instruction for a needed operation.
Still further, many tricks can be used which allow a smaller instruction form. For example, adding 128 vs subtracting -128. The second can be encoded using an 8-bit immediate value whereas the first requires a 16 or 32-bit immediate value.
Microsofts linker produces a jumbo DOS stub, for example. Many linkers produce a relocation table even though for win32 executables there generally is no need for one. Between these two you could save up to 1 kilobyte.
Idealy you would use a combination of a good linker, PE manipulators (StripReloc, PE Optimizer, ...), and assembly language. You would not use a compiler for this sort of thing, and even with assemblers some hardcoded DB's are often necessary to get the smallest instruction for a needed operation.
Still further, many tricks can be used which allow a smaller instruction form. For example, adding 128 vs subtracting -128. The second can be encoded using an 8-bit immediate value whereas the first requires a 16 or 32-bit immediate value.
Quote:Original post by wolf
I upgraded from Visual Studio 2003 to 2005 and suddenly had much bigger exes,
You definitely can use VS 2005/2008 to generate small exe's:
http://msdn.microsoft.com/en-us/magazine/cc301696.aspx
http://wcrt.sourceforge.net/
http://www.crinkler.net/
There is smaller, and then there is small. The OP meant the real meaning of small.
Check out TinyPE
133 byte EXE's that download from the internet..
The 4K intro competitions are not won by style alone. These guys pack music as well as the graphics into that 4096 byte EXE. They dont waste a single byte.
Check out TinyPE
133 byte EXE's that download from the internet..
The 4K intro competitions are not won by style alone. These guys pack music as well as the graphics into that 4096 byte EXE. They dont waste a single byte.
Author
Hey cool stuff :-) ... I wanted to use C ... I already use an exe compressor but even that only gets me down to 869 bytes in the moment.
I used Visual Studio for a while but it was just a pain to get it doing small exes. Additionally there was a linker a few years ago who was call aLink and it helped a lot in making smaller files ... it is discontinued so.
Pelles C is just doing what I want and is small and handy. Obviously one step further is to disassemble everything and work from there. Something I can always do. At some point I optimized function calls in assembly but this was a pain :-) ... so I had inline assembly in there to call D3D functions while working with Visual C ... this is now much better with Pelles C.
I used Visual Studio for a while but it was just a pain to get it doing small exes. Additionally there was a linker a few years ago who was call aLink and it helped a lot in making smaller files ... it is discontinued so.
Pelles C is just doing what I want and is small and handy. Obviously one step further is to disassemble everything and work from there. Something I can always do. At some point I optimized function calls in assembly but this was a pain :-) ... so I had inline assembly in there to call D3D functions while working with Visual C ... this is now much better with Pelles C.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
