Comment by quotemstr | Hacker News Reader

Comment by quotemstr | Hacker News Reader

Parent Full thread

I've worked extensively with both ELF and PE systems --- I was on the Windows Perf team and the Windows Phone core team, and now I do low-level Android goo at Facebook.

I vastly prefer the Windows shared library model. In addition to the advantages you mention, the Windows per-DLL symbol namesystem system is much better than ELF's hazardous model: in ELF, accidental interposition is a big hazard, so you have to very carefully namespace the symbols exported from a shared object. In Windows (and in OS X), symbol name collisions are simply not a problem: there's no global namespace in which symbols can collide. Yes, you still have DLL _name_ collisions, but SxS addresses that problem nicely. As a result, hosting unrelated bits of code in the same process is very common in the Windows world and uncommon in the ELF world. RTLD_LOCAL and RTLD_DEEPBIND are completely unnecessary.

Another advantage Windows has in practice is default symbol visibility. Windows DLLs export only the symbols you explicitly instruct your compiler and linker to export --- through export files or compiler annotations. The default in ELF systems is to export everything that's not file-static. This configuration is particularly fun when combined with the namespace problem. While Unixish compilers can be configured to work like Windows and export only needed symbols, I've found that very few people do. These people then go on to wonder why shared libraries are slow and the binaries so large. (-Bsymbolic helps, of course.)

If I were benevolent POSIX dictator for life, one of my edicts (although not my first one) would be to require an OS-X-style two-level namespace and hidden symbol visibility by default. Yes, LD_PRELOAD interposition gets harder. Just deal with it and modify functions directly.

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.

Also, it's a minor thing, but LoadLibrary in Windows returns a pointer to the PE header. dlopen is nowhere near that simple, nor is the in-memory representation of a shared object as useful. (It'd also be nice if dladdr1 got some documentation. Also, it'd be nice if Bionic weren't even more awful than glibc in this respect.)

> The default in ELF systems is to export everything that's not file-static.

...and then import them all again, even when they're in the same file, which I think is one of the most bizarre aspects of the ELF mechanism - I can certainly see that it allows the extra flexibility of overriding functions, but I've never thought "I'd like to be able to easily replace any function in my application with one from a library". I don't imagine it's a common use case, since on Windows it would be the equivalent of having a PE import itself (is this even possible?)

> 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?

> Wow, really? So you can't make system calls from assembly language on Windows?

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.

Reply on news.ycombinator.com