pouët.net

i don't think this this topic will live up to anything good, by looking at the troll'o'meter of an average thread, but hey, let's give it a shot.
i was looking for a legal solution for development. as visual studio is rather expensive, and quite hard to purchase even if you have the money, at least here i was looking for a cheaper alternative.
I found Bloodshed's devc++ and mingw compiler as a quite useable combo, at least it wasn't too hard to port my projects were they using directx or opengl.
The problem is it creates hell of a big executables. Anyone tried (and succeeded?) to create anything that fits into ~64k (or less?) with this environment?
Some tips are welcome.
(even "buy a visual studio, asshole", but that would not be taken too serious for a while...)

have you tried compiling with no default libraries optimizing for size etc.?

with no default libraries (no debug info, no profiling) it went down to 97k.
(72 upx-ed)

a legal solution for coding demos could be lcc:
http://www.cs.virginia.edu/~lcc-win32/
i even saw a 4k intro done with it.

hmm...

i just compiled the following code in dev-c++:



without default libs, and the resulting exe was 3kb in size. but it can't be upx:ed. (upx returns NotCompressableException)

(compiling and linking the same code, with the same options, yields an 8kb exe that upx brings down to 2kb)

+in vc

you sure you do not include debugging info?
supply mingw with the -s option.

and -Os of course, if you haven't.

"without default libs, and the resulting exe was 3kb in size. but it can't be upx:ed."

UPX may say this because the executable is *too* small and can't be compressed simply because it wouldn't get significantly smaller.

thanks dudes.
what i found out is that at least in my version of devc++ (4.9.8.3) the linker option "do not use standard system startup files or libraries" is added the option to the compiler and not the linker...
Now by adding the -nostdlib manually at the linker tab, it works like a charm...
i feel stupid not noticing this...
thanks again.

"UPX may say this because the executable is *too* small and can't be compressed simply because it wouldn't get significantly smaller."

ah yeah... most likely. duh.

wow... i think i've been blasted by sagacity's superior intellect!

the gcc linker suck at producing small executables, but if you replace it with the lcc linker the result should be quite small.

Ofcourse, if you are a man you should use MSVC.

(UPX is unable to compress files smaller than 5-6k or something like that, guess it has to do with too much overhead... use fsg or apack+dropper for tiny exefiles)

Reed: There's a first time for everything.

iirc the reason for upx not being able compress files below 4k has to do with windows executable alignment rather than upx

jar: fsg manage it just fine, but then again -- fsg is basicly a dirty PE-hack. (but it DOES work on all current windows-versions, and thats what matters, the PE loaders tend only to support MORE tweaks/hacks, not less)

upx does things the "correct" way, but that has never been the way of the scene.

don't bother with legal problem, Bill Gates blesses demomakers everyday for making Windows platform so sexy ;)

MinGW linker is crap in the sense that it cannot sort out stuff which is not used anywhere. This may still bite you, as you need to import Windows libs, OpenGL/DirectX, and so on. Of course you can use dynamic loader for OpenGL, this may save you something.

Say, i hear that the good old OpenWatcom is worth trying in this respect. Keep us current as you go, i was going to try to hack the minimal libraries for OpenWatcom and for DigitalMars C++ compilers - one of them will surely fit. :)

Say, does anyone have any experience whether OpenGL or DirectX is better suited for 64K?

-eye/midiclub

what exactly is the "gcc linker" and "mingw linker"? ld, the GNU linker?

eye/midiclub: if your 64k makes use of fragment/vertex programs, then DirectX is the only option, as there's no way to load a binary shader in OpenGL.

ascii packs well :)

midiclub: well, directx is less imports in your executables because you use com-objects. however this counts for so little of your total space availible in a 64k that I wouldn't care about it. Use whatever suits you best, I don't believe either has any big advantages over the other in the 64k-context except from what imak said about shaders. (Gargaj is right about ascii too, though :P)

I have already considered the problem of packing the staders.

A LZ-compressor should compress most of defficiency out of it, but it may impact compression ratio for the rest of the excutable. Of course, one should strip the shaders of whitespace before using them.

It is very easy to write a tokeniser and a de-tokeniser. I don't think it shall have much effect, but is worth trying - a de-tokeniser is really a very tiny piece of code. LZ compression itself is almost equivalent to tokenisation. BTW, i suspect that bytecode shaders are merely tokenised representations themselves.

Another thing: with only a few shaders all this size consideration is out of reevance. :)

-eye/midiclub

Why would you use LZ-compression when you're compressing your executable *anyway*? That's just dumb. :)