I run the game, play with settings and saved games, then run a custom-made script that looks for newly created and modified files. I don't know how to get this kind of info directly from the binaries, but any help on this would be most welcome ;-)
That is a time-consuming process, and it really shows some dedication to your project. The problem is that it is not cover every possible instance. If the game needs to write or even create some file in a rare situation (in the late game, for example) that you did not consider, the game may end up failing (and make some user unhappy).
I'm afraid I do not have a solution for you, but here was my idea: search for system calls being made by the executable. It is possible that helpful tools exist for elf-executables, but for Windows, I don't know.
This is how I would approach this: look at the executables in an hex editor, and search for the names of the files. Try to look at the surrounding context to distinguish strings that refer to an open() system call from other strings that may exist in the files. Then try to see the flags that indicate if it is a read-only operation or a read-write operation. I'm guessing those flags always go into the same registry (darn, I hope this won't need using a deassembler). The same thing may be done for files being created.
Why this may not work:
1. compiler optimization may obscure the relevant pattern;
2. the file names may not be part of the executable, and created through a process or stored in some data file.
So this is no silver bullet. I could
help with coverage if it worked.
Another possible approach would be using an overlay filesystem
or an union filesystem
. Overlayfs seems to be part of the mainline kernel since 3.18, but it requires root privileges. I think a userlevel solution wold be better, like Unionfs for FUSE
. Now this could
be your silver bullet.
Unionfs on FUSE should not cause much of a slowdown for games, and IMHO, it is well worth the extra dependencies it brings, since play.it
, support all
games on GOG. Actually, this sounds a tad too good to be true (no more per-game scripts, for instance), so I may be overlooking something. I don't know if you looked at this option before going with the symlinks and discarded it, but it would be my first choice.