Removing syscall() from OpenBSD

Removing syscall() from OpenBSD

Yeah, the built-in Windows component that performs "the C library"'s function of communicating directly with the kernel is NTDLL.DLL.

It's instructive to read up on what-all NTDLL.DLL provides, because it started out, back in the days of NT 4.0, as a "just the system calls" shim under KERNEL32.DLL, like someone was saying we should have over in Unix land. But look at the actual file "c:\windows\system32\ntdll.dll" in a current-generation Windows. It's bigger than libc.so.6. If you dump out its symbol table, it provides a whole lot of functionality besides the system calls.

This is for practical engineering reasons. NTDLL.DLL is the only piece of code that is guaranteed to be loaded into every user space process, and that means it's the logical place to put functionality that every process needs, no matter what — such as the dynamic loader. Well, it turns out that a dynamic loader is a big Twinkie with a lot of dependencies, because it needs a heap allocator, it needs to be able to report errors, and it needs to be tied so intimately into the thread library that it's easiest to make it be the thread library. All by themselves those things add up to most of a conventional "language runtime". And then once you have that, inevitably it suffers feature creep.

I have occasionally thought about what a minimal "just the syscalls" shared library, that all the post-C languages could agree on, would look like, and, well, I think the only plausible way for it to be truly "minimal" and "language-agnostic" is if we somehow move the dynamic loader out of process. That would be worth doing for various security-related reasons as well, but it needs a bunch of new kernel API (so it can manipulate an arbitrary process's memory map without becoming that process's debugger), and it might be unacceptably slow, and it adds, um, challenges to system boot.

(It might be interesting to think about a different split, though, in which we divide all of ISO C + POSIX functionality into "everyone needs this" and "only programs written in C want this", accepting that much of the "everyone needs" pile will retain a certain C flavor to it. I don't know if it would be worth doing, I would have to take the time to make the lists.)