Anyone tried to compile FASM from the source?
I just did it for fun and noticed that the file size grows by about 50%... but only of FASM itself, not the compiled executables?!?!
How is that possible? Doesn't Thomasz compile FASM with FASM? ;)
From the documentation I can't see any optimization flag and as I said, I compiled the source right after I extracted the zip file (so no changes where made)
You also see the 0.2 seconds speed improvment? :rolleyes:
I just did it for fun and noticed that the file size grows by about 50%... but only of FASM itself, not the compiled executables?!?!
How is that possible? Doesn't Thomasz compile FASM with FASM? ;)
From the documentation I can't see any optimization flag and as I said, I compiled the source right after I extracted the zip file (so no changes where made)
C:\temp\Fasm\SOURCE\WIN32>fasm fasm.asm fasm2.exe
flat assembler version 1.39
39 passes, 0.5 seconds, 77312 bytes.
C:\temp\Fasm\SOURCE\WIN32>fasm2 fasm.asm fasm3.exe
flat assembler version 1.39
39 passes, 0.3 seconds, 77312 bytes.
C:\temp\Fasm\SOURCE\WIN32>dir fasm*.exe
09.07.2002 01:39 54.272 FASM.EXE
17.07.2002 09:33 77.312 fasm2.exe
17.07.2002 09:33 77.312 fasm3.exe
You also see the 0.2 seconds speed improvment? :rolleyes:
Ohhhhh..... stupid me without Hex Editor at work!
Hehe, that's not nice, Thomasz! Don't fool the FASM users! :grin:
C:\temp\Fasm\SOURCE\WIN32>debug fasm.exe
-D
155D:0100 81 FC 60 AF 77 02 CD 20-B9 9E 5E BE 9E 5F BF 00 ..`.w.. ..^.._..
155D:0110 AF BB 00 80 FD F3 A4 FC-87 F7 83 EE C6 19 ED 57 ...............W
155D:0120 57 E9 7F AD 55 50 58 21-0B 01 04 0A 1B F0 30 B9 W...[color=red]UPX![/color]......0.
155D:0130 04 07 69 E2 92 AD 06 5E-06 26 F6 FF B4 4A BB 10 ..i....^.&...J..
155D:0140 10 CD 21 BA 33 AE B4 09-06 6F FF FC E8 02 40 E8 ..!.3....o....@.
155D:0150 03 26 05 09 80 3E FF FF-86 B1 00 0F 84 DE 00 66 .&...>.........f
155D:0160 8D 06 87 B1 66 A3 A8 AE-F7 FF 66 67 0F B6 48 FF ....f.....fg..H.
155D:0170 66 01 C8 67 80 38 19 6F-4B C4 40 16 AC AE BF FF f..g.8.oK.@.....
Hehe, that's not nice, Thomasz! Don't fool the FASM users! :grin:
Well, my conclusion is, always to compile new FASM versions myself. There are 3 main reasons for that:
1) IMO, I get a slightly faster compilation because the file must not be unpacked before it can start compiling.
2) I can replace the line
stub_message db 'this program cannot be run in DOS mode.',0Dh,0Ah,24h
with
stub_message db '(c) 2002 by bAZiK',24h
;)
3) I am used to self compile from Linux :rolleyes:
Enough talking to myself now....
BTW, please replace all occurences of "compile", "compilation"
or "compiler" with "assemble", "assemblation" and "assembler".
I just remembered that f0dder loves to flame about this but am to lazy to edit the posts now :)
:)
1) IMO, I get a slightly faster compilation because the file must not be unpacked before it can start compiling.
2) I can replace the line
stub_message db 'this program cannot be run in DOS mode.',0Dh,0Ah,24h
with
stub_message db '(c) 2002 by bAZiK',24h
;)
3) I am used to self compile from Linux :rolleyes:
Enough talking to myself now....
BTW, please replace all occurences of "compile", "compilation"
or "compiler" with "assemble", "assemblation" and "assembler".
I just remembered that f0dder loves to flame about this but am to lazy to edit the posts now :)
:)
I thought I'd join you in this thread :)
with todays disk sizes and bandwidth there is little point in use exe compressors
with todays disk sizes and bandwidth there is little point in use exe compressors
with todays disk sizes and bandwidth there is little point in use exe compressors
Thats also my point of view. Expecially with a 70 KB application.
So the big question: Why did you compress this file, Thomasz? :)
Save on bandwidth? Perhaps he is charged if he uses to much.
small exe == cool :grin:
Save on bandwidth? Perhaps he is charged if he uses to much.
LOL!
His 200k FASM package at SourceForge? Some people host 700MB Linux iso's at sourceforge for free! ;)
Why use EXE compressors ?
1. They generally load faster.
2. The download quicker.
3. They defeat system paging.
If performance matters and the app is not a shared DLL of enormous size, why not ? :grin:
Regards,
hutch@movsd.com
1. They generally load faster.
2. The download quicker.
3. They defeat system paging.
If performance matters and the app is not a shared DLL of enormous size, why not ? :grin:
Regards,
hutch@movsd.com
I just remembered that f0dder loves to flame about this but am to lazy to edit the posts now :)
Haha - flame on, you nasty little penguin ;)
As for compressing the exe... sometimes compressing an exe will give
worse compression ratio when added to a .zip or .rar - this should
be tested before deciding whether to pack or not (and let the end users
UPX the executable if they want it).
Small exe cool? Sure, if you have limited amount of space, like a
floppy or one of those neat USB flash-ram storage devices. Apart
from that, there's not much use in doing EXE compression outside
of software protection. Ohyeah, and files will load a bit faster
across network devices... but slower locally, and I guess most people
run their files locally.
if penguins flame too much they'll die by melting the southpole ice-cap :eek:
Thomasz has an older machine and would like to support the full range of machines from 386 thru current. Also, it is nice to fit all your tools on one floppy (or cheap memory stick :tongue: ).
The memory stick wasn't all that cheap - but it's rather nice :).
On a 386 I bet runtime decompression of "not-so-small" executables
would be rather noticable?
On a 386 I bet runtime decompression of "not-so-small" executables
would be rather noticable?
The memory stick wasn't all that cheap - but it's rather nice :).
On a 386 I bet runtime decompression of "not-so-small" executables would be rather noticable?
IIRC, the decompression was noticable, but the floppy was slower. :)
IIRC, the decompression was noticable, but the floppy was slower. :)
:P - the 386's I had access to had harddrives. While this may sound
"woooh!", it was at school, when 486s were common and pentiums
were getting more commonplace... yeah, there was even a 80286.
Originally posted by hutch--
If performance matters and the app is not a shared DLL of enormous size, why not ? :grin:
If performance matters and the app is not a shared DLL of enormous size, why not ? :grin:
You may get "unintended side-effects".
Like yesterday when our network was upgraded to the latest F-Secure (anti-virus) software. Thirty minutes later F-Secure false-alarmed on BLANK.DLL and TEMPLATE.DLL in the \MASM32\PLUGINS directory.
The vendor confirmed that "Yes, this is a false alarm on packed files. The packer didn't bother to put accurate section information into the files' headers, so they start to look suspicious to our of our engines." They even had a free utility to fix the packed DLLs.
Of course it is not a big problem if that happens on your own hard-disk with your own files. I am nevertheless glad that I did not use that particular packer for executables that I distribute.
Regards
Frank
LOL!
His 200k FASM package at SourceForge? Some people host 700MB Linux iso's at sourceforge for free! ;)
Never had a webpage. Only guessing.
lol i always compress/compact my exes/dlls. it makes it smaller, faster and it stops newbie hakx0rz from taking my data.
if penguins flame too much they'll die by melting the southpole ice-cap :eek:
Funny. :)
Originally posted by Hiroshimator
if penguins flame too much they'll die by melting the southpole ice-cap
When the ice-cap melts, they will swarm to hutch's house in australia. :grin:if penguins flame too much they'll die by melting the southpole ice-cap