| ActiveMac | Anonymous | Create a User | Reviews | News | Forums | Advertise |
|
|
|
User Controls |
|
New User |
|
Login |
|
Edit/View My Profile |
|
|
|
|
|
|
|
ActiveMac |
|
Articles |
|
Forums |
|
Links |
|
News |
|
News Search |
|
Reviews |
|
|
|
|
|
|
|
News Centers |
|
Windows/Microsoft |
|
DVD |
|
ActiveHardware |
|
Xbox |
|
MaINTosh |
|
News Search |
|
|
|
|
|
|
|
ANet Chats |
|
The Lobby |
|
Special Events Room |
|
Developer's Lounge |
|
XBox Chat |
|
|
|
|
|
|
|
FAQ's |
|
Windows 98/98 SE |
|
Windows 2000 |
|
Windows Me |
|
Windows "Whistler" XP |
|
Windows CE |
|
Internet Explorer 6 |
|
Internet Explorer 5 |
|
Xbox |
|
DirectX |
|
DVD's |
|
|
|
|
|
|
|
TopTechTips |
|
Registry Tips |
|
Windows 95/98 |
|
Windows 2000 |
|
Internet Explorer 4 |
|
Internet Explorer 5 |
|
Windows NT Tips |
|
Program Tips |
|
Easter Eggs |
|
Hardware |
|
DVD |
|
|
|
|
|
|
|
Latest Reviews |
|
Applications |
|
Microsoft Windows XP Professional |
|
Norton SystemWorks 2002 |
|
|
|
Hardware |
|
Intel Personal Audio Player 3000 |
|
Microsoft Wireless IntelliMouse Explorer |
|
|
|
|
|
|
|
Site News/Info |
|
About This Site |
|
Affiliates |
|
ANet Forums |
|
Contact Us |
|
Default Home Page |
|
Link To Us |
|
Links |
|
Member Pages |
|
Site Search |
|
Awards |
|
|
|
|
|
|
|
Credits |
 |
Microsoft promises end to 'DLL hell' | |
|
||
| Time: 18:42 EST/23:42 GMT | News Source: ZDNet | Posted By: Bill Roach | ||
|
Windows Server 2003 will bring an end to one of the biggest headaches for Windows users and administrators, according to Microsoft. The problem, which relates to Dynamic Link Libraries--software modules that can be shared by several different applications--has become an increasing headache over the years. Problems typically occur when an application is installed that uses an updated version of a Dynamic Link Library--or DLL--that is already used by another application. If the original application cannot work with the updated DLL, then the user gets an error message; Windows and Windows applications have no notion of DLL version numbers, and so the problem can be difficult to track down. | ||
|
Write Comment
Return to News |
Displaying 1 through 25 of 165 Last | Next |
The time now is
12:58:30 PM
ET.
Any comment problems? E-mail us |
| #1 By 3339 (65.198.47.10) at 3/6/2003 8:26:01 PM |
| It sounds like this creates its own problem: DLL bloat. It's one thing to say modern HDs are bigger, it's another thing to have 20 copies of the "same" DLL. |
| #2 By 3339 (65.198.47.10) at 3/6/2003 8:53:30 PM |
|
Can someone explain... It sounds like the GAC is becoming an intermediary when the apps could do the work, why add this additional layer--isn't this just overhead?
If the DLL/COM object/whatever has a version number for the GAC to cache in its own registry... Why is the GAC playing the intermediary role of hard linking that object to its registry to the app which installed it? Never mind the work of trying to heuristically determine whether or not the proper DLL is being used... Does this mean that not only do the apps not specify which version they use, but that the registry cannot distinguish between different versions of the same DLL without the GAC? This sounds retarded to me. Isn't it time to simply make versioning a requirement. That way the registry could store multiple versions of DLL if necessary, and if not, overwrite or not install them. That way you would have the benefit of maintaining multiple versions but still sharing when possible without an intermediary? |
| #3 By 125 (216.232.67.238) at 3/6/2003 8:54:27 PM |
|
#5 is right. If developers never removed functionality from a DLL there wouldn't be the nasty problem we have today. Or if they needed to significantly change the way a routine worked or its required paramaters then rename the dll and change the GUID.
Wishful thinking right? :) |
| #4 By 2062 (68.129.23.252) at 3/6/2003 9:14:09 PM |
|
For the most part this was fixed in win2k. THe new part is side by side dll's (SXS). It means if 2 programs require the same file but different versions, it will load both versions in memory at the same time. Runtimes are a great example of this. In win9x is a program overwrote a runtime such as msvcrt.dll, other programs might stop working. This totally fixes that.
-gosh |
| #5 By 7797 (64.105.197.82) at 3/6/2003 9:23:49 PM |
|
Yes, they DID promise this with Win2K also....
http://www.microsoft.com/windows2000/techenthusiast/features/wfp.asp This post was edited by tgnb on Thursday, March 06, 2003 at 21:29. |
| #6 By 1845 (12.209.152.69) at 3/6/2003 9:55:54 PM |
| jerk, fyi, GAC is only for .NET assemblies. It has nothing to do with COM components. |
| #7 By 2459 (24.170.151.19) at 3/6/2003 10:26:10 PM |
| But UNIX has its own package/dependency hell. |
| #8 By 3339 (67.121.114.19) at 3/6/2003 11:49:56 PM |
|
Thanks, Bob, I was just throwing the whole boatload in, you know. (I've actually already been told by a friend that it does nothing for COM Hell.) But do you get my question, GAC is going to cache hard pointers between the apps and the appropriate DLL (presumably by detecting which component was created at install). Why doesn't the app just handle it by using versioning... You may have a situation where the same DLL doesn't overwrite another DLL, but you still have two DLLs that appear to be the same (if you aren't looking in/at the GAC)... If you are giving up some element of sharing (not a bad thing in my mind--how often do you have five or more apps sharing the same five DLLs, and if you do, is it such a big deal if they dont't share... considering the capabilities of a modern computer)... So why not version every DLL and have the app specify both the DLL and version, instead of having a GAC at all to cache a list of DLLs, associated apps, and code to try to interpret which is which when the GAC doesn't contain the proper entries.
Sounds to me like the problem still exists more or less, but they are throwing in another layer to (hopefully) solve the problem. I'm not purporting to know so what do other people think? |
| #9 By 6253 (12.237.219.240) at 3/6/2003 11:53:17 PM |
|
cba-3.14, the fundamental problem here was not solved in *nix. The *nix scheme for versioning of shared libraries makes it "possible" to avoid DLL Hell, but on any system with more than a few apps using more than a few libraries, it's very difficult for an average sysadmin to know which symlinks to create/change when updating libraries, to avoid breaking an app. Also, you're still relying on the programmers of libraries to follow the versioning rules.
Aside from library reuse, there are other situations in *nix where a shared resource or shared system facility can get clobbered by a stupid installer. How about if my installation script decides to put something in your crontab by simply copying my pre-built crontab straight into /etc? Oops, you already had something in crontab? The possibility never occurred to me. When you boil it all down, that's what happened with DLLs. There were a bunch of rules which would have allowed DLLs to save not just disk space but also memory, and improvements in a library could theoretically benefit multiple apps immediately and automatically. All of this was without risk to any app, as long as everybody followed the rules. The problem is that it took Microsoft years to realize that 99% of programmers in the world are dumb and lazy (just like 99% of plumbers, lawyers, actors, chefs, etc.). The remaining 1% were the OS programmers at Microsoft who figured that since they were workaholic hardcore coders, all programmers must be. JamesWjRose and astorrs are only partially right, because there were many different things which app programmers (including some of Microsoft's) screwed up besides changing interface/implementation between versions. We got installers which overwrite newer versions, newer DLLs which forgot to increment their version, DLLs without a version resource at all, installers which placed common DLLs in a shared location without reference-counting it, uninstallers which remove reference-counted DLLs without decrementing, installers which go ahead and update registry/INI settings used by a new DLL version even if the new DLL version fails to install, service provider implementations done directly in the SPI DLL instead of called from a stub (like early MAPI services), and on and on. |
| #10 By 6253 (12.237.219.240) at 3/6/2003 11:53:46 PM |
|
tgnb, "DLL Hell" is a loose term which gets applied to several different situations. What Microsoft promised with WFP in Win2K was that an app wouldn't break the OS. For the most part, they delivered. WFP was addressing the problem that you typically have to log on with administrative rights to install software, but this made it impossible to protect critical OS files with NTFS permissions alone. WFP provides that protection.
Admittedly, there are some loopholes in WFP. For example, if the currently logged-in user is not an administrator when system files get replaced (perhaps by a compromised Windows service), and the protected files are not cached, and the installation source indicated in the registry is not accessible, then WFP can't do anything. Another loophole is the registry situation I mentioned above. Nothing besides SP1 can replace the MDAC 2.7 files built into Windows XP, but you can easily screw up some registry entries by attempting to install MDAC 1.5 (or by unsuspectingly installing an app which in turn tries to install MDAC 1.5 without giving you any choice). Even though MDAC 1.5 fails to overwrite any DLLs, it does tell the registry that the current MDAC version is now 1.5. When you later try to install a product which checks to make sure you've got MDAC 2.x or higher, it will see the registry entry and tell you to upgrade MDAC. When you try to install MDAC 2.x, it fails to overwrite any files, but MDAC 2.x's installer is "smart" enough not to update the registry if no files got installed. Therefore you'll never get your second app installed until you stumble across this explanation. In fact, even if you reformat and reload, odds are that you'll reload that first app again before the second and hit the same problem. WFP was only one feature of Win2K which addressed DLL Hell. Win2K also supports .local files which force apps to use private copies of DLLs, and NTFS partitions in Win2K also handle symlinks (called junctions in Microsoft's terminology) which allow you to handle DLL versioning much the same way *nix does, if that's what you prefer. |
| #11 By 1845 (12.209.152.69) at 3/7/2003 2:02:48 AM |
|
jerk,
A little background, I've been doing .NET apps for a little over two years now. The apps I write use the shared assemblies in the GAC, but my apps don't deploy to the GAC. They rely on their own private assemblies. Keep that in mind with this explanation and take it for what it's worth based on my specific experience. I don't want to go into the COM world and explain the reasons that GAC is a nice thing to have, so let's just focus on what that GAC does. When an assembly is deployed to the GAC its metadata includes a version number and a strong name key. The strong name key is a globally unique. The GAC can contain other versions of the same assembly, and they will be uniquely identified both by their strong name key and by their version number. GAC doesn't know or care which applications references the assemblies it contains. An application that references an assembly in the GAC will reference it by version number, but more importantly by its public key token (strong name key). This gaurantees to the app, that it will get the version of the assembly that it needs. Further, when an update to the assembly is added to the GAC (like the v1.1 framework assemblies for instance) both versions of the assembly will live in the GAC. An app developer can choose to to have an app go with the latest version of an assembly or can specify a specific version. Also, IIRC, he can set a range of acceptable versions. If I erred in that explanation, someone more familiar with GAC than I, please correct me. |
| #12 By 2459 (24.170.151.19) at 3/7/2003 10:17:23 AM |
|
hdaerden,
There is nothing preventing MS or anyone else from fixing a security issue in a DLL. They do it all the time when they distribute updates and hotfixes. As long as the public interfaces remain the same, they can change the code to fix whatever bugs are in it. |
| #13 By 2459 (24.170.151.19) at 3/7/2003 10:49:05 AM |
|
mOOzilla,
Default behavior is for the app to use the version it was built with. The app must be redirected by the developer to use an upgraded version. If an upgraded version is installed into the GAC, it will sit side-by-side with the older version. The old app uses the old version (unless updated or allowed from the start to use the newer version). The app that installed the new version will use the new version. |
| #14 By 3339 (65.198.47.10) at 3/7/2003 1:59:13 PM |
| Thanks for the info, Bob. As I said, it sounds like another layer to "try" to fix the problems, and develoeprs can still build sloppy code. Why don't they just go to a method where better code design is enforced. |
| #15 By 7390 (63.211.44.114) at 3/7/2003 2:56:44 PM |
|
11 By BobSmith (3601 Posts) at 3/6/2003 9:55:54 PM
jerk, fyi, GAC is only for .NET assemblies. It has nothing to do with COM components. Typical SodaJerk! Thanks, Bob, I was just throwing the whole boatload in, you know. (I've actually already been told by a friend that it does nothing for COM Hell. Soda here lesson 101: GAC = .Net shared component. Otherwise you would place it in the Bin folder of the App COM = Uses the registry so can't do copy paste you need register it. But important is giving his opinion and referring to things tha the knows little about or doesn't care to read about. And before you go there I am an MSCE and studying to be an MCAD (which is .Net certifications). So sit back and only comment when you can contribute. I am sure that some story about MS causing world hunger and are in league with aliens will come soon. Mr. SodaJerk have a good day |
| #16 By 3339 (65.198.47.10) at 3/7/2003 4:40:01 PM |
|
Redhook, whatever...
My point was the GAC seems to only address .Net components, doesn't doing anything for Win32 DLLs, or COM.... Am I wrong about that? I'm just questioning the actual impact of the GAC--as others have pointed out, 2000 and XP were both going to "solve the DLL Hell problem." James, by enforcing good code design, I am saying require the use of the strong name key or the versioning to point to components. Rather than have some code using weak links, some using versioning, some using GUIDs. There is little advantage in having multiple options except lazy, bad developers can get up and running. All I know is this doesn't have to be a problem... So why all these intermediary "attempts" to fix something while maintaining the underlying flawed system? This post was edited by sodajerk on Friday, March 07, 2003 at 17:06. |
| #17 By 7390 (63.211.44.114) at 3/7/2003 9:12:37 PM |
|
Jerky, as many have tried to tell you and I am sure you know by now. The GAC is .Net specific and does not address the world of COM.
Once everything is done is .Net (MS's dream). DLL hell won't be an issue until then everything else is a hack, even your suggestion. |
| #18 By 8589 (65.66.107.123) at 3/8/2003 2:32:20 AM |
| Sharing DLL's has always been considered a risk since its implementation back in the days of Windows that sat on top of DOS. |
| #19 By 7390 (63.211.44.114) at 3/8/2003 8:20:51 PM |
|
#30 Maxama, what specific action causes the "BSOD"? Maybe it's an application that have you installed? Have you noticed a pattern? Do you have all of the SPs and hot fixes installed?
For Windows ME at the very least, do something about the "Blue Screen of Death". Thats should of been fixed by the time it hit the shelves. That tells us nothing, can you expand upon this a little. I am not being funny, maybe someone here can assist you based on what you tell us. |
|
Write Comment
Return to News |
Displaying 1 through 25 of 165 Last | Next |
The time now is
12:58:30 PM
ET.
Any comment problems? E-mail us |
