Re: Manifest Hell - a thing of the past?
"David Webber" <dave@musical-dot-demon-dot-co.uk> wrote in message
news:uy$ME5K$KHA.3840@TK2MSFTNGP02.phx.gbl...
2. With "DLL Hell", I never understood what anyone was talking about. I
just put the MFC and CRT DLLs in my program directory since the first MFC
version of my program released in 1996. Never had any problems at all
until VS 2008 and manifests. Never. And I have never caused DLL Hell
for anyone else by replacing someone's versions of MFC etc with the ones I
am supplying.
Putting the DLL's in your program directory is called App local
installation. You are right that it never caused, nor was it a victim of,
DLL Hell. So you got a free pass! :-)
DLL Hell was caused when the DLL's in c:\windows\system32 were overwritten
by other people's installers or Windows Update or whatever, and these new
DLL's were incompatible with the ones your app was linked against.
Basically it means there can be only one version of each DLL globally
available for everyone's use, and anyone's app can update it. This leads to
all sorts of issues. Microsoft itself has released a couple versions of its
VC RTL DLL's that had bugs in them (I think VC 4 had an issue). Other
people's installers had bugs in them that they would overwrite newer
versions of the DLL's with older ones, they would not update the DLL's as a
set so there were left some old and some new DLL's, etc.)
Unfortunately, to fix the DLL Hell in c:\windows\system32, the manifest
solution made App local installation more troublesome, since for this, you
now had to have manifests in each .exe and .dll explaining which other dll's
it depended on and what their versions were (and not just versions, but
things like public key tokens, etc.) These were generated automatically and
worked fine, so long as you "rebuilt the world" and mainly caused issues if
you built a library or DLL with an old VC++ and wanted to use it as is in
your app built with the new VC++.
3. I too put out service releases of my software, and I can replace the
MFC and CRT libraries easily enough if service releases of those have come
out.
One reason MS pushed so hard for the manifest system is it let them issue
patched DLL's that could override even the ones you had in your program
directory. That's right, if you didn't read Jochen's blog (article "How to
make a really app local installation"), I'll bet you never knew that if
there was a newer version of the DLL's in c:\windows\system32, that when
Windows loaded your program, it would load those newer DLL's into your
program's process and not the DLL's that were in your program directory!
The prime example of why this was desired was the bug in gdiplus.dll that
caused a manipulated image file to be able to crash the app and gain Admin
access.
With all due respect, I don't think you would respond nearly as fast to
rebuild and redistribute your app with the new gdiplus.dll as Microsoft
could do by patching end user systems directly. Even if you did, the change
would not take effect unless your users updated, which again would cause a
delay. So for zero day attacks and other such things, no doubt about it,
manifests which enabled loading an updated DLL instead of the one in the
program file (at the same time retaining compatibility because the manifest
specified which version was originally used) was a key security boon.
Although how much effect this had in every day living I'm not sure, and
apparently so is MS which revoked the manifest system for important VC 2010
DLL's .
4. I agree that lack of good documentation of manifests was a major
problem. Having to rely on the existence of Jochen Kalmbach's Blog (and
find out about it) to find out how to put the dLL's in ones program's
directory just points to how pathetic Microsoft's documentation is (but a
real service to the world - thanks Jochen).
5. With VS 2008, I didn't want to use the Microsoft redistribution SxS
installer, because my software ran on Windows 98, and I couldn't find any
documentation about whether the Microsoft installer worked on Win 98 (an
operating system they explicitly didn't support) and if it did, where it
put things. I have always been particular about NOT replacing people's
system DLLs in the Windows or System directories - see (2). So it was a
real problem for me until I discovered (4).
6. Hard disk real estate is dirt cheap. There is no reason at all thee
days NOT to put MFC etc in one's own directory.
Hard disk space is one consideration. Memory usage is another - if multiple
apps are running e.g. msvcr100.dll from separate folders, each one takes
memory, whereas only one copy would be loaded if they were using the one in
c:\windows\system32. Security is yet another (see above).
Also, one reason to *not* put MFC into your own directory is if you
distribute various .exe's all of which must for whatever reason be put into
their own folders (I.e. all your .exe's don't go into the same folder.)
This happens more often than I originally had thought, in which case app
local installation is not really an option.
7. Looking through the VS 2010 help (and I'm not sure I like the format
but it's early days yet) I did find something which indicated one could
put the MFC DLL in one's own directory, and there was no mention of
needing a manifest. But I didn't find a parenthetic admission in capital
letters that IN VISUAL STUDIO 2008 YOU NEEDED A MANIFEST WHICH WE DIDN'T
TELL YOU HOW TO WRITE BUT WE SCREWED UP AND ARE VERY SORRY SO NOW YOU CAN
DO IT WITHOUT A MANIFEST. Had that been there, I wouldn't have felt the
need to ask for reassurance here :-)
8. Anyway thanks for a lot of good points on this thread: but I am
resolved to do it my own atavistic way and put MFC and CRT in my program's
own directory, as that way I understand what I'm doing, and it definitely
can't interfere with anything else on anyone's machine (which makes me
feel comfortable). After VS 2008 it feels suspiciously easy in VS
2010. All looks clear but I feel there are bad guys hiding behind the
rocks ready to ambush me. We'll see :-)
I haven't created new C++ projects in VC2010 yet, but I believe they still
generate manifest (if for no other reason than the manifest marks the .exe
as it should not run have e.g. registry virtualization enabled), it would be
interesting to see if the manifest contains any dependencies on VC DLL's. I
don't think so, but it would be a good check.
BTW, while I like the protection manifests provided, I did indeed spend days
and even weeks over the years since VC2005 (manifests were introduced in
VC2005, not VC2008, btw) diagnosing problems with manifests containing e.g.
dependencies on 2 versions of mfc80.dll. And it really burned me when MS
introduced the ATL Security Update thing summer 2009 that broke builds and
even releases to customers because MS updated Visual Studio redist without
telling us. So I have been burned and it has cost real money.
But the bottom line is manifests let *you* control which DLL's get loaded
into your app and *no one* can screw that up, especially Joe Blow and his
stupid installer that doesn't check that the old DLL's he's stupidly copying
into c:\windows\system32 are one year older than the ones you diligiently
supplied with your app!
-- David