> The ELF dynamic linking mechanism is designed to emulate static linking. That's like designing cars to neigh and occasionally kick people to death with robot legs that exist only for this purpose.
So I'm only passingly familiar with the state of OS's back before I was born, but between "your code works unchanged between static and dynamic linking, you just have to change your build system which is already OS dependent" and "how you export and import symbols in the source code varies depending on how you're linking and also which OS you're building on and which compiler you're using", the former seems less insane.
Sure, but static linking isn't dynamic linking. Pretending that it is has done much harm, but I don't think it's led to demonstrable benefits. If you want to split a single module into two dynamically-linked parts, you need to define the interface between these parts anyway for versioning purposes. If you're doing that work anyway, it's not hard to add export tags at the same time.
You're right, though, about history being a factor. Windows was born with dynamic linking; shared libraries were a Unix bolt-on. (Then again, symlink was a bolt-on feature too, but it's well-integrated these days.)
It's also interesting to note that on Windows, there's no such thing as a static executable in the sense you might have one in Unix. Every system call must go through ntdll.dll or it'll stop working on the next major upgrade, which will scramble the system call numbers. On Windows, the ABI compatibility boundary is ntdll/kernel32/user32/etc., while on Unix, the ABI boundary is the kernel-userspace boundary.
The Windows way of doing it is much better. It places fewer constraints on the kernel and lets you implement 32-bit-to-64-bit system call thunks entirely in userspace, completely avoiding a major class of security vulnerability.
> Every system call must go through ntdll.dll or it'll stop working on the next major upgrade, which will scramble the system call numbers.
Wow, really? So you can't make system calls from assembly language on Windows?
> It places fewer constraints on the kernel and lets you implement 32-bit-to-64-bit system call thunks entirely in userspace, completely avoiding a major class of security vulnerability.
Well, there is VDSO. What kind of thunks and security vulnerabilities are you talking about though?
So I'm only passingly familiar with the state of OS's back before I was born, but between "your code works unchanged between static and dynamic linking, you just have to change your build system which is already OS dependent" and "how you export and import symbols in the source code varies depending on how you're linking and also which OS you're building on and which compiler you're using", the former seems less insane.