Historically this would not have been especially easy for microsoft to do, since windows was not really designed with the idea of locking out all syscalls. And

Historically this would not have been especially easy for microsoft to do, since windows was not really designed with the idea of locking out all syscalls. And for many purposes (not including hard-core sandboxing) the existing windows security mechanisms were considered good enough. This would be quite possible for Microsoft to implement on top of their pico process architecture (only microsoft can implement those drivers, with prevention measures like locking down the registration system before any third party drivers are loaded), since for a picoprocess all syscalls get handed off to the pico provider, which can ensure that no regular syscall can remain directly callable, and provided only the set of specially designed synchronization system calls. But there are still challenges. Your no DLL rule means that these system calls must have a stable ABI, since statically linked code will be used to call them. (Or alternatively you are forcing the using app to manually create a file mapping of relevant dll, and act like a dynamic linker to get application code linked with that.) But fundamentally it is just a decent chunk of engineering effort, only became realistically feasible with the introduction of pico processes which is relative recent in the overall lifespan of Windows, does not have especially high demand, and is not a something that enables some exciting new end user feature that makes it worthwhile to implement despite limited demand.