Actually, as the article itself points out, there's a very easy way to avoid DLL hell - don't share DLLs with other apps.
All of the programs we produce here include all of their DLLs in their own folder. There's nothing shared, so no other program can cause a problem for them.
Two main arguments for using DLLs were saving disk space and saving RAM.
When was the last time you ran out of disk space because of too many DLLs? And nowadays, our RAM is bigger than the disks back then, so that shouldn't be a problem either.
The other main argument is so that bug fixes can be deployed to all affected applications by replacing a shared DLL. The importance of this aspect is also going away now that pretty much everything automatically updates itself via the Internet.
> pretty much everything automatically updates itself via the Internet
But will the vendor care about every update from the system the program is running on? What happens if someone discovers a bug, your system is updated, but vendor a) doesn't care (or doesn't exist anymore) b) linked statically to some library?
You're left with no protection against a known vulnerability, even though the patches are available and published.
It's a trade off between using bandwidth (+ the extra hassles for the auto update infrastructure etc., but that is carried by the vendor) and reducing the risk of deployment issues that may not be caught by QA because they are machine-specific.
Plus, application dll's are in the magnitude of 100's of kilobytes - I 'waste' more bandwidth with the POP3 polling that my phone does each week than that. I would say that in this context the amount 'wasted' is so small that it can hardly be called a true 'waste'. (I rinse my cup before pouring in new coffee. Is that 'wasted' water? Technically yes, since it goes into the dishwasher at the end of the day anyway and reusing the cup during one day doesn't pose a health risk. That 'waste' won't prevent me from doing so though).
Of course it's a trade off, I didn't deny that. I see it just like (micro) optimizations: in some cases it's worth doing it, in others it's not.
Regarding the size of DLLs, some of them are indeed small, but others have a couple of megabytes, e.g. XUL (from Mozilla Firefox), Qt, GTK+. Multiply this with the number of applications and it can be come an issue if you have a slow Internet connection.
also from the article: It is worth noting that DLLs no longer save disk space. In fact, the opposite is the case. If you have a look into the side-by-side repository (found in Windows' WinSXS directory), you will find, that its 5 GB on Windows 7 and even 7 GB on Windows Server 2008, containing 40.000 files with numerous versions of roughly all Microsoft Libraries. That's about 50% of the disk space used by Windows in total. We were needing a solution, but we created a monster
I think this argument is wrong. Those 5GB are of separate versions of each DLL. If program A needs version 1 of a library and programs B and C need version 2, you only have to have 2 files - those of 1 and 2. B and C can share their copy. So they do save space. Now I don't know if it saves as much as the 5GB that the different versions take.
This 5 GB is because there are so many versions. You could argue that they shouldn't be all installed, and that applications should install them on-demand, but that would require major deployment issues at vendors (especially those so small that they don't have specialized deployment engineers). I think the trade off they (=Microsoft) made here is quite reasonable (i.e. use more disk space to prevent deployment issues).
That 5gb is 20gb on my vista 64 bit machine. I have tons of different 64bit, debug and release dlls. Could be from the fact that I have 3 different versions of studio installed? Anyway...it does not serve it's purpose, and only wastes user money - 20gb cost a lot on a latest SSD drive
It's probably not really 20GB. Most of what's in WinSxS is links to files in other directories, often multiple links to the same file, and the Windows shell "Properties" dialog will include every "copy" when calculating total size.
dir c:\windows\winsxs\amd64* accounts for 10829 directories
dir c:\windows\winsxs\x86* accounts for 6163 directories
Total 16gb. So I was wrong, 20GB came from the artist machine I was inspecting the problem. On mine is 16GB
In total here is what I have:
C:\Windows\winsxs>cmd /c dir /s | tail
Directory of C:\Windows\winsxs\x86_wwf-system.workflow.runtime_31bf3856ad364e35_6.0.6002.18005_none_670656a59d28c52a
I don't think there's an easy way to do that -- I bet you could write a fairly simple program with pywin32 to do that. But there's definitely a ton of hard-linking going on in there.
Libraries are still shared among multiple instances of the same process, and just how big are libraries anyway? Most servers run only a handful of (very busy) processes...
That may be true, but RAM is not so limited (even on VMs/servers) that DLLs are worth the extreme hassle. Case in point: Linux (for me) runs much better on a minimal VM than any version of Windows.
Does not compute. Linux too uses dynamic shared libraries, and you can also link programs to a specific version of a .so, or bind it with your binary distribution (see Firefox, Chrome), such binding posing problems to distributions : Debian just dropped chromium from Squeeze exactly because of that.
We can still use a DLL with multiple applications - they're just shared between the different apps, and live with them.
So if I have two apps Foo and Bar that both use PrettyTreeView.DLL, then I just put a copy of it in both projects, and save it in the same repository. Means I can keep the functionality nicely carved off in one place, but I don't have to worry about updating one app and breaking the other.
Also, the DLL is only loaded in as needed - which saves on memory.
Unfortunately, it's a problem which is surprisingly hard to solve for code that uses CRT, MFC or ATL. And it is especially hard, if you link to the code which in turn links to some other version of these libs.
Also if for some reason you would like to deploy debug version along with release. Normally you don't have to, but sometimes to inspect a problem on coworker's machine (say he's an artist, and the dll is some plugin for some editor) and then you end up with installing studio on his machine :(
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.
> 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.
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).
All of the programs we produce here include all of their DLLs in their own folder. There's nothing shared, so no other program can cause a problem for them.