DLL Hell

I keep seeing this phrase, what does it mean?

Aussie Chick
Tuesday, October 21, 2003

http://www.desaware.com/Articles/DllHellL3.htm

Prakash S
Wednesday, October 22, 2003

One thing in that article said:
"Windows will search for ActiveX components and controls in the registry instead"

Is there a difference between ActiveX and standard DLLs?

I just assumed that the newer the better?!?

Aussie Chick
Wednesday, October 22, 2003

http://www.google.com/search?hl=&cat=&meta=&q=dll+hell

Damian
Wednesday, October 22, 2003

An ActiveX control is just a COM component that implements certain interfaces. The implementation of an ActiveX control is normally a DLL file.

So they're really seperate concepts.

Sum Dum Gai
Wednesday, October 22, 2003

An OCX file is another type of COM DLL too.  OCX's are also susceptible to DLL Hell.

Wayne
Wednesday, October 22, 2003

If you want to understand ActiveX and COM, one of your best resources would be Chappell's book "Understanding ActiveX and OLE"
http://www.amazon.com/exec/obidos/tg/detail/-/1572312165/

It's fairly technical, but it's the bare nasties about the interfaces.

Philo

Philo
Wednesday, October 22, 2003

Aussie Chick,

<quote>
Is there a difference between ActiveX and standard DLLs?
</quote>

Yes. From a VB perspective:

1. An ActiveX DLL is used by ticking it in Project -> References.
2. A standard DLL is used with the Declare method.

Also, you can try running regsvr32 with the DLL path name as a parameter. If you get a 'success' error message, you have an ActiveX DLL. Anything else you LIKELY have a standard DLL.

Seeya

Matthew
Wednesday, October 22, 2003

The problems of DLL Hell were largely diminished in Win 2000 and then XP.

Now there's more likely to be the problem of the particular MS runtime you need not being on the target machine.

Simon Lucy
Wednesday, October 22, 2003

dll hell refers to the fact that applications would often install their own version of standard Windows .dll's because they couldn't bwe sure you had the up-to-date one. The problem was that those "up-to-date" .dll's would often be out-of-date when you installed the program, and would overwrite a newer version, and stop something else working.

Starting with Millenium Edition and W2K Windows bought in WFP (Windows file protection) which will rewrite the original system file over any system file your rogue program might overwrite.

.dll hell was the reason people use to have to do regular format and reinstall on W9* machines. Luckily with W2K and win XP the need has largely disappeared.

Stephen Jones
Wednesday, October 22, 2003

Another good thing to read is just the first chapter of Don Box's "Essential COM".  You'll totally understnad DLL Hell after that.

http://www.amazon.com/exec/obidos/tg/detail/-/0201634465

Grumpy Old-Timer
Wednesday, October 22, 2003

"You'll totally understnad DLL Hell after that."

Okay, it's been a very stressful few days for me.  That of course should have been "understand"...

Also, if you'd like to read some "funny" accounts of the widespread devstation that can be caused by DLL Hell, go to groups.google.com , and search for "mfc42 8447" (without the quotes).

Grumpy Old-Timer
Wednesday, October 22, 2003

Most newcomers to VB will get stuck in COM DLL hell reasonably quickly, because the concepts of binary compatibility and references aren't particularly explained well. Even more experienced programmers will still get it from time to time because you have so little control as to the COM stuff going on under the hood.

When you get to system test and try to solve the dreaded "429 : ActiveX component can't create object" or similar errors, you really do need a good understanding on how COM works, especially with relation to the registry.

The classic book "Hardcore Visual Basic" gives a good introduction to that knowledge for VB programmers. (Online copy at http://www.mvps.org/vb/hardcore/ ).

Better Than Being Unemployed...
Wednesday, October 22, 2003

I don't think it's been mentionned: As far as you're concerned, the pain about ActiveX controls is that, unlike regular DLLs, sticking the .OCX file in the directory where your app lives doesn't ensure that this is the one that will be used. The reason for this, is that Windows looks up the OCX's path in the registry, not in the filesystem... and Windows (until W2K/XP, but I haven't looked into this) doesn't provide a means to allow more than one given OCX to be located in the Registry.

So... if a user installs another app that uses the same OCX as your app, but in a different version (older)... the OCX will be replaced by this other app, an older version of the OCX will be happily replaced... and your application will stop working with Err 429.

The only solution is, when your app is launched, to check that all the OCXs on which it depends are properly installed, and reinstall them stealthly otherwise :-)

Frederic Faure
Wednesday, October 22, 2003

which is why you should have multiple clsids if the class is different.
but then again, even microsoft office doesn't get this right, ask for (progid) microsoft.office.specificversion, and you'll actually get what is (from the caller's point of view) a random version.

mb
Wednesday, October 22, 2003

But then, generating a different CLSID every time a new version of a control comes out breaks compatibility... and since, if I understood COM at all (not sure :-)), one of COM's virtues is providing multiple interfaces, each one mapping to a different revision number... it makes sense that the CLSID wouldn't change.

But then, MS should have provided a way to either forbid downgrading to an older version if at least one software requires the current version, or make sur that the older version already offered the interface that the other app needs.

Frederic Faure
Wednesday, October 22, 2003

of course. if the interface is identical as the COM contract reqires, and the class only provides new interfaces, then you shouldn't change the ID. but most people don't do that. so i'm suggesting v1 has clsid1, v2 installs clsid1 (w/full backwards compatiblity) and clsid2, and anything requiring v2 calls clsid2. and if you install v1 on top, it only blows away the backwards-compat part of v2, which won't hurt anything.

msxml has gone down a route like this.

mb
Wednesday, October 22, 2003

MS used to want to understate the problems associated with different COM servers providing for the same CLSID. Then when .NET came out they wanted to convince all the COM programmers to switch so they started overstating it instead. This is why you keep hearing the term "DLL Hell" :)

Jon Hanna
Thursday, October 23, 2003

Amen Jon!

Entrepreneur
Friday, October 24, 2003

  Recent Topics

  Fog Creek Home