My app is 25 kb size when stripping symbols (-s) in no it has 62kb
When im linking to psapi (-lpsapi and using one function from it, psapi is winapi lib for process info etc) it grows to 175 k and with stripping symbols 75 k
no using psapi 25k 62k
using paspi 75k 175k
why it grows so large (i am using only one function and my app grows from 25k to 75k i dislike it because i like tiny executables)
Is there a way to shrink it to 25 k again?
Have you already tried dynamic/runtime linking. Is the API open source, so that you can stripe all the unnecessary code out of it ?
Have you already tried dynamic/runtime linking. Is the API open source, so that you can stripe all the unnecessary code out of it ?
psapi is some winapi but you must link to libe explicity -lpsapi
(also you must include header (#include <psapi.h>) out of
the normal windows.h (but present and included like windows.h)
- I dont know the difference agains other winapi where you do not
link explicite, why I must use header and link it
I not tried the dynamic linking it would probably work (could eventaullt try it) but now I just wonder why it grows so (including whole windows.h
not fats out my exe and this psapi makes +50k)
Are you sure you are doing this correctly, your MinGW install is good, and your computer has no malware on it?
My complete psapi.dll alltogether only weights 9,216 bytes, so even assuming you linked the DLL's complete binary code into your executable somehow (which is not how it works!), this couldn't explain an extra 50kiB.
Linking with psapi.dll the proper way using the import lib (-lpsapi) makes exactly zero difference here (it's probably a few bytes extra, but due to PE/COFF section size alignment, the final executable is exactly the same size).
Are you sure you are doing this correctly, your MinGW install is good, and your computer has no malware on it?
My complete psapi.dll alltogether only weights 9,216 bytes, so even assuming you linked the DLL's complete binary code into your executable somehow (which is not how it works!), this couldn't explain an extra 50kiB.
Linking with psapi.dll the proper way using the import lib (-lpsapi) makes exactly zero difference here (it's probably a few bytes extra, but due to PE/COFF section size alignment, the final executable is exactly the same size).
strange,
mingw should be ok, as to malware cannot be sure but never saw
a manifestation of it and everything seem to be ok
psapi here 23 040 bytes, I could try disasembly etc matbe try to see
whats going on but maybe im too unexperienced - and thus this question
Increasing the total linked size by over twice the size of the added library is completely abnormal. I guess there must be some other source of code, such as
There are plenty of tools to list the content of an executable file: they should allow you to see which sections grow and which sections remain the same between the two versions of the program.
I've tried this again with a different MinGW build (TDM-4.8.1), and done binary compares.
Wiht or without -lpsapi (when not actually using any functions from psapi) makes exactly zero difference (executables are binary identical except for the linker's timestamp in the PE header, but that one is different for every two builds).
When actually using a function from the library (I tried EnumProcesses), a few dozen bytes are added to .text (no surprise), and the function's name is added to the back of the file (presumably import table), as well as the library's name. Alltogether, fewer than a hundred bytes are different.
The total size of the executable remains exactly the same (again, because of PE section sizes, there are merely some fewer zeroes at the end).
So... if your executable grows by 50kiB, something must be seriously amiss.
I've tried this again with a different MinGW build (TDM-4.8.1), and done binary compares.
Wiht or without -lpsapi (when not actually using any functions from psapi) makes exactly zero difference (executables are binary identical except for the linker's timestamp in the PE header, but that one is different for every two builds).
When actually using a function from the library (I tried EnumProcesses), a few dozen bytes are added to .text (no surprise), and the function's name is added to the back of the file (presumably import table), as well as the library's name. Alltogether, fewer than a hundred bytes are different.
The total size of the executable remains exactly the same (again, because of PE section sizes, there are merely some fewer zeroes at the end).
So... if your executable grows by 50kiB, something must be seriously amiss.
dont know i can link the binary if somebody would like to disasembly it or something, I feel not ready to this..
https://www.dropbox.com/s/q5htqxrv94oocq9/psapigrow.zip
here are both versions , i comented my prototype game code so it is only green dot moved by mouse - app
One is compiled with exception support, and the other without.
You can easily tell by the presence (or absence) of __unexpected_handler_sh and __terminate_handler_sh or strings such as "terminate called after unhandled exception".
One is compiled with exception support, and the other without.
You can easily tell by the presence (or absence) of __unexpected_handler_sh and __terminate_handler_sh or strings such as "terminate called after unhandled exception".
I carefull add -fno-rtti -fno-exceptions to all i compile and link, so
linking to psapi forces mingw to enable exceptions (and ignore my commands)? Is there a way to remove it?
