Did someone say
HBL MEMORY MANAGEMENT?
HBL has a pretty simple memory setup, and it shows when you start using stuff like TCPGecko and HID to VPAD that have the sheer audacity to leave the safety of Mii Maker and venture into the heap-centred madness of the world beyond. In essence, HBL tells the PowerPC to take a bit of memory that's usually allocated to root.rpx and point 8MB starting at address 0x00800000 to it. This basically means that when you try to read, say, 0x00800004, the PowerPC translates that to 4 bytes into this root.rpx area and reads there. This works well enough, and it means that HBL has its own dedicated little bit of memory at address 0x00800000 all to itself (a rarity in Cafe OS).
To load an application, HBL just copies it to
0x00802000 (the extra 0x2000 bytes are for HBL's internal use) and runs it. It does this every time you load any application, with no changes and no changing addresses. 0x2000 bytes into the region, every time.
Hopefully you can start to see the problem here.
If I open HID to VPAD, it gets loaded into 0x00802000. It then sets up its patches, returns to the main menu, and sends me on my merry way. I can open any native Wii U app I'd like and the HID to VPAD code stays put; the 0x00800000 memory area is
dedicated to HBL, so other apps don't affect it. So, what happens when I try to run another HBL application? HBL does what it always does - load up the file, copy it to 0x00802000, and run it. This works fine and does exactly what you'd expect for
any other application, but stuff that has patches like HID to VPAD or TCPGecko have modified bits of code
outside of the HBL area to run bits of code that are
inside the HBL area. So, when the well-intentioned HBL goes and overwrites the HBL memory area with the new application, all those bits of system code that were once pointing at HID to VPAD are now pointing at goodness knows what and it all goes down the toilet very quickly from there.
This boils down to one simple fact - HBL can only hold one application in memory at a time, and every application expects to be in the same spot in memory. Considering what HBL was meant for, this is exactly what you'd expect - application, back to the menu, new application with no trace of the old. However, we've now got homebrew that doesn't fit this mold, and HBL has no way to deal with this. Short of moving to RPX (which would still cause problems, but with code that we
didn't write) or setting up their own memory area (which Maschell already stated he doesn't want to do), such homebrew really doesn't have another option here. They just have to claim incompatibility with HBL applications and call it a day.
As for solutions, the native RPX loader can handle several executable files at once (although putting homebrew here may cause problems with app switching, a fatal problem for patching homebrew) and each app can set up their own memory area (which gets complex quickly). I started a project a little while ago that aims to unify all these apps into one memory area (separate to HBL) while also making them compatible with each other, although I haven't really been doing much with it lately (motivation, woo-hoo!).
So yeah, hopefully that helped your understanding of how this works on the backend. You can see how clashes occur so easily and why it's not an easy problem to fix.
