Resource locators are just strings that say where to find a resource, they can either point to a file path or to an XEX resource.
Normally the Gamercard/SharedSystem exports use XamBuildResourceLocator to make a locator for the resources inside xam.xex.
But since our xam won't have those resources I've made it point them to a local file instead (by passing 0 as the module param for XamBuildResourceLocator).
The resources will have to be extracted to the XEX's local path for it to find them though (and XEX will need to have media:\ symlinked too)
The XamFormat*String exports are really windows-only right now, but they'll at least empty the buffer for other platforms.
They'll also always output MM/DD/YYYY no matter what locale the system is, on 360 this is localized properly of course.
I've renamed XamBuildSharedResourceLocator_ to XamBuildLegacySystemResourceLocator too since that seems to be the proper name for it.
In earlier Xams this just pointed to ...SharedSystemResourceLocator (as does this code), but later versions seem to have their own function.
Just changed the existing XamNotifyCreateListener import to ...CreateListenerInternal, and made a new XamNotifyCreateListener that just calls the internal version.
Also changed name field of DeviceInfo to be a wchar_t* of known length, makes it match the X360 DeviceInfo struct more closely and it's easier to make sure things reading it won't overflow anything.
- Convert http to https, provide archive link when possible.
- Made CPU-JIT.png more readable on dark themes;
Added a white background so there isn't black text on a black
background.
Like said in that issue, it seems the limit passed to XamContentCreateEnumerator is actually a limit on how many results XamEnumerate should return per call, not a limit on the number of enumeration items in total.
These changes fix Sonic Unleashed not loading more than 1 DLC (it passes 1 as the limit, but then loops over XamEnumerate to load in each DLC one at a time), and likely many other games.
Code is mainly just copy/pasted from kernel/util/xex2.cc, I've tried fixing it up to work better in a class, but there's probably some things I missed.
Also includes some minor improvements to the XEX loader, like being able to try both XEX keys (retail/devkit) automatically, and some fixes to how the base address is determined.
(Previously there was code that would get base address from optional header, code that'd get it from xex_security_info, code that'd use a stored base address value...
Now everything reads it from a single stored value instead, which is set either from the xex_security_info, or if it exists from the optional header instead.
Maybe this can help improve compatibility with any weird XEX's that don't have a base address optional header?)
Compressed XEX loader also has some extra checks to make sure the compressed data hash matches what's expected.
Might increase loading times by a fraction, but could save reports from people unknowingly using corrupt XEXs.
(still no checks for non-compressed data though, maybe need to compare data with xex_security_info->ImageHash?)
