This thread will not actually execute instructions, it will only advance the timing/events and try to yield immediately to the next ready thread, if there aren't any ready threads then it will be rescheduled and start its job again.
Replace all the C-style complicated buffer management with a std::deque.
In addition to making the code easier to understand it also adds support
for non-POD IdTypes.
Also clean the rest of the code to follow our code style.
This will happen when the mutex is already owned by another thread. Should fix some issues with games being stuck due to waiting threads not being awoken.
Each archive now takes a mount point of either NAND or SDMC, and builds its own directory structure there, trying to simulate an HLE-friendly hardware layout
This is to better represent the hardware layout, they are still aren't quite accurate, but this better and will help a bit when implementing the other archives like NAND-RO and NAND-RW
This allows Steel Diver to boot further, some files are needed.
This is still not ready and needs a big cleanup, this will possibly be delayed until the way we handle archives is fixed (with factory classes instead of ahead-of-time creation of archives)
Stubbed CreateMemoryBlock
Using Berkeley sockets, and Winsock2.2 on Windows.
So far ftpony creates the socket and accepts incoming connections
SOC_U: Renamed functions to maintain consistency
Also prevents possible scope errors / conflicts with the actual Berkeley socket functions
SOCU: Close all the opened sockets when cleaning up SOCU
They will be stored in /extsavedata/SDMC and /extsavedata/NAND respectively.
Also redirect some APT_A functions to their APT_U equivalents.
Implemented the gamecoin.dat file in SharedExtSaveData in the PTM module.
Implemented formatting the savegame.
Retake a previous savegame if it exists instead of reporting them as not formatted every time a game is loaded.
This handle manager more closely mirrors the behaviour of the CTR-OS
one. In addition object ref-counts and support for DuplicateHandle have
been added.
Note that support for DuplicateHandle is still experimental, since parts
of the kernel still use Handles internally, which will likely cause
troubles if two different handles to the same object are used to e.g.
wait on a synchronization primitive.
Yuri Kunde Schlesner