Don't use Windows API

[Tyrrrz]

Details

Currently, we use Windows API to read and write resources. If we replace those with manual reading and writing of PE files (potentially a huge undertaking), this library could then be fully cross-platform. Not sure if it's a lot of use to be able to edit resources of Windows PE files on non-Windows operating systems though.

[TecsiAron]

Just used Ressy to make a small command line tool to change the version number of exe files on our CI server (Linux). It worked with wine no issue. I know its not ideal, but just wanted to let people, who might be looking, know.

[Tyrrrz]

Just used Ressy to make a small command line tool to change the version number of exe files on our CI server (Linux). It worked with wine no issue. I know its not ideal, but just wanted to let people, who might be looking, know.

Nice 🙂 Glad it worked for you.

[Tyrrrz]

Another reason not to use Windows API: It seems that all resource functions create temporary files on disk when reading/writing resources. These files are not always deleted, for example if the function fails in some very fatal way. Additionally, if the PE is corrupted (easy to reproduce by changing a random string to a shorter/longer string without updating the pointers in the headers), then these files end up growing indefinitely and never get deleted. Working with binary files ourselves gives us more control and lets us avoid such problems.

[Tyrrrz]

Maybe these classes could be helpful:

• https://learn.microsoft.com/en-us/dotnet/api/system.reflection.portableexecutable.pereader
• https://learn.microsoft.com/en-us/dotnet/api/system.reflection.portableexecutable.managedpebuilder