DLL Hell - What is that ?
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
Code-reuse is the most sought after feature in the programming world today. The idea is to separate the code into individual components to make it available for other applications to use. This is the main reason the concept of components has been around for many years in different forms. Instead of writing one big monolithic whole software programmers preferred to divide the code into smaller units each of which had a well-defined behavior. .Net proposes a new approach to code reuse. It has taken some concepts from its predecessors viz:- DLLs, COM, and COM+ who also follow the concept of code reuse. In the early days of programming if a developer wanted to use a function library in a program, he compiled the client portion of his program to machine code and then relied on the linker to join this machine code with the library’s object file into a single executable. Here Storage space was wasted because separate executables referencing the same class library would each have separate, unused copies of the class library embedded within them. A second disadvantage was that if a bug was found the whole thing had to be re-compiled and re-distributed. Due to the storage space disadvantage the DLLs came into picture. With dynamic-link-libraries, executables could share copies of function libraries between them. A developer could simply place an exe file into the same folder as the library file that it referenced and rely on the operating system to do the linking at run-time. This saved space as well as only DLLs could be independently re-compiled and re-distributed. DLLs faced one problem: only those exes and DLLs written in the same language could be used together. If you write a perfect component in Visual Basic there should be no need of writing it again in VC++. That would be a waste of time. COM solved the problem. With COM an exe written in Visual Basic or Visual C++ could use a DLL written in Delphi. COM imposed a binary standard. Under this standard, components communicated with each other via interfaces. COM identified interfaces via Globally Unique identifiers. Components were registered in the system registry. The benefit of registering was that it was very easy to see what components were available on one machine. With COM it became easy to write a component in any of the languages supporting COM and to call it from other languages. But this ease was topped up with complexity. COM was difficult to learn. Moreover storing information about all components in the registry made the process of i
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
.NET allows multiple versions of an assembly to coexist using versioning. cheers, Chris Maunder
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
The single most annoying case of DLL hell I have had to deal with was when M$ was releasing service packs for NT and VC and we built our app with the latest version of MFC. Well, they updated MFC42.dll to a rev that was not the same as the default OS installation so our latest build did not work with most systems. The old "ordinal WXYZ not found" error was what we got. I almost had to get on a plane over this issue and it really pissed me off. I still don't understand why they didn't increment the version number of the DLL because it was not forward compatable. We ended up having to distribute the DLL also so what were they thinking ? In my opinion, they weren't.
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
There was a very amusing WDJ editorial about six months ago about how often M$ have 'solved' DLL hell. Christian I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOz
I live in Bob's HungOut now
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
http://www.computerworld.com/cwi/story/0,1199,NAV47-71-366-1718\_STO65533,00.html thought you guys might be interested in this article. I've never thought about the "problem" quite in these terms though :-) Senkwe Just another wannabe code junky
-
I was going over some .net documents. One of the advantages listed was it solves Dll version conflicts. But I remember reading somewhere that COM, Windows 2000 were designed to solve this. Most of the dll conflicts I have come across are those involving system dll's like comctl32, oleaut32 etc which are distributed by Microsoft. The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . So aren't again back to square one ?
Ravish wrote: The .Net Class library will also evolve over time, leading again to the different versions of the class library dll . There can be more than one CLR on the same machine and components from one CLR can interact with the components in the other version. It wont happen sooner but its a definite possibility when they go for a next version of CLR. Cheers Kannan
-
.NET allows multiple versions of an assembly to coexist using versioning. cheers, Chris Maunder
The best thing is not having to put 1000s of DLLs in the system32 directory Nish Sonork ID 100.9786 voidmain www.busterboy.org If you don't find me on CP, I'll be at Bob's HungOut
-
http://www.computerworld.com/cwi/story/0,1199,NAV47-71-366-1718\_STO65533,00.html thought you guys might be interested in this article. I've never thought about the "problem" quite in these terms though :-) Senkwe Just another wannabe code junky
I found that article interesting. I especially liked the following paragraph: "... reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what Side-by-Side Assemblies is all about. Microsoft depends on obscurity and complexity to survive." I was reminded of some of the the help in MSDN. Sometimes I wonder if they are deliberately trying to be abstruse. "Am I talking too fast, or are you just playing dumb? If you want I can write it down." -Jarvis Cocker/Pulp
-
I found that article interesting. I especially liked the following paragraph: "... reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what Side-by-Side Assemblies is all about. Microsoft depends on obscurity and complexity to survive." I was reminded of some of the the help in MSDN. Sometimes I wonder if they are deliberately trying to be abstruse. "Am I talking too fast, or are you just playing dumb? If you want I can write it down." -Jarvis Cocker/Pulp
Daniel Ferguson wrote: "... reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what Side-by-Side Assemblies is all about. Microsoft depends on obscurity and complexity to survive." This argument is completely stupid (or am I the stupid here ?). It's non-sense. It's like saying Ferrari makes faster cars to make it difficult for Sony creating a CD-player that plays music at 250 miles/hour on slower car brands. So, if you want to hear music at this speed, you want a Ferrari. But THIS is not the point. If you want DRIVING at this speed, you want a Ferrari. If Sony ever makes a CD-player that only works at this is speed, it's a Sony problem, not Ferrari's monopolistic view of the world! If the feature is Windows-specific and your software depends on it, it IS a Windows-specific software! It's YOUR fault, not MS! If the feature is not Windows-specific, so your software is simpler to deploy on other platforms. This is pretty obvious and clear. Crivo Automated Credit Assessment
-
Daniel Ferguson wrote: "... reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what Side-by-Side Assemblies is all about. Microsoft depends on obscurity and complexity to survive." This argument is completely stupid (or am I the stupid here ?). It's non-sense. It's like saying Ferrari makes faster cars to make it difficult for Sony creating a CD-player that plays music at 250 miles/hour on slower car brands. So, if you want to hear music at this speed, you want a Ferrari. But THIS is not the point. If you want DRIVING at this speed, you want a Ferrari. If Sony ever makes a CD-player that only works at this is speed, it's a Sony problem, not Ferrari's monopolistic view of the world! If the feature is Windows-specific and your software depends on it, it IS a Windows-specific software! It's YOUR fault, not MS! If the feature is not Windows-specific, so your software is simpler to deploy on other platforms. This is pretty obvious and clear. Crivo Automated Credit Assessment
No need to get so excited and jump all over me because I said something that questions the way MS does things. :omg: I think you missed my point. I wasn't referring to specific features of Windows or any other OS, or even trying to compare Windows to any other OS, what I'm saying is that the implementation of some features is more complex than they need (or should) be, and why is this? :suss: "Am I talking too fast, or are you just playing dumb? If you want I can write it down." -Jarvis Cocker/Pulp
-
No need to get so excited and jump all over me because I said something that questions the way MS does things. :omg: I think you missed my point. I wasn't referring to specific features of Windows or any other OS, or even trying to compare Windows to any other OS, what I'm saying is that the implementation of some features is more complex than they need (or should) be, and why is this? :suss: "Am I talking too fast, or are you just playing dumb? If you want I can write it down." -Jarvis Cocker/Pulp
Excuse me, it wasn't my intention to seem agressive (maybe it's my poor english, I'm a native portuguese speaker). Again, I disagree: I've seen tons of people having problems with .o and .so files on Linux. Search for glibc on the web and you'll see what I mean. Crivo Automated Credit Assessment