Hacker News Reader

Comment by elblanco | Hacker News Reader

Considering how cheap storage is today (~$65/TB) is there really a reason to use shared DLLs in this day and age on the desktop?

View on HN

Yes, so that one component can be upgraded and be used by other programs. Recall the zlib bug of a few years ago. Everybody who linked zlib statically had to provide a new build (or include the fix in their next release). There have to be thousands of applications out there who weren't upgraded (old version, vendor out of business, whatever) and who are vulnerable to a years-old security flaw.

That said, I ship my own software with all required dll's in one directory, too.

I must be too late to the party, because I have just discovered that joy that is Java and WebStart.

Really, too fucking late eh?

> who are vulnerable to a years-old security flaw.

That's an interesting point I hadn't considered.

I had always operated under the assumption that DLLs were a design compromise to allow code reuse on systems with relatively constrained storage.

All that being said, I still run into problems with missing or version mismatched DLLs quite frequently. It seems particularly bad with software provided by the O/S community, but there's a fair number of commercial programs where I run into these issues as well. The obvious solution to me is to just ship with all required DLLs (when possible) and install them in the local path for your app. Nobody is really going to notice another few MB missing these days.

This is no guarantee. There is no standard lib library/dll on Windows. Not everybody would install it in system32, and sometimes it's compiled with flags the standard distribution is not.

On Linux at least people some how agreed that system version is for the better, and works there.

Ideally, when a bugfix or security update is applied to the shared DLL, your application immediately benefits and you won't have to roll out your own update. I would imagine that some 3rd party enhancements (plugins, for example) also rely on shared DLLs.

Aren't dynamic loading (for plugins etc.) and dynamic linking two different things?

Depends on the exact definitions. 'dynamic loading' (whic I would define as with ::LoadLibrary() ), is a subset of 'dynamic linking' because dynamic linking can be done explicitly (with ::LoadLibrary()) or implicitly by the application's startup code, which is generated/inserted into the executable by the linker.

Then again I wouldn't have a problem with someone defining the terms differently so that they are the same or overlap in a different way. I wouldn't say though that they are very different - they are related no matter how you slice it.

For dynamically loaded plugins (or extension modules or whatever you want to call that feature). And because of some weird misfeatures of windows dynamic linker you pretty much have to break your application into pile of discrete DLLs if you want to dynamically load anything useful (or pass pointers to huge structs of pointers around, as is done by JVM's JNI).

Not if you are on SSD. Also not if you want VMWare image of the OS to run all simualtenously on the same machine

Reply on news.ycombinator.com