No End to DLL Hell
drdobbs.com
drdobbs.com
For anyone trying to debug building problems, see this stack overflow question which shows, judging by the upvotes, that many people were bitten by this (people still upvote the answers there, still getting hit by this, after 2 years): http://stackoverflow.com/questions/59635/app-does-not-run-wi... .
A lot of code uses ATL. Imagine if Microsoft had been able to update a few ATL DLLs and close the hole for every app written to dynamically link to ATL. Instead, the dynalinkers were no better off than the static linkers. No wait, they were worse off.
So arguably it was exactly the static linking (forced by the language) that was at fault here. People who linked dynamically were forced to make some painful changes, but those who linked statically potentially had the security bug left in their programs. I'm not sure who of the two would be worse off here. I guess at Microsoft they considered the security implications severe enough to warrant a patch as disruptive as this one was.
Well… they could if only they had aptitude… and a repository for 3rd party's source code. I guess there's no easy way out, then.
They were very, very close to a working versioned symbols system.
If community doesn't exists at all - this is not gonna work and it's better to enclose everything in your app.
I believe, community thing, in sense like it exists with open source projects, will not exists for any private software, so when you create something based on MS stack, or something which do not have open sourced codes - stick to "keep everything with app" way.
But, of course, I would like to see more opensourced software and propose opening code for the whole stack to avoid this kind of problems =)) Ah.. dreams =)
According to hippich (and I agree), that kind of community and spirit only ever emerges when we are sharing code.
How does Ruby or Python keep track of old versions of libraries? How does it ensure that, when you start a program, the exact library is used that the application was written and tested against?
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.
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.
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).
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.
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.
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).
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
06/03/2009 03:34 PM <DIR> . 06/03/2009 03:34 PM <DIR> .. 02/18/2009 11:39 AM 540,672 System.Workflow.Runtime.dll 1 File(s) 540,672 bytes
Total Files Listed:
70492 File(s) 17,392,399,667 bytes
54416 Dir(s) 3,145,158,656 bytes freeSo 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.
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.
That said, I ship my own software with all required dll's in one directory, too.
Really, too fucking late eh?
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.
On Linux at least people some how agreed that system version is for the better, and works there.