And beside that really nice Preprocessor I just discover by now:
It also happened that I had a look upon AutoItSC.bin. (The script interpreter stub that's attached to every compiled AutoIt-Exe.)
- Wow nice no '.reloc' so I see you already 'found' the /DYNAMICBASE:NO' linker switch.
Just because I read the first reply:
So why is that good? - Guess what it's the *,exe that loads the *.dll and not the other way. So since it comes first in the new process adress space - nearly everything is free. So it can always load at it's preferred address and never need to 'move'/relocated to somewhere else.
- However it happened that I loaded AutoItSC.bin into in IDA, And saw that the Common RunTime's are statically linked:^- That's the whole adress space of AutoItSC.bin, the cyan area's are statically linked library functions.
By using the Compiler switch /MD these areas will stay out of the AutoItSC.bin and load from msvcrt.dll that there in the system32 dir on ever windows installation.
That might shrink the size something about 25%.
Maybe I'm really not really telling any news about that /MultithreadDll switch. And in detail things are not that perfect. The performance 'loss' between calling a library function or a function to a loaded Dll is in my eyes minimal.
The main reason is that depending on what VC you're using that MSVCRT.dll is sometimes names MSVCR70.dll, MSVCR71.dll, or with the 'brand new' VC++ 2011 MSVCR100.dll. and I'll need to include these *.dll since you can't really assume that they are already in the system.
Well I for the other part of the reply I just checked it msvcrt.dll is even present in Win98 (Setupfile WIN98_57.CAB) Windows itself is written in C++ and will make itself use of it - like for ex. calc.exe or ftp.exe does.)
Maybe you get it compiled with the old'n gold'n includes from VC6:
that really includes MSVCRT.dll and not that new crap from the MSVCRXX-version-zoo where I can't see what better whem using. Something it need undocumented under the hood gribs to like -d2QIftol to say to the actual compiler no I don't want my FloatToLong convertions with SSE. Or adjusting stdio.h
_CRTIMP extern FILE _iob;
#endif /* _STDIO_DEFINED */
#define stdin (&_iob)
#define stdout (&_iob)
#define stderr (&_iob)
so I get my 'stdin' handle directly via '_iob' array and not that fucking __iob_func that is not present in MSVCRT.dll
As C-Coder how landed from time to time in the ASM-Debug on nasty bug's you're probably know this:
MOV EBP, ESP
SUB ESP, 10
These framepointer based functions are somehow nice for debugging (and Reverse engineering) easier and quicker compiling, but for compiling optimized release code it's better to remove them with the /Oy compiler switch. That saves some space and bring minimalistic performance gains.
- More Optimizations options
I just name the in short without going to much in detail. Use the documentation at first place or ask for more details
/GL - Full optimization
/Oi - use Compiler build in asm functions like ROL instead of 'importing' them
/Os - small code - no alignment gaps between functions.
/GF - String pooling store identical strings only once
/Gr - try to use __fastcall calling convention
/Gs - no Buffer overflow protections - saves space and performance. newer saw the sense of enabling that by default. (AutoIT is not viewer-or-player-only-Standard app like a browser, pictureviewer or Audio/Video player where a buffer overflow attack makes sense )
Ever notice that mysterious 'Rich'-signature between the MZ-Dos Header and the PE-COFF Header on all files compiled by the Microsoft incremental Linker? Well after removing the light encryption from that an looking where that data comes from, it get's more harmless than you might though about when you where still in the mystery about what it could be.
It even get's useless - so I feel better not to have that crap in my release.
So I patched my linker to keep that 'rich'- thing out + shorten the MZ-Dos header ("This program cannot be run in DOS mode.") a little so that both(MZ+PE-Section header) stays under 0x200 bytes. So the .text section start at 0x200 instead of 0x400.
Well that 512 byte less is really not worth to talk about- but it's nice to get rid of that 'rich'-crap.
- Esoteric stuff
sometimes the one, the other or both makes sence.
/ALIGN:16 <- newer thought the windows loader will load such PE's. However I had I closer look into the ntldr-internals an if filealign = sectionalign the PE may seen as valid, when if filealign is not aligned to 0x200.
^- I don't recommand / like this kind of tweak since files just end up in a unpageable mess of code&data. However it's nice to try it out.
Anyway if someone of the Devs couid make a 'private' build for 32-bit version of AutoItSC.bin with
/MD /Oy /GL /Oi /Os /GF /Gr /Gs
and release it here !
Would but be really nice.
Edited by Robinson1, 08 September 2011 - 09:57 PM.