Prev: Resource Leak
Next: Questions about vcredist_x86.exe, (VS2008 redist).
From: David Ching on 26 May 2010 01:23
"Tom Serface" <tom(a)camaswood.com> wrote in message
news:#h4oNDJ$KHA.5848(a)TK2MSFTNGP06.phx.gbl...
> I usually just open the EXE using Notepad to check the manifest
> information (text) that is buried in there. I wish the OS was smart
> enough to display a decent error message when the versions were wrong.
>

SxSTrace.exe (in Vista and later) is really good. It tells you exactly what
version of the DLL was expected and which was found. It is a little tedious
to use, and of course it does no good on customers machines or on XP, but
still .....

-- David

From: Liviu on 26 May 2010 01:45
"David Ching" <dc(a)remove-this.dcsoft.com> wrote...
> "Liviu" <lab2k1(a)gmail.c0m> wrote...
>
>> I'll disagree with the "less control" part, on grounds that DLL hell
>> will at least start the app (except for borderline exotic cases),
>> thus giving it a chance to check the versions of the loaded modules
>> and decide on the appropriate course of action in case of mismatches,
>> be that a warning, auto-repair, or immediate shutdown. The manifest
>> hell on the other hand always chooses the latter with no recourse.
>
> Isn't that the purpose of the manifest? To specify exactly which DLL
> versions are required and fail if they are not there?

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

> I've never heard of anyone doing a version check from within their
> app once it was started up. I can't believe anyone would ever do that.

On the offchance that someone had to actually do that ;-) for whatever
good reasons, it's a valid, legit technique as far as all the docs go.

Liviu


From: David Lowndes on 26 May 2010 03:05
>I usually just open the EXE using Notepad to check the manifest information
>(text) that is buried in there. I wish the OS was smart enough to display a
>decent error message when the versions were wrong.

I agree, I think the lack of easily understandable messages and *good*
accessible documentation for manifest issues were the root problem
with it.

Dave
From: David Lowndes on 26 May 2010 03:07
>Frankly, I don't think they trusted even themselves to do the right
>thing, so they disabled the manifests.

Sounds like they made a good decision in that light :)

Dave
From: David Webber on 26 May 2010 04:33
I'll jump in here at random.

1. First - sorry for starting such a furore - I have quite a few DLLs which
use MFC and CRT DLLs, so I just wanted to be sure before removing all the
manifest files and taking the lines out of my rc files.

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.

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.

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.

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

Dave

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

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