What makes Crinkler happy?

[rain_storm]

Still playing around with this excellent tool but it just occured to me I havent a notion as to what to do to get the most out of crinkler. At the moment Im just trying something and linking with crinkler its not until i see the output that I can tell what difference any changes made, How about arrays do the compress well if they are not all zeros?

Edit:
Also what alternatives are there to crinkler Ive seen some demos packed in a com file that emits a MZ.exe whats that all about?

[hellfire]

Ive seen some demos packed in a com file that emits a MZ.exe whats that all about?

The .com- and .bat-file things don't need the space for a win32-exe-header. they contain the complete win32-binary in compressed form, uncompress it to harddisc and execute it (so called file-dropping).
The smallest way to perform the uncompressing here, is to just call expand/extract from /system32.
That MS-compressor, however, is not really state-of-the-art anymore.

[Jim]

Vista and well virus-protected computers hate droppers.
Crinkler is ace for miniscule apps, around a few kb.  kkrunchy is best for 64kb stuff.  Watch out though - some of the latest 'beta' kkrunchy exes don't work on Vista.

Jim

[rain_storm]

Is there any way to use crinkler with *.a files like what DevCpp uses. Or will I have to use OpenGL32.Lib instead of tinyptc_ext.a. I have tried renaming it to tinyptc_ext.Lib but crinkler still balks. Ive gone through unpacked versions with a hexeditor to see exactly what dll's are being called I was surprised that only kernel32.dll user32.dll gdi32.dll and msvctr.dll are used by tinyptc or thats all that is included in the import section I try to link to the SDK Libs but I havent gotten crinkler to accept a tinyptc project yet always fails to open *.o if I try. But crinkler will accept *.o if I just make a simple console program.

[hellfire]

Programming C++ under Windows and not using Visual Studio appears *very* counter-intuitive to me.

[Jim]

You need to use the .lib files from the Platform SDK.  The Mingw ones don't work.
Also, if you're using crinkler, you almost certainly can't use any of the high-level libs like libptc.  They're too big and often rely on msvcrt C runtime dlls.  Normally with crinkled apps you are not using any C runtime calls at all to get the tiny size.

Jim

[Rbz]

I've managed to make tinyptc_ext crinkler 'compatible', you can grab it here:
http://www.rbraz.com/source/tinyptc_ext.zip

You can even use original library name to compile it (libtinyptc_ext.a).

I did some tests and managed to make a packed plasma effect example compress to 3097 bytes.

As Jim said, you will need .lib files from the Platform SDK to compile it.

If you need a MSVC example, I can do one for you later.

[Jim]

->rbz - are you saying you've removed the all the libc references from libptc?

Jim

[rain_storm]

Thanks rbz, tinyptc_ext is a dream to work with I cant thank you enough for your work on this library. Gonna try that version out right now

Edit:
That version compiles to 10KB under FB thats nearly half the 18kb that I am used to and thats without crinkler

@rbz Just out of interest what commandline parameters are you passing to Crinkler

[Rbz]

->rbz - are you saying you've removed the all the libc references from libptc?

Jim, yes, I've compiled it using "Ignore all default libraries", anyway tinyptc really never needed anything than "kernel32.lib,gdi32.lib and user32.lib" to be compiled.

That version compiles to 10KB under FB thats nearly half the 18kb that I am used to and thats without crinkler

Good, seems to me that msvc did some magic

Just out of interest what commandline parameters are you passing to Crinkler

Just using default commands, eg:

Code: [Select]

CRINKLER.exe /out:tinyptc_ext_example.exe /ENTRY:main /subsystem:windows /LIBPATH:"C:\YOUR_PATH\Microsoft Platform SDK for Windows Server 2003 R2\Lib" kernel32.lib gdi32.lib user32.lib libtinyptc_ext.lib libmmx.lib Main.obj

[mentor]

rain_storm: For a final release build I would recommend something like this.

/COMPMODE:SLOW
Slow compression really isn't that slow anymore - there really is no reason not to use it.

/HASHSIZE:100-200
Indicates how many megs of ram will be used for decompression. Note that the decompression
memory overlaps with the static memory of the intro, so the memory requirement of the compressed binary
ends up being max(hashsize, static memory used by intro). If the hashsize is smaller you can essentially
raise it to the memory usage of the intro for free. A larger hashsize is always better, but the law of diminishing
returns kicks in fast after the 100-200mb mark.

/HASHTRIES:500-1000
Indicates the number of tries made to find a good hash function minimizing collisions. Higher is better, it will only cost you CPU cycles.

/ORDERTRIES:5000-?
Indicates the number of tries at different layout of the code/data. The impact of a good layout can be quite dramatic, so spending some extra time here can often pay off. The iteration will converge at some point, mostly depending on the number of sections in the intro. Try out some different values to see when there are no more improvements. Again, setting it too high will only cost you CPU cycles.

/UNSAFEIMPORT
Disables the warning message that appears if a dll file is missing. The rule of thumb is: If you are not using d3dx9_xx.dll, you are safe to use /UNSAFEIMPORT.

/TRANSFORM:CALLS
Transforms relative calls (E8) to absolute calls to improve compression. Enabling this feature gives a small overhead of ~20 bytes, so whether or not it is worth it really depends on the number of calls and how they are distributed. Try both and choose whichever is best.

Cheers
-mentor/TBC

[rain_storm]

Thanks alot mentor I will try these asap, Looks like a lot of info to play around with here that should keep me occupied for a while. I actually have just the project to try these with I shall soon see what is better for compression. I already know that default settings for this project compress to 1:3 ratio, any hope that this ratio can be bettered is worth investigating, Thanks again

[va!n]

@mentor:
thanks for your posing and beeing part of this great community! 
i have played a bit with crinkler and its settings... but their is just one point i dont really understand how to use nor get it work...

/TRANSFORM:CALLS
Transforms relative calls (E8) to absolute calls to improve compression. Enabling this feature gives a small overhead of ~20 bytes, so whether or not it is worth it really depends on the number of calls and how they are distributed. Try both and choose whichever is best.

can you give a small example how to use this?  i have tried things like    /TRANSFORM:E8    /TRANSFORM:0xE8   without success... atm i dont really know/understand how to use/get it work... sorry..

btw, you and blueberry got an email some days ago from me with some ideas/improvements for future crinkler versions... hope you guys got the message... thanks and send nice greetings to my old mate blueberry

best regards
"mr.vain of secretly!" aka thorsten

[mentor]

va!n: You should have received a reply from blueberry by now.

Call transformations are enabled using the /TRANSFORM:CALLS switch. The CALLS part identifies that it is the call transformation you want to use, which is currently the only one, not which type of opcodes to transform. By rereading the description I realize that it can be slightly ambiguous. Maybe we should consider rewriting it for the next release.

Good luck with your project,
-mentor

[va!n]

@mentor:
thanks for your fast and personaly reply! Yes, i got feedback from blueberry in the meantime... btw, you got a message (ICQ) too ^^
keep on your great work and thanks for sharing the great tool crinkler! 

best regards
mr.vain/secretly!