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.
>The only system calls that the calling thread is permitted to make are read(2), write(2), _exit(2) (but not exit_group(2)), and sigreturn(2). Other system calls result in the termination of the calling thread, or termination of the entire process with the SIGKILL signal when there is only one thread. Strict secure computing mode is useful for number-crunching applications that may need to execute untrusted byte code, perhaps obtained by reading from a pipe or socket.
https://docs.microsoft.com/en-us/windows/win32/api/enclaveap...