Hey,
I've read several parts of your documentation to give you a better answer.
What is good is that you point out in "Chapter 4: Browserhax, Kernel, and IOSU" that this is not the "normal" coding and that you get a way cleaner environment if you have an entry point at the beginning of an application. Unfortunately it requires kernel exploit to have the access to do that kind of entry point at the moment.
But there are quite a few points that are gonna misslead people on how to code for WiiU as those are not common ways to do it. Those are mostly true only for the browser exploit environment.
You chapter "The Mystery of the Missing Standard Libraries" is wrong. You do have those and you can use them. You just dont do it because you dont link them. Linking that code actually increases the binary size by a lot. That is one reason why not many use those. Also some parts require a proper definition of a malloc, memalign and free function and those require a re-implementation with a wrapper inside your code as those were written for the Wii.
My applications do actually use the C and C++ STL libaries. They are all compiled or included as headers in devkitPPC (some C++11 stuff are missing but thats because devkitPPC is old already and no one does update it anymore). Stuff like stdout and stderr have to be adjusted to something different like on screen console manually in your program but even that is quite easily doable and you can use printf() for example to output text to the on screen console or to a network connection. You just need to know hot to work with devoptabs on devkitPPC to make that possible. Thats what I did for the FS access to actually be able to use FILE* in C or std::fstream in C++ to access the sd card. Would work similar for console but on devoptab STDERR and STDOUT with less functions required than on FS (you could also see SNES9xGX for an example).
Another point which is also not "normal" programming are all those function pointers from the RPLs. We only use them out of convience because they give us the hardware access we need. Nintendo made those great dynamic libaries which allow you to use their code very easily for your purpose. That is also the reason why we don't have to rewrite all those IOS ioctlv accesses and other implementations of hardware accesses (through IOS or direct hw registers). It's way simpler to use the ready to use code. You have the symbols of the functions and even a function to find the symbols. Its all served on a silver plate and cant get easier
.
So that is the only reason we need those function pointers. We need them for hardware access (even just console output on screen which accesses the graphic hardware in a way). In normal applications you would not code with function pointers (mostly only for callbacks). They need 3-4 instructions where you would usually only need 1 instruction. Functions like __os_snprintf are actually not needed and the normal snprintf from libgcc can be used (C libraries can be used as described above).
The most missleading parts to "coding for WiiU" are those stuff:
These two assembly lines of code are something way out of the ordinary programming most people do. They forcefully change the stack pointer to a different position. This is required on the browser exploit because it has no clean stack on entrance and that enviroment does not have access to many memory regions. So it is set to some region where it has access to overwritting some (luckily) unused regions. To be honest I cant even tell how much stack we have there as I never made looked it up or made tests.
asm(
"lis %r1, 0x1ab5 ;"
"ori %r1, %r1, 0xd138 ;"
);
Those lines signal the foreground application that you want to shut it down:
IM_SetDeviceState(fd, mem, 3, 0, 0);
IM_Close(fd);
OSFreeToSystem(mem);
The application then starts to stops its running threads on core0 and core2. Core1 threads are most likely not shutdown as the exploit application is occupying it. Only threads whith higher priority on core1 could theoretically shutdown if the scheduler switches context to them (which it should).
In normal application you would not need that.
Same goes for these lines:
OSScreenSetBufferEx(0, (void *)0xF4000000);
OSScreenSetBufferEx(1, (void *)0xF4000000 + buf0_size);
You assign the screen buffer hardcoded MEM1 addresses. Of course this will cause crashes if GX2 for is still running on the browser which is using those MEM1 addresses. Thats why you shut down the running threads with the above command.
Normally you would cleanly allocate that memory marking it as "occupied".
Another point which I didnt find in your documentation is that usually you dont have any kind of static or global variables in the browser exploit code. This results from the fact that it just doesnt copy .data section with the exploit as it doesnt know where to. You could actually achieve it with loading the .data and .bss sections after the exploit is running but thats also nasty hack like the stack pointer change too. On normal applications you just can use those.
Well those are main points that came into my mind when I read your doc.
To tell you the truth, writing a WiiU application isn't much different than writting any other standard C/C++ application for a linux system. You just have to use different functions to access hardware or communication with the I/O processor but a lot is the same. The parts where it is not the same because you access some specific memory region or doing changes to stack is where hacking starts and homebrew "application" ends.
