Hey, well its not that I think that the compatibility is not important. Just as I said in one of my previous comments, its really not fun developing on something so instable. Its really annoying when it freezes all the time and you have to hard reset your WiiU each time you do a little change. That is why the other stuff, the base implmentations for easy development, is more important to me.
Nevertheless here is a little peek into its development:
I did dig into that stuff. It requires us to revert the "kernel exploits" changes to the kernel memory setup table. At first I though we dont use the setup memory region by those changes anyway anymore so I though we only need to revert the table to its original state and thats it, but I forgot that we actually use the memory setup by it for storing the RPX file temporary into and load it from there in the loader later.
The kernel setups the MMU from that kernel memory setup table. It maps a physical address to an effective (virtual) address with permisisons and gives us (user mode usually) access to some memory regions. Since all 8 DBATs are in use by the system for different purposes and variate in their positions from application to application, we can not just setup a common DBAT to some fix position for our code running. Our code is in background in every application and doing data accesses to the same physical memory area, so it must be a permanent (run time) change which stays there for all applications. Well the other option left is to setup a segment register with the corresponding PTEs in the PTEGs table for our memory access as those do not variate and are fix in overall WiiU run time. This process is relatively complex compared to the setup of the BAT registers which are not very simple themself. Well, I have already implemented the algorithm to setup PTEs for a segment register of my choice and the memory area of my choice. So I can setup us a segment register and we can remove the kernel memory table modifications. And that is the only thing left to implement (its only a few lines of code). But than while testing it I got really pissed when it froze again after having frozen several times in some tests before because of some simple mistakes and I had to hard reset the WiiU again and then the freaken kernel exploit didnt want to work etc....so I though f*ck it for the day and went to bed at like 2 or 3 o'clock in the morning. As that was really annoying and not fun at all and it is only for one game, I started working on something that actually will make my life easier by writing bases for easy development before continuing with stuff that can not be logged and freeze because of every little mistake you do. Stuff that actually are fun to code.... I will continue my work on that eventually but for now I am working on the stuff that me and many developers will benifit from also and not just the users (it might be a bit egoistic but oh well, the other stuff was really annoying me
).
So to sum up, this whole text is just a little peek into how the development is going on and to explain you (and the other that think what I do now is only "nice to have") that it is really annoying to code for the WiiU at the current state with the current kernel exploit and I dont have the time to actually search for a better exploit either as there is so much other more important stuff to do too, so I always say "mah...maybe later..." knowing that another more stable exploit already exist and some people use it but dont give it out to the public (I dont have it). The changes might look from the users side like its a "nice to have" but it is not a "nice to have" for me and probably many other developers, its needed to not go nuts developing with such a crappy development environment and loose the interesst in the work quickly.