
No End to DLL Hell - bdfh42
http://www.drdobbs.com/windows/227300037
======
roel_v
He didn't even mention some of the fun tricks that Microsoft pulled with the
versioning of the C and MFC runtime dll's. For example in the summer of 2008
with the release of SP1 for Visual Studio 2008, they included a security fix
in ATL that required a new runtime. Now all of a sudden all applications build
with the Visual Studio that included that SP required different runtime dll's
to be deployed. Double the fun when you have a bunch of dll's that require the
'old' version (no SP) and some that require the new one. You can't ship them
in the same directory because they have the same name.

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...](http://stackoverflow.com/questions/59635/app-does-not-run-with-
vs-2008-sp1-dlls-previous-version-works-with-rtm-versions/) .

~~~
dmethvin
So sad, because that could have been the DLL's finest hour.

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.

~~~
roel_v
To elaborate, the rub here was that ATL heavily relies on templates, code that
is instantiated by the client at build time. The fix (IIRC but I don't see any
other explanations either) required a change in one of those compiled-at-
build-time parts (i.e, in the header), and was of such nature that it changed
the ABI. If the part that had the bug had been able to be included in a dll
(but it couldn't be because of the way templates work), swapping out the dll
would have worked.

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.

------
Symmetry
Reading that mostly made me appreciate how much my Linux Distro does for me.

------
loup-vaillant
Microsoft can recompile the relevant programs when the new DLLs aren't binary
compatible, then push those new binaries along with the core update…

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.

~~~
mikemol
Windows SxS was supposed to ensure that programs would get linked to the
latest version of a DLL that the program would be compatible with. There are
even conditional forwarders set up for it. You could have a program that would
only link against the oldest version, if it needed to.

They were very, very close to a working versioned symbols system.

------
hippich
After reading this.. It's all about community. If community can agree on API
you can create something shareable like DLLs and it will work for all at
benefit.

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 =)

~~~
roel_v
I don't understand how a 'community' would help here. When the ABI of a dll
changes (which it will at every major release, and it's a major pain to keep
it compatible even between small releases - I don't know of any projects that
even try), you need some way to communicate this change to any applications
that use it.

~~~
djacobs
I definitely get what hippich is saying. The idea is that when you have a
community built around a platform, and that community is, well, communal
(cooperative in some ways), solutions emerge to avoid conflicts and problems
like this. (RubyGems for Ruby, CPAN for Python, aptitude for Debian, RPM,
etc., etc.)

According to hippich (and I agree), that kind of community and spirit only
ever emerges when we are sharing code.

~~~
hippich
roel_v, just like he said =) (except, CPAN is for Perl =)). Probably, API is
incorrectly referenced here. But idea is - if something really shared,
community using this something shared will be able to find a way to avoid
conflicts.

~~~
Someone
Another way to describe some of that community effort is 'work very hard to
bury conflicts so deep that, ideally, nobody will find them'. As an extreme
example consider ./configure

------
AndrewDucker
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.

~~~
mapleoin
Doesn't that defeat the purpose of using DDLs in the first place?

~~~
cstuder
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.

~~~
wzdd
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.

~~~
ciupicri
Why should I waste bandwidth because DLLs aren't shared anymore?

~~~
roel_v
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).

~~~
ciupicri
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.

------
hippich
One page -
[http://www.drdobbs.com/article/printableArticle.jhtml;jsessi...](http://www.drdobbs.com/article/printableArticle.jhtml;jsessionid=ZTPGFQCDLF2CFQE1GHPCKH4ATMY32JVN?articleId=227300037&dept_url=/windows/)

------
mkramlich
Hopfully enough folks have swung around to the Batteries Included approach
(bundling dependencies inside the app's disk footprint) that DLL Hell will
eventually die out. Plus both disk and memory space has gotten much less dear
over the last 30 years, so conserving and treating every byte as sacred is no
longer as important as not having one's software break in mysterious and
painful ways.

------
jimbobimbo
Ah, lovely manifest problems! It's truly a new hell today for C++
applications.

