Open LukeUsher opened 8 years ago
This, or keep a compatibility-layer in between ;)
Even though this issue makes perfect sense, forwarding Xbox kernel calls to NtDll is currently the quickest way to get them implemented.
Once we have enough of the kernel implemented, it can function as a foundation, so we can focus on other stuff that's also a lot of work.
Later on we can revisit the kernel and implement more of it ourselves, instead of leaning on the host OS.
But as stated already, that will be an insane amount of work, while probably only relevant for some very specific scenarios in certain titles, or ports to non-Windows OSes. Both of these are a long way off for now.
This is becoming more relevant now that our kernel is on its way to being implemented more completely.
Even so, not a single kernel object type is currently supported well enough by our kernel to switch over to it. So, until the Ob, Ke, Nt and other API's are implemented well enough, we still have to rely on NtDll forwards.
The method Cxbx uses to emulate the Xbox kernel involves redirecting as many NtX kernel calls as possible to the user mode implementations contained in NtDll on Microsoft Windows.
NtDll is an internal library and is not meant to be called directly by user applications, but by API functions that user applications call, because of this, the behavior of these functions is not always consistent between operating system versions.
Ideally, we should never call NtDll but instead implement the kernel functions ourselves. Wine and ReactOS may be good references
NOTE: This is a long term goal, as replacing these calls is an insane amount of work at this point, but necessary for both consistency and potential future portability to non-windows systems.