Re: Manifest Hell - a thing of the past?
"Hector Santos" <sant9442@nospam.gmail.com> wrote in message
news:ukmaedL$KHA.5044@TK2MSFTNGP04.phx.gbl...
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.
I think we have differing biases toward two universes that are pretty even
in terms of evilness. If you wrote your own "depends" that means DLL Hell
was a problem for you and you invested significant resource in dealing with
it. Frankly, that sounds more like a kludge than manifests which deal with
the problem at the OS level where they are meant to be dealt with. Your
issue is that they are not free in terms of understanding and deploying
them, while rendering irrelevant your hard won knowledge of combating DLL
hell.
I have no issue with home grown solutions like you devised, but manifests
solved problems that no "depends" like tool or 100% understanding of DLL
management could ever solve. (Or should have to solve, as this is an OS
function.)
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.
There are whole articles written on the different behavior of LoadLibary(Ex)
on various OS's which I tried to learn and found my head hurting, and anyway
that is only for dynamic loading of DLL's and doesn't solve the statically
loaded ones.
Of course manifests "altered" things, such that it was possible to clear all
this up. The trouble was, their solution involved a lot of effort to
leverage, and you didn't want to do it.
I don't. Please don't lump all people who had issues with it as though
they were idiots or something.
I think manifests highlighted that getting the right DLL's loaded is hard
(because if you don't get it 100% right, you will get a 100% failure as
Liviu points out). A lot of people like Liviu get by with using the wrong
DLL that is 99% compatible, and maybe it will just work, and if it doesn't
the user won't know what to do with the error message or random program
termination, and may call your technical support but probably you will never
hear about it. The manifest errors are opaque, but are more informative
than something like "Entry point foobar is not found is xyz.dll") because
Joe Blow installed an older xyz.dll that was put out before foobar was ever
written.
Well I for one can't afford to be supporting customers at the mercy of Joe
Blow. I simply don't have time or desire to hand hold customers through
this crap. If my apps were one bit successful, and people actually used
them, I wouldn't have time to code!
With manifests I am 100% certain that when I deploy global DLL's that get
put into c:\windows\system32 (or it would be the winSxs folder I guess), *no
one* will screw up my customer's machine and have me deal with the
aftermath. So my tech support costs go down, down, down, and my program's
reputation for stability goes up, up, up.
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.
Same with DLL Hell, see above.
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.
LOL, the only thing "hidden" is DLL's hiding of errors when wrong DLL's are
somewhat compatible and mostly work. Manifests put everything out there cut
and dried. Nothing hidden about them, unless you don't want to learn them.
Then again, that applies with anything. "I don't want to learn it, so it
remains 'hidden'!" :-)
[...]
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.
I'm glad your home grown Depends saved you from ever dealing with DLL Hell,
but if you've ever relied on redistributed DLL's stored in
c:\windows\system32, you've spent significant time on DLL Hell whether you
admit it or not, even if it was spent writing a Depends.
Actually, I'm not sure if the situation has improved with using
vc_redist.exe or MSI merge modules. Those are the two officially supported
ways of installing the VC redists in c:\windows\system32. I'm not sure if
you can just copy the individual DLL's there by yourself, or if it is a
protected OS function requiring vc_redist or MSI to update. If so, I agree,
letting MS handle it would drastically reduce potential to foul up this
valuable shared folder and prevent DLL Hell. Anyone know about this?
-- David