Prev: Resource Leak
Next: Questions about vcredist_x86.exe, (VS2008 redist).
From: Hector Santos on 26 May 2010 05:39
David Ching wrote:

> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
> news:OgWhkPH$KHA.4316(a)TK2MSFTNGP04.phx.gbl...
>> +1, unless you are "master" in understanding manifest, and that means
>> using them, you can get really lost just trying to get applications
>> running probably without extensive debugging and tracing and not even
>> that will help sometimes, unless you know what you doing.
>>
>
> What does it mean to "master" manifests? It doesn't require (much) more
> than mastering DLL versioning. If you don't understand either, you
> don't deserve to be using DLL's period, you should be static linking and
> that's all there is to it.


I got DLLS all over the place, uses in all shapes and forms and NEVER
had a problem because it is well understood, under my control, and
early days were tough, I wrote my own "depends."

Manifest was a big kludge to say the least, removing basic
understanding of them at a basic level, hard to manage, especially
when there were problems.

If you never had a problem David, well then, you were the rare
exception and "master" of understanding them.

Please don't tell me it was just a matter of editing a text file and
trying to follow and match these guids around from tweak to tweak,
version to version, OS to OS, and even then when patches came around,
something could go wrong.

The bottom line I never needed them - the OS did.

>> The old school way - UNDERSTANDING basic DLL loading - in my view is
>> far easier and less distruptive.
>>
>
> I dare say understanding basic DLL loading is as misunderstood as
> manifests. Win9x looked in different paths for DLL's than WinNT, for
> example. .....


DUH, that is NOT RELATED to Manifest. That is exactly my point, what
you stated was well understood especially between versions,
understanding LoadLibrary(Ex), implicit or explicit, delay loading,
etc, all understood.

When it came to manifest, it "altered" things and when YOU thought you
had it figured out or maybe follows some BLOG to get around this stuff
and didn't work, it isn't fun.

> Bottom line is people think loading DLL's should be as
> automatic as loading EXE's,


I don't. Please don't lump all people who had issues with it as though
they were idiots or something.

Obviously Microsoft felt the same way because more than just idiots
has a problem. Even experts had issues, not because they couldn't
figure out, but it was a pain in the a$$. Who wants to spends hours
trying to figure something out when in reality most of the time it
wasn't your problem.

> DLL Hell "works"
> more often than manifests, and people would rather bury their heads in
> the sand even though it yields subtle problems like unresolved externals
> in the DLL or bad behavior due to breaking changes of using the wrong
> manifest, in addition you are at the mercy of whatever Joe Blow's
> installer was run last that installed who knows what version of the DLL!
>
> But I am glad at least for app local deployments, the basic rule that
> your local DLL will always be the one used for your app still rules
> supreme no matter for manifests or not. I stick to app local
> deployment, or static linking.

Well, maybe you do David. I won't. I need DLLS because we have a
plug-in system, a dynamic Virtual I/O system based on DLLS, a p-code
compiler langugge which requires 3rd party developers to import
libraries, etc. We don't need 'hidden' rules based on the OS issues
with loading different versions.

Maybe the problem is that MS is getting its OS vs Applications
integration issues confused with 3rd party ISV of the OS - they should
be independent, it was an Anti-Trust issue, you know? So when MS has
a bug or security patch for its own applications and services via a
system DLL, it could and has cause problems for others. Maybe
Microsoft should do a static link for their own application so their
once general DLLs they wanted to share with others but kept changing
them doesn't hurt others any more.

Maybe they should slow down the hidden hooking of your application
dlls in the name of monitoring, centralization or whatever. People
would be surprise how many dlls are hooked in even for the smallest
app with just 1 dll - one mismatch in the transparent hooking and you
are hosed.

All I know is I never used Manifest, yet, I had problems related to
it. Not by my choosing or wanting to learn it. I am glad MS did
something right for a change - get rid of something you don't need and
cause more problems than it solved.

--
HLS
From: David Ching on 26 May 2010 10:22
"David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
news:uy$ME5K$KHA.3840(a)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

From: David Webber on 26 May 2010 11:38


"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:E0CDF9B1-D002-4326-8467-C7BF728A8652(a)microsoft.com...
> "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
> news:uy$ME5K$KHA.3840(a)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.

So I gather, but the phrase "App local installation" was only invented long
after everyone was doing it - probably only when VS 2008 made it such a
complicated issue :-)

> You are right that it never caused, nor was it a victim of, DLL Hell. So
> you got a free pass! :-)

It has just always seemed so obvious.

> DLL Hell was caused when the DLL's in c:\windows\system32 were overwritten
> by other people's installers...

Yes. I could just never work out why everyone didn't do "app local
installation". Of course the original idea of DLLs was that you only
needed one copy of a DLL on your hard drive and lots of programs could share
it (and originally in Win3.1 IIRC only one copy of the code was ever loaded
in memory). But hard disk space stopped being an issue long ago.

>> 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!

No I didn't :-( So Big Brother is still watching me :-(

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

Didn't know about that either :-( (But I only started using gdiplus at my
VS2008 release.)

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

Well, I'm not too bad: my users tend to rate my support well enough. I
rarely go three months without putting out a service release for some minor
bug or other. If there are reasonably easy work-arounds, I usually wait
until 2 or 3 have been reported, (because patches which fix all previous
releases tend to grow as time goes on). But (very occasional)
show-stoppers get fixed pretty much immediately. Of course users have to
press "Check for updates" on the Help menu to find when there's a service
pack, as I have been loth to have my software go down the internet without
the user actually asking it to. There are enough on my Yahoo user group
that they gang up on me soon enough if something definitely isn't right.

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

There must have been a lot of complaints. Microsoft *does* like to be in
control :-)

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

I thought that since win95, programs simultaneously using the same DLL all
loaded their own copies of it: code and data both????

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

Well I suppose it would be inelegant if you distributed 153 different small
exes all using the same big DLL, but it's still an option: even 153 copies
of a 1MB DLL on a terabyte hard disk aren't that much of a problem - but I
take your point: I wouldn't do that.

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

I have just imported my existing project - complete with directions to MFC9
etc manifest stuff in the resources - like

#ifndef _DEBUG
IDR_DLLMANIFEST RT_MANIFEST "res\\mzw32m.manifest"
#endif

in the RC files. It seems to be ignored (on the machine with Visual Studio
installed).

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

Yes, but one never had to find out what they did with VC2005 :-)

> 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!

Yes. But app local is the easy way to avoid Mr Blow :-)

Thanks for an informative post!

Dave

--
David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm



From: Oliver Regenfelder on 26 May 2010 12:47
Hello,

Tom Serface wrote:
>
> I think DLL hell is slightly better than Manifest hell, but I guess that
> remains to be seen. They may have been better off just beefing up the
> error message that came up for an out of version runtime (the message
> that popped up was pretty dumb).

Yes it only stated "The software hasn't been installed properly. Please
reinstall to solve the problem" or something along these lines.

But if the manifest was wrong (or missing), reinstaling didn't really help
much.

Best regards,

Oliver
From: Oliver Regenfelder on 26 May 2010 12:54
Hello,

Liviu wrote:
> Right, and that was my very point. Failing "if they are not there" is an
> unconditional decision forced upon by the "manifest hell", while the
> "dll hell" allows the application some latitude as to how to proceed
> (in most common cases, not counting "borderline exotic" ones such
> as missing exports which prevent the PE from being launched at all).

It was an xml file, so they could have allowed to specify what to do
in case the DLL wasn't found. Like
<allow newer version>yes</allow ...>

So all that could have been made with the manifest. AND they could
have but an error message like

'Version 9.321.3 of the C runtime (blah.dll) required but not found!'

Not just 'Your application wasn't installed properly'.


I think they could have made manifests more usefull.

Best regards,

Oliver
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Resource Leak
Next: Questions about vcredist_x86.exe, (VS2008 redist).