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.
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?
Of course you can. Just go through the system DLL like any other program.
> What kind of thunks and security vulnerabilities are you talking about though?
Something like http://xorl.wordpress.com/2009/08/07/cve-2007-4573-linux-ker..., though that's not the only one.
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.