flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
bart 24 May 2004, 16:08
http://www.woodmann.net/bart/download.php?id=xt_fsg20.zip
or http://tinyurl.com/37eqh make your fasm executables smaller ![]() |
|||
![]() |
|
f0dder 25 May 2004, 00:41
but larger in memory, and slower.
|
|||
![]() |
|
iceplus 25 May 2004, 08:00
oh,packed FASMW.exe don't run!
|
|||
![]() |
|
roticv 25 May 2004, 12:44
f0dder wrote: but larger in memory, and slower. I share your opinion on exe packers. I do not fancy them in general. |
|||
![]() |
|
sina 25 May 2004, 13:15
and what about disassembly
|
|||
![]() |
|
Tommy 25 May 2004, 13:36
I agree... In my opinion we don't need exe packers... Either write optimized code and algorithms...
![]() |
|||
![]() |
|
Tommy 25 May 2004, 16:16
All in all the executable runs at same speed, don't they - I mean when a packed exe is unpacked, it's the same?... And then there's only the loading time which differs... Without knowing much about the topic, I would guess that unpacking an executable will take longer time than loading an unpacked one.
decard: I'm interested in hearing how the packed executable can run faster... Is there something I've been missing? I'm actually interested in learning more about it all... ![]() |
|||
![]() |
|
decard 25 May 2004, 16:33
I didn't mean that they can *run* faster, (the app should run at the same speed of course), I wanted to say that in some cases they can load faster, as the executable file is smaller, and thus it takes less time to read it from disk. Then your app is decompressed in memory, so the whole process may be sometimes faster (it depends on the mashine speed, on file size...).
However, for smaller executables the difference isn't visible at all. If you are interested in packing executables, download UPX source code (http://upx.sourceforge.net/). regards |
|||
![]() |
|
Tommy 25 May 2004, 18:02
Ok, I understand..
![]() |
|||
![]() |
|
zjlcc 25 May 2004, 20:08
for XP notepad.exe
Code: version size run ============================= other ? ? fsg v12 35728 error fsg v131 35504 error fsg v133 35456 error fsg v133a 35456 error fsg v20 45997 OK for 98 notepad.exe Code: version size run ============================= other ? ? fsg v12 18192 error fsg v131 17968 OK fsg v133 17921 OK fsg v133a 17921 OK fsg v20 26409 OK |
|||
![]() |
|
bart 25 May 2004, 21:17
new version doesnt remove high resolution icons (like all < v2 do), note that icons included in notepad for xp are big (9 formats for just one icon
![]() but switch 2 options in fsg.ini (strip_version=1 and handle_icons=1) and you'll get smaller exe (17553 bytes), but thats just the dirty way btw tomek maybe you'll take a look at the resource section in fasm executables and make it more like a standard compiler (IMAGE_RESOURCE_DIRECTORY_ENTRY after standard headers, then data) ![]() |
|||
![]() |
|
comrade 25 May 2004, 22:11
all resources are generated by macros (see INCLUDE/MACRO/RESOURCE.INC)
|
|||
![]() |
|
f0dder 27 May 2004, 15:05
Compressed executables "can" load faster since of course less will have to be read from disk - however, a compressed executable has to be read all-at-once on application start, while an uncompressed one is read on demand, in 64kb chunks, thanks to windows demand-loading.
Second-time load of the application will be slower with a compressed executable though - an uncompressed executable could be run directly from the filesystem cache, while the compressed exe has to be re-uncompressed on each and every run. This will of course only be noticable with large exes/slow machines. Just-in-time antiviral scanners can be quite slower on compressed executables. I don't fancy these AV scanners myself, but a *LOT* of end-users do, and they don't fancy slow loading times. Apart from speed issues, there's the memory bloat with regards to running multiple instances of an application. Windows shares the 'clean' (ie, non-modified) physical pages between multiple instances of a running application, and does copy-on-write to give each instance private versions of the pages they modify. In a compressed exeuctable, each and every one of the code/data/resource/... pages will be dirty, since they're written by the decompressor - no code/data sharing is possible. You might think this isn't a process in single-instance applications, but there's yet another problem with dirty pages - and that is what happens in low-memory situations. Windows can simply discard clean pages, because it knows it can re-read them from the original image file. Dirty pages will have to be paged out to the paging file - I guess most people will agree that writing to the harddrive is somewhat slower than just discarding some memory, yes? ![]() smaller != faster Anyway, not saying fsg is bad or anything, bart, so don't take this as an attack on you. I'm just annoyed at people who blindly uses exe compressors, especially if I end up having to do manual decompression to get higher-performance executables. |
|||
![]() |
|
Madis731 29 May 2004, 12:18
Sideremark: you speak about not noticing the change, but we are running multigigahertz computers nowdays. On small programs we even can not notice some 10x speed change, but to my mind it is a big problem already.
I think that we - assembly writers - should pay more attention to computer-measured cycles, not our own experience, cuz it can give use false (well not exactly false, but...) informatin. |
|||
![]() |
|
f0dder 29 May 2004, 16:12
We should pay attention to things that matter, not get lost in details.
|
|||
![]() |
|
roticv 30 May 2004, 06:50
To say the truth I have this tool called winspy15 and is packed by upx and the size of the packed exe is 34kb. But the program itself takes up to 5sec to launch....
|
|||
![]() |
|
XpoZed 10 Jun 2004, 09:30
bart.. FSG ownz
![]() |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.