Slashdot Mirror
Microsoft to End DLL Confusion
MankyD writes "ZDNet is reporting that Microsoft is attempting to do away with DLL version conflicts in its next version of Windows with a technology it calls 'Strong Binding'. When new programs attempt to overwrite old versions of DLL's, the Strong Binding will index the DLL's and allow the programs to reference them by a unique ID, rather than by file name. Hopefully it will prevent a new program from breaking an old one. I would think this might add to DLL clutter however."
Sounds like a great idea. While there will be more DLLs in the registry, at least each and every program will have it's "own" DLL and can't be broken. Although I wonder if the software will default to the newest DLL and then go back if it doesn't function correctly.
Slashdot: Playing Favorites Since 1997
How does Linux deal with the issue of linked libraries? I'm assuming it has something similar.
It is not only for preserving disk space.
It also preserves ram by sharing common code between different applications.
It also makes upgrades and bugfixes easier (think openssl, for example).
Wasn't that the point of the Registry?
"Would it kill you to put down the toilet seat?" -- Maya Angelou
In addition, the OS should be intelligent enough to know when an EXE's been manually deleted (thrown in the Recycle Bin). The current practice of placing all unstallation responsibilities on the vendor tends to result in DLL buildup when the uninstaller doesn't work right or isn't provided (not uncommon.) There should be a unified process for adding a DLL that links it to the executable file that requires it.
Dropping the fancy XP theme frees up about 5 megs of RAM, but if your system only has 128 or 256 megs of RAM you don't have a lot of room to load apps.
Sorry, but my karma just ran over your dogma.
I don't get it. The sole idea about DLL is, that they are dynamically linked libraries (hence the name ;) shared by applications. This new idea suggest that, in theory, every program can have their own unique DLL. What's wrong with this picture? It's a workaround because today, programmers create DLL's that are not backwards compatible thus breaking older programs once the DLL has been overwritten. Yes, the workaround will work, but at the same time it undermines the idea of sharing libraries and it doesn't exactly urge programmers to write nice code that doesn't break existant functionality.
/Christian
Well this makes one start to wonder, if each program is going to have a unique DLL (or at least one shared with VERY few others) why bother to have DLLs at all? Why not just roll the library up into the application binary?!
It'll be interesting to see how this adds to the bloat, I imagine it won't take long for the average user to amass quite a number of these things, mostly doing the same job!
There must be a better solution than this!
The number of copies in memory, for one thing.
Consuder how many processes are loaded on a typical 'doze system. Now imagine what would happen if every one of them had a different copy of USER32.DLL (or whatever).
According to Microsoft's Ivo Salmre, quoted in the article: "When a .Net component is installed onto the machine, the Global Assembly Cache looks at its version, its public key, its language information and creates a strong name for the component."
In a few cases in the past, backwards compatibility has been (slightly) broken by service packs and security fixes. How will they deal with that? Presumably, the public key of a library can be affected by a patch. If an application uses the strong binding to request a specific version of a DLL, does that mean that it will keep its own copy of the DLL without the patches? Or will it have to deal with potential incompatibilities introduced by the patches? How "strong" will this binding be?
And by the way, this idea looks rather similar to the usual UNIX shared libraries that allow an application to bind to libpng.so (version doesn't matter), libpng.so.1 (version 1 required) or libpng.so.1.0.89 (specific version and patchlevel required). The proposed system for DLLs does not seem to be very different from that.
-Raphaël
Correct me if I am wrong, but wouldnt that slow windows down even more. You computer will now have to search through your registry to find the correct DLL for your application. And what happens if you registry gets corrupted (not like that ever happens), then that you put you in an even worse position. Would it be easier to make the DLLs backwards compatible?
Well, it is one thing to say that application can now obtain the version of the DLL they want if they *explicitly ask for it*. It is another thing to say that, they always and forever, until the end of time get the DLL they were "compiled against" or "packaged with". It is not clear from the article which of these two situations is the case.
The point of shared libraries is that you CAN upgrade one single library and have many applications "automatically" inherit the changes. This is how you can update a file dialog for instance, without recompiling every single one of your GUI applications. This is a Good Thing. The question then becomes "why is this shit breaking so much". The right solution is a proper combination of carefully-followed deprecation and backwards compatibility rules (preferentially married with some sort of standard version naming convention), and the ability for applications to explicitly choose the library version they want (or even better yet, runtime configuration directive that can be set by the user or administrator) in the cases that *it is known that the new shared library is not backwards compatible*.
It's 10 PM. Do you know if you're un-American?
So, you change the shared library. What programs did you affect?
-- Stephen.
..Microsoft use the same news dupe checker than slashdot ! Windows 2000 : "Get out of DLL Hell for good. The Windows® 2000 Professional operating system has a feature to meet, greet, and exorcise applications that mess with your Dynamic-Link Library (DLL) and executable files: Windows File Protection. This feature saves you from unsightly operating system and application mismatches." http://www.microsoft.com/windows2000/techenthusias t/features/wfp.asp
Windows XP:
"One source of frustration for me is applications that share code. No doubt you've run in to the scenario where two applications share the same DLL but require two different versions of it. The result is usually fatal. Windows XP fixes this problem via side-by-side component sharing. The gist of this technology is to allow multiple versions of a component to run in memory at the same time. Each program gets to use its own version of the DLL."
http://www.microsoft.com/technet/treeview/default. asp?url=/technet/prodtechnol/winxppro/evaluate/wxp relb.asp?frame=true&hidetoc=true
- MrNop
If each application pretty much has their own version of the DLLs, doesn't that defeat the purpose of having shared libraries anyway?
The libertarian solution to the failures of capitalism is to apply more capitalism til the failures are fixed.
OS/2 - as an example only - had a much better scheme where o/s stuff lived in its own space and the stuff you built/bought lived in its own space (and never the twain shall meet). On top of that, they implemented the idea of a LIBPATH env variable so that you could set the path OS/2 would take when looking for DLLs. Consequently, screwups were minimized, versioning was not an issue, built/bought software could be maintained easily, and (wait for it...) you could upgrade the o/s without blowing away all your apps!
Can't wait to hear what MS 'discovers' next!
CrazyLegs
"Pork!!" said the Fish, and we all laughed.
My perspective isn't how conflicts are solved, but it's the underlying API itself isn't generalized and well designed. I think in MS's effort to make it super simple for stupid programmers, the API's were dumb down to the point where method signatures limited their ability to grow/add new features. Therefore they had to come up with new API constantly, which continually broke old DLL's. It's what happens when software takes it's API design from some one who thinks like a sales guy, instead of a software architect who thinks forward.
The whole idead behind dll's was to keep from having multiple copies of the same file for each program. This seems to overrule that theory, so why even store it in windows\system(32) then, just put the dll in the programs directory and do away with the dll-id nonsense.
Does anyone else see this as a pre-registry registry?
Actually I think the reason XP takes up so much ram is because it is loading up a ton of USELESS DLL's and COM objects into ram so that IE will load faster and Word XYZ will open immediately, .NET Framework, VB Framework and the list goes on. A whole bunch of junk that really should not reside in RAM just so that MS's stuff loads faster than the competitors products. DLL's are a great idea but Microsoft has found that they have too many DLL's and they are disorganized.
The idea that an opperating system has a standard core set of DLL's that all programs can use to add functionality to programs is a WONDERFULL IDEA! Microsoft is only finding out that there is such thing as too much of a wonderfull thing. They have been writing DLL's and COM components for windows for almost ten years and they need to keep backward compatibility with all of them no matter how ugly or badly implemented an original DLL was done. This method will allow them to stop having to keep backward compatibilty (but leads to other problems such as bloat). They will still have too many DLL's that are only usefull to only one or two programs (and this solution won't make it better) and really should be statically linked or put in a private directory of the XYZ program (and uninstalled when the program is) but this is a good step in the future management of DLL cruft because they can at least start the process of breaking backward compatibility of badly designed libraries.
I miss the Karma Whores.
Well, I was going to say this earlier, but the network hung. All I can do now is expound on this...
The largest EXE on my box is a little over 3 megs (it's AbiWord, by the way). The largest DLL on my box is a little over 5 megs (it's the bulk of the image loader/editor that came with a cheopo digicam I bought). Let's be really, really conservative and say that AbiWord decides to load that DLL. Yeah, I know it would never happen but this is just a worst-case scenario. That's 8 megs resident in memory. Now, how many windows do I typicly have open? 5 or 6, and many times it's the same app like IE or MSVC. Even under a worst-case scenario like 8 separate huge apps open, that's 64megs. Now of course this worst-case scenario is an extreme. I wager a more typical scenario with everything self-contained would result in less than 32 megs of code resident in memory. What's 32 megs cost? They don't even sell 32 meg modules most places. A lot of boxes are coming with half a gig, and if you want more you just grab for some loose change and snap it in.
Of course, apps aren't the only thing on the box. The System Information in Windows shows a lot of DLLs loaded by Windows, many of them legacy support. On a box with 128 megs of ram, I sometimes break over 50% resource utilization, but there's no noticeable impact on performance so who cares?
Now, weigh the cost of RAM against all the hours spent putzing with different dynamic library versions.
Plainly, dynamic libraries are a holdover from the days when memory costs and address-space limits were something to think about.
Now, I'm not saying that there aren't circumstances where dynamics are a good idea. For example, it would have been nice if Microsoft had installed MFC DLLs with earlier versions of Windows. I shudder to think of all the bandwidth wasted downloading those.
The "solution" of maintaining different versions of DLLs and giving them unique IDs is almost an admission of defeat that dynamics don't work. It's probably better to think of it as a way to ween people of dynamics, and of providing those who still want to use them with the option.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
but I haven't experienced "DLL-hell" on Windows since 95. Not that it doesn't happen, but is this a feature whose time is over before it arrives?
Now, (rpm|dpkg)-hell, that's another story...
Given the current cost of massive hard disks, why are programs still putting DLLs anywhere outside of ...\Program Files\Foo\dlls? I think most people would be happier losing some extra space per program due to DLL redundancy than to keep dealing with shared libraries!
Great... now when you install and uninstall a package, the DLLs are going to hang around (on purpose). I can see it now with a 13 year old that likes to install lots of little programs. Hopefully there is enough space on my hard drive.
I might as well note that this approach has some serious problems as well as the benefit of added simplicity, like:
- Only Apple can update the OS. That suits Apples goal of selling more copies of MacOS X, but shafts the customer slightly when they find that a few months after a new release comes out, applications start requiring it. See DirectX for contrast.
- Code reuse is stifled. On Windows, for the longest time JabberCOM was the de facto Jabber library. Most clients used it, and if you had more than one client installed, they'd share the same copy. There is no real mechanism for doing that, save shipping the framework inside every app, causing enormous bloat. So it doesn't happen very much.
- Modules are much "coarser" than say on Linux. I can't imagine MacOS developers getting together to share say 60k of code in a framework, it's just not worth it. That sort of thing happens all the time on Linux, and to a slightly lesser extent on Windows. Again, there's nothing wrong with depending on lots of shared code, it just has to be done properly.
Eliminating some of the key code sharing technologies (true dependancy management, strong component model) from MacOS X was I think a pretty big mistake - it bought them short term simplicity while making sacrifices in the longer term.Note that there is nothing wrong with a 3rd party application install upgrading parts of the OS, it's just that historically Windows has sucked at it. Look at Debian for an example of how this can be done well.
There might be a system running a hundred processes, but a typical windows system runs more like 8.
I currently have 6 programs running, I think that's pretty typical.
How many processes? 35.
Most running programs are less than 50% library code.
Hm, I'll read that as "running processes", since that's what's important.
Let's take one at random: winampa.exe
(winamp's "agent", the little toolbar dealie)
Total image is ~8MB
This includes:
- ntdll.dll: 492kB
- kernel32.dll: 724kB
- user32.dll: 400kB
- gdi32.dll: 240kB
- advapi32.dll: 368kB
- rpcrt4.dll: 448kB
- shell32.dll: 2300kB
- shlwapi.dll: 400kB
- msvcrt.dll: 280kB
- comctl32.dll: 552kB
- imm32.dll: 104kB
- shw95dll.dll: 124kB
- wow32.dll: 256kB
- ntvdm.exe: 644kB
- comdlg32.dll: 248kB
- version.dll: 28kB
- lz32.dll: 24kB
- winampa.exe: 36kB
I don't know about rpcrt4 or some of these, but shell32.dll alone is a huge fraction of its total size. Well over 50% of the memory use of this process is shared.
Trivial apps aren't, but how many trival apps do you run at the same time?
Is this a trivial process? That's about 7MB of shared code. If this is a typical amount (I believe it is), apps have to use >14MB to be less than 50% shared code.
How many do? Only 5 of the 35.