Let's see if we can't add support for *.xexp files.
We may have to do some trickery to allow runtime patching (maybe scan for *.xexp in the same directory?)
Title updates are officially installed via STFS archives to the hard drive, right? It would be nice to support loading them from the virtual filesystem in addition to loose .xexp files.
Edit: Actually, this may be the only way to properly handle updates, as the LIVE archive containing the .xexp can also contain additional data that the new binary will look for.
I'm interested in working on this - leave a comment if you have made a start please!
Go for it! I haven't begun researching it. Good starting point is in cpu/xex_module.cc.
I have got a bit stuck reversing the XEX_HEADER_DELTA_PATCH_DESCRIPTION structure - which actually contains the patch instructions. Annoyingly xextool supports generating patched xex files but decided to do some packing tricks.
@jackchentwkh if you still have this please get in touch with my email
Had a shot at it and managed to get .xexp's working here: https://github.com/emoose/xenia/commits/xexp
Example log output: https://pastebin.com/gupjZXgB
Had to change a lot to make it work though, first moved all the XEX2 code into XexModule, then had to change how XEX loading works: it now returns X_STATUS_PENDING after loading in XEX headers & data, then if a patch is found it can be applied, and after that UserModule::LoadXexContinue() is called to finish up the XEX load (ie looking for imports/functions/symbols/etc, setting up loader table entry...).
The commit messages go into detail about it a little more, it's mostly done this way so we don't have to bother resetting all the import/function/symbol stuff after patching.
If someone could look it over that'd be great, if you think it's good enough I'll make a PR for it, otherwise I'm happy to leave it as a reference for someone who wants to work on XEXP stuff in future.
@emoose This is actually really wonderful! Go ahead and submit a pull request so I can do a full review - but the code looks great at a glance.
@DrChat Will do, since this is such a big change I expect there'll be a lot of things that can be improved, my C++ isn't exactly the best neither (always been more of a C person really :P), but I'll be happy to fix up anything that gets flagged.
Most helpful comment
Had a shot at it and managed to get .xexp's working here: https://github.com/emoose/xenia/commits/xexp
Example log output: https://pastebin.com/gupjZXgB
Had to change a lot to make it work though, first moved all the XEX2 code into XexModule, then had to change how XEX loading works: it now returns X_STATUS_PENDING after loading in XEX headers & data, then if a patch is found it can be applied, and after that UserModule::LoadXexContinue() is called to finish up the XEX load (ie looking for imports/functions/symbols/etc, setting up loader table entry...).
The commit messages go into detail about it a little more, it's mostly done this way so we don't have to bother resetting all the import/function/symbol stuff after patching.
If someone could look it over that'd be great, if you think it's good enough I'll make a PR for it, otherwise I'm happy to leave it as a reference for someone who wants to work on XEXP stuff in future.