Click to See Complete Forum and Search --> : Can exe file size be calculated from PE header fields?


S_M_A
February 3rd, 2010, 01:21 PM
Feels like I've read a million articles but so far without any success in finding the answer...

The reason for wanting to know is that if the relation exists it would open for a very easy bundling of one single exe with another (binary data) file. I.e. using only the shell as the tool to create a new exe file containing customized data. Maybe this is in a way cheating on the resource concept but I know my client would love to be able to create new files himself (and so would I since that part is quite boring ;)).

The requirement is a single self sustained exe file for each distributed variant. So as far as I can see my options are either the concatenation way or a different build target for each variant.

All clever thoughts are welcome...

GameZelda
February 6th, 2010, 06:09 PM
Just write the size of the resource at the end of the PE, and the resource just before it.

VladimirF
February 7th, 2010, 11:01 PM
All clever thoughts are welcome...Why don't you write your stuff at the end of exe file, and then - 4-byte length of it.
Then you won't need to parse PE header, just read last 4 bytes and seek back.

S_M_A
February 8th, 2010, 01:31 AM
Thanks, I had that thought as well but discarded it since I didn't find a way of doing it with plain console commands. I think I was a bit unclear regarding this part in my post. My client does not have access to anything more than a plain Windows installation and don't want it either so providing a special tool wasn't an option.

Unfortunately the time schedule made me go for the build target solution this time. It's not as flexible as I'd wished but it gets the job done for this time.

Krishnaa
February 8th, 2010, 03:33 AM
Why can't you put the variable thing in resource and create the specific exe using your own custom tool.

S_M_A
February 8th, 2010, 03:42 AM
I could have done that but since I seeked a solution free of any other tools besides shell commands I didn't. Since now I'm doing the duplication job it's much faster to make the duplicate targets than make the tool (even though it's simple). I still think the simplicity of a plain binary attach would be a beautiful solution so maybe I do some more research during my spare time.

VladimirF
February 8th, 2010, 05:13 PM
I could have done that but since I seeked a solution free of any other tools besides shell commands I didn't. Since now I'm doing the duplication job it's much faster to make the duplicate targets than make the tool (even though it's simple). I still think the simplicity of a plain binary attach would be a beautiful solution so maybe I do some more research during my spare time.Well, I still think my suggestion satisfies your requirements.
You can build your exe, get its size, create a 4-byte binary file (size.bin) with that size in it and use this shell command to create your targets:
copy /B Test.exe + /B data.bin + /B size.bin new.exeIt this scenario, after you read that size from the end of your exe, you seek from the beginning to that offset and read your data.
Am I missing anything?

S_M_A
February 9th, 2010, 06:18 AM
Well both yes an no. Your suggestion works for me but not for my client (the end user). To be able to push the job of bundling things to the client the solution had to be even more trivial. He/she does not know how to create a size.bin with the correct content and endian.

That's why I seeked a more reliable solution, when it comes to assigning numbers properly I do trust the vc linker more than any human. :)

VladimirF
February 9th, 2010, 05:12 PM
This will work for your clients if YOU will provide that size.bin file.
How do you feel about hacks?
The first section of PE file is [now almost obsolete] MS DOS header that have some reserved space. You could write the exe file size into those fields.
Bottom lime is – there are few optional parts in PE file, and if there is no straight “size” filed (I don’t know if it exists), you would have to parse whole lot of data to figure that out.
Since your solution is somewhat a hack in itself, I would consider this suggestion.