Hacker News Reader

Comment by millstone | Hacker News Reader

Imagine writing, say, Firefox, without dynamic linking. You would have to provide a separate version of Firefox for every version of the OS, and when the next version of the OS is released, your current Firefox would stop working!

It's not about saving memory or disk space (although those are still very significant, especially on mobile). It's about allowing a program's components to evolve separately.

View on HN

I don't understand why you would need a separate version of Firefox for every version of the OS?

Consider Copy/Paste. This is a system feature, and all apps must agree on where the clipboard is and how to access it. If the system implementation of the clipboard changes (say, in the next OS), then apps that statically linked against the old implementation will not be able to Copy/Paste with those in the new implementation. You also have the reverse problem: apps compiled against the new implementation will break when run on the prior OS.

Dynamic linking is one way to ensure that all apps automatically get the correct clipboard implementation for the system they are running on. Of course this applies to all system features, not just copy/paste.

I'm not saying you can completely avoid integrating with the OS (after all, you need to communicate with the OS if you want to run). I'm saying that if you use something like libjpeg, you should statically compile it in. Application libraries should be part of the application (system libraries, then, should be part of the system).

For sure, I agree. There's not much cause for bundling a dynamic library with your app. But you still need dynamic linking for the system.

Of course C++ is really terrible at this. Its binary interface is very fragile: you can't add variables or virtual methods without breaking clients, and of course different STLs cannot interoperate. So for the case of C++ specifically, ABI compatibility is lipstick on a pig. Still, the gcc guys deserve props for their abundance of caution, and it does pay dividends for other tools (e.g. gdb) that have to understand the ABI.

For one, on some OS's (like Windows), the syscall interface is unstable, so you really want to use kernel32.dll and friends or you're signing up for pain. Even if you're on an OS with stable syscalls, there are plenty of vendor-specific DLLs you have to work with: GPU drivers, for example.

>For one, on some OS's (like Windows), the syscall interface is unstable

True but if someone is dealing with syscalls on Windows they're programming something very unusual.

>so you really want to use kernel32.dll and friends or you're signing up for pain.

Why? There is no pain involved unless a function that isn't implemented in older versions is imported.

You don't have to use syscalls directly. If you statically link a library that makes system calls, then a syscall interface change will break your app. But if you wrap all system calls in a dylib, then that dylib insulates you against syscall interface changes.

Syscalls are irrelevant for almost everybody programming Windows applications. I didn't write about Mac OS X.

On Windows at least, all the common controls and the file dialogs are dynamically loaded, because they can be different across different versions.

The file open/save dialogs embed Explorer and all its shell extensions, each of which is a DLL. These can vary from system to system.

Something similar is present on Linux with libnss; if you want to do username-userid lookups, you have to load the relevant libraries at runtime.

Reply on news.ycombinator.com