- https://www.mdsec.co.uk/2022/04/resolving-system-service-num...

- https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisp...

- https://whiteknightlabs.com/2024/07/31/layeredsyscall-abusin...

Though I'm not sure which of these techniques, if any, would be most favored by a game DRM as I've never looked into it.

Some operating systems have massive fan-in and fan-out on what is internally one single system call crossing the shell/kernel divide. Witness how much is done by sysctl() on the BSDs, for example. Whereas others will be more 1-to-1.

Then there's the fact that the Native API for Windows NT is structurally very different to the Linux API (as they are both different from, say, XNU). It's basically entirely coincidental that the numbers are even close, and there are no general conclusions that one can draw from such statistics.

Except, perhaps, a general but rather facile conclusion that these operating systems aren't running on 8-bit processor architectures. (-:

That said, for those particular API functions there is an interesting history that is, rather, about mitigating security holes:

* https://www.tiraniddo.dev/2020/05/silent-exploit-mitigations...

You got three common suffixes for function names in Windows. A and W relate to the encoding of the string parameters - A refers to the strings being encoded in plain ASCII, W to UTF-16.

And Ex, 2, 3, whatever - these refer to extensions with different parameters. Like, the "original" function may have had only two parameters or a tiny struct, but for more modern usecases they might have added a few parameters, expanded the struct or, even worse, re-arrange fields in the struct.

Now, of course they could have gone the Java/C++ path - basically, overload the function name with different parameters and have the "old" functions call whatever the most detailed constructor is and set default values for the newly expected parameters (or convert, if needed). But that doesn't work with C code at all, which is why the functions/syscalls have to have different names, and additionally the Java/C++ way imposes another function call with its related expenses while having dedicated functions/entrypoints allows for a tiny bit more performance, at the cost of sometimes significant code duplication.

And on top of all of that, MS has to take into account that there are a lot of third party code that doesn't use ntdll, user32 and god knows what else is supposed to be the actual API interface, but instead goes as close to the kernel as possible. Virus scanners, DRM solutions, anti-cheat measures, audit/compliance tools - these all hook themselves in everywhere they can. It's a routine source of issues with Windows updates...

In hindsight a silly idea, trading off security for a speed boost.

Aero introduced accelerated compositing: https://learn.microsoft.com/en-us/archive/msdn-magazine/2007...

And WPF and subsequent toolkits follow a more modern model of "application draws into its own RAM region using DirectX which is then composited into the desktop".

And the criticisms were the contemporary 1990s criticisms of microkernel designs, namely that all of this message passing was slow. (In reality, this is a red herring in most critiques of microkernels. In systems ranging from AT&T STREAMS to Windows NT today, I/O subsystems are built anyway around the idea of passing request packets around, be they mbufs or IRPs.) So it all got moved into the kernel, and then some of it in later versions got moved back out again, and rearchitected when windowing became more about compositing multiple whole bitmaps that could be constructed locally rather than drawing into a shared area with lots of clip rectangles.