Fix peres file version output

[arbruijn]

No description provided.

[GoGoOtaku]

Thank you for the fix

[jweyrich]

Would it make sense to use offsetof(struct VS_VERSIONINFO, Value)?
That would also require us to define VS_VERSIONINFO as per https://learn.microsoft.com/en-us/windows/win32/menurc/vs-versioninfo
PS: Going further, if VS_VERSIONINFO is defined, the ptr arithmetic could be changed to get the base of it instead and access the Value member from there.

[GoGoOtaku]

Yes and no. On one hand it would be better since we could more easily check for values like the L"VS_VERSION_INFO" string and if it even has a value. On the other hand the issue would still persist.
At least in theory.
The issue here is Padding1 at the start of padding one we are at byte 36 which is divisible by 32. Since this padding is mandatory tho it adds another 4 byte which is where that magical 40 comes from.
Now according to the spec it could also just a 2 bytes if for example the padding would begin at byte 38.
Here is what I don't understand tho: If we assume that the string is in fact always 16 wchars long it would have to begin at byte 36.

In general I think it would still be a better way of doing it but I also think that some parts of this should be moved to libpe. Let me write up a patch so I don't have to give the contributor additional homework.

[jweyrich]

Oh, wait, right. The size of wchar_t is not defined by the standard. If it's 4, then 16*4 is already 64, and Padding1 would be required to have length 20 so that Value's offset will be 32-byte aligned at 96.
If I got this right.