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."

Comments

Auto-DLL Managment?

[MSTCrow5429]

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.

Re:Auto-DLL Managment?

[n3k5]

... at least each and every program will have it's "own" DLL ...

Ah, yes, what a wonderful idea; let each and every program have its own DLLs, at the mere cost of rendering the whole DLL system totally useless.

You see, if you just wanted to split your executable code over several files for one reason or another, you could include DLLs with your program (in its own directory) ever since. Those wouldn't ever be changed by Windows, but this has nothing to do with the registry. The whole idea behind registered DLLs that reside in a centralised place is that you have shared libraries, that you don't have to store code used by several programs in multiple places, but only once, where you can do easy updates.

However, now that there are so many versions of Windows out there, Microsoft is experiencing compatibility issues with DLLs and they're doing something about it. I'm not familiar with the details of their solution and don't want to say it's a bad one at all. But your ideas are a little too extreme; saving one copy of a DLL per program is just absurd.

Re:Auto-DLL Managment?

[WindBourne]

While a sibling poster pointed out that the admin could change it, you have probably hit on where MS is going. I suspect that MS will simply drop the admin capability.
The versioning problem could have been handled with an external nameing approach (name-version.major.mindor.dll) and then using a resolver program. They are electing to give an internal id which implies that dlls will not be in one place or will have different names. This will make it hard to change out dll or know which ones to transport.
Actually, just thinking about it, I've heard that longhorn is supppose to have a sql based file system. It would make it easy to sux this into it and use the id as a way to find the dll. You will simply need to know it.

Re:DLL vs static libs

[Anonymous Coward]

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).

Garbage collection

[dachshund]

Just as long as Strong Binding knows when to garbage-collect the old DLLs that aren't being used anymore, even if the uninstaller fails to explicitly remove them.

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.

What about patches and security fixes?

[Raphael]

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.

DLLs

[chenry007]

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?

Unsolvable?

[Hard_Code]

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*.

There's a Bigger Picture Here!!

[CrazyLegs]

Great... MS has discovered versioning and makes a big announcement. But what is really going on here is that MS is trying to design their way out of a more fundamental design problem that has plagued Windows since Day One. That is, they allow system-level software (DLLs) to co-mingle with software others have written. How many Windows shrink-wrap products have taken advantage of this feature by modifying base Windows DLLs, tripping the light fantastic over system-level directories, etc.??

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!

Re:DLL vs static libs

[oconnorcjo]

Agreed. Windows XP gobbles up about 110 megabytes of RAM when it's just booted, without any background images, screensavers, system tray apps running etc. 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.

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.