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."
I never really understood the advantages of a DLL over a static lib in modern times.
In the old days, when diskspace & memory were precious goods, they made sense to share code. But today, what's the burden of 4MB extra app size compared to the DLL misery ?
Except for plugins, I see no reason why developers would need DLLs. Can anyone shed some light here ?
When will I end this grieving ? When will my future begin ?
I always find it interesting that Microsoft gets to announce and shake up the world with "a new feature" that they caused and of which at least one other major OS had long since solved. Versioning the library API? "Who would've thunk it?!?"
In other news, Microsoft invents a journaling file system to prevent data loss.. oh, wait..
Bel, the mostly sane.. "Of course I can't see anything! I'm standing on the shoulders of idiots." -- Me
I wonder how they deal with upgrades to DLLs where the the upgrade represents a security fix. In such circumstances one would definetly not want an application to use an old version of a particular DLL...
I could see some possible security problems with this. When a DLL needs to be patched for a security issue it will only fix programs witht the correct version of the DLL. and the old version of the DLL wont be fixed. This is bassicly defeting the porpose of DLLs in the fact most applications will be using simular but slitght different versions of the DLL. At this point why not just compile everything staticly with DLL that way it is no longer an issue. As well as quicker and easer to install and uninstall.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I thought Microsoft already claimed to have fixed "DLL Hell" once or twice before with Windows 2000 and Windows XP. How many times are they going to "fix" the same problem?
One of the really annoying things about Microsoft is they always promise to fix something in the next version. It's always "next time" with them, but the problems never seem to go away.
As if you never had a library version problem under unix!
SlashDot regurgitates, period. NYT, Wired, whatever. The vast majority of the stories mentioned on SlashDot I've seen elsewhere, sometimes days earlier.
What's the problem?
This is not a "Breaking News" site, it's a community discussion board. One doesn't come here for "news," per se, but to read what like-minded people in the "geek community" think about that news.
You're getting upset because your dog doesn't 'meow.'
Almost all non-Windows operating systems avoid this DLL problem.
For one, Mac OS X uses bundles. Each application has its code as well as libraries all wrapped up in a single package. Only that app uses the libraries there. Clean, simple.
I doubt Microsoft's solution will solve the problem because their operating systems rarely show the cojones to stop an errant application from taking advantage of "features" placed within Windows that are self-compromising (e.g., Visual Basic Scripts, ActiveX). Some programming yahoo would just write something to override Microsoft's effort.
Windows could use a DLL manager similar to the old Mac OS Extensions Manager. Actually giving the DLLs easily recognizable names and clear version numbers wouldn't hurt either.
Aw, fuck--just chuck the damned thing and run a *nix, for cryin' out loud.
Vos teneo officium eram periculosus ut vos recipero is.
In order to solve "DLL confusion" in Windows, Microsoft are going to increase of the number of DLLs on the system, potentially by as much as there are applications installed, and give each DLL a unqiue, but symbolic only (xyz123:pdq098 versus msvcrt.dll for example) identifier.
One result is that from one machine to the next, not only will you not be sure what applications are using which DLLs, you will also have applications that use radically different identifiers for accessing their libraries.
This eliminates library confusion... how? I can't wait to have to troubleshoot it. Here's another solution Microsoft: document your standard libraries so that idiot application developers don't feel they need to re-invent the wheel and dump custom libraries all over the place.
Of course, the rest of us will continue using open source software.
Why bother.
Sounds like a great idea.... each and every program will have it's "own" DLL
Call me old-fashioned, but I thought the point of dynamic libraries was to reduce program size and duplication of effort by allowing multiple programs to load common functions out of libraries.
So, it's a great idea, insofar as it completely negates the advantage of having DLLs in the first place. Why don't they just compile statically instead?
and abandones the advantage of shared libraries: one DLL ABC which is used by several applications.
.NET metadata with a versionnumber.
Sharing a library has one disadvantage: the interface of the library should not change, otherwise using applications will crash. When an interface changes, you have to update the version. Now, you can do this in several ways, most likely this is doable by using a filename version scheme, or as in
The central point where you register shared dll's shouldn't be based on a directory though, but a central repository which holds ID's that refer to files on disk. This is implemented in COM somewhat: COM objects are stored in DLL's mostly and when you register a COM dll, its COM Objects are registered in the registry: each CLSID is stored with the physical file where to find the object. If you now store the files locally with the app, as it should be, you can register the com dll's and each application using a COM object with a given CLSID that is stored in the local stored dll can use them.
The problem arises when you install 2 applications which use the same DLL with the same objects, only application A uses v1.0 and application B uses v2.0. v2.0 of the library has all the objects of v1.0 but also newer objects. You first install A. All dll's are stored local. Then you install B. A works, it will probably use the dll of B because B registered all teh objects with the local stored DLL. When you UNinstall B, A will not work anymore, unless you keep the dll with the objects around. Most people don't do this ("Hey the uninstaller left some dll files behind!" *executing del command*). That's DLL hell.
What's best is thus a central repository (Be it the GAC or the registry) and a central store which allows multiple versions of a DLL to be stored. I'm pretty sure that's what MS is heading at, and not your MacOS X nor any Unix does this.
Never underestimate the relief of true separation of Religion and State.
I have not read the article, but I think this simply works by allowing different versions of the same DLL. If you have two programs that require the same version of the same DLL, they'll both use that DLL. However, if you install a new program that wants to install a different version of an already-installed DLL, that program will use its version of the DLL while allowing other programs to continue using the pre-existing DLL.
As long as a libraries API doesn't change between major versions (as it should) there is no problem.
Unless the semantics of an API change subtly from one version of the DLL to the next. This is sometimes done to fix bugs, security holes, etc. in one version of the DLL. You wouldn't believe how many proprietary programs in practice rely on undocumented behaviors of specific versions of libraries.
Will I retire or break 10K?
the app will use the .dlls from its local directory and unless it is running in a 3.1 environment it will not encounter any possible conflicts. Amazing how what is old is new again.
Caution -- printing is no longer well supported from the sixteen bit compatibility so a workaround is needed but the rest continues to work well. Not sure about sockets, haven't tested.
Thank you for pointing this out. There've been other good comments around the board about DLLs and how sharing should work, but you're evidentally the only one who's read the article and understands the technology.
.NET 1.0 as well.
.NET assemblies? That choice alone has caused more issues than I have ever seen (name conflicts between a COM DLL and a corresponding .NET interop assembly DLL, people trying to register a .NET assembly DLL with regsvr, VB6 allowing you to attempt to use a .NET DLL as a component when it doesn't work, etc. etc. etc.) While they may be "dynamic link libraries" in a traditional sense, they're not ".DLLs." Chalk the reporter up as one more of the confused.
The feature was present in
I've always wondered, though... why did MS choose to keep the extension ".DLL" for
They're probably doing it to break WINE as well. DLL problems aren't that bad with Win2k and XP, system DLLs are protected and with XP you can go back to a restore point.
If an app installer is so badly written that it messes up your installation then the software can't be much good either.
First, what are the advantages of DLLs?
- Less Memory Footprint
- Less Disk Footprint
- Global Security Fixes
- Use of third party binaries
- Plug ins
Less Memory FootprintIn Unix, when you have two instances of an application running, say, vi, the executable code between the two is automatically shared. The shared library gains you nothing. To gain memory footprint, you need to use the same shared library from two applications at the same time. For example, libc might be used by vi and cc.
However, if you compile statically, you bind in only the routines that are needed. For shared libraries, you need to have all routines available, since you don't know which of them are used. Now, your virtual memory system may notice that a shared libary page isn't used, and page it out. Yes, this requires additional run time execution time. The upshot is that you save memory only when you have enough different programs use the same shared library to overcome the overhead. I claim that this happens with libc, libX11, and not a whole lot else.
Less Disk Footprint
If you have 50 programs that use the same shared library, you can save some disk space becasue that libary code does not need to be duplicated that many times. However, shared libraries need to have the symbol information requried to perform the dynamic binding. The savings isn't that much.
In the old days, when an entire Unix distribution fit on a 150 MB tape, the libc shared library savings amounted to about 30%. You could get more reduction in size by using compression.
In fact, programs could be compressed on disk. The loader could decompress the image as it reads it into RAM. For slow disks, this may be faster than loading the uncompressed version into RAM. The down side here is that you then may not be able to use the original file on disk for virtual memory paging.
In any case, it's getting hard to get a disk drive under 20 GB. 30% overhead reduction for the most common shared library doesn't amount to much.
Global Security Fixes
So, your libzlib.so.5 has a bug. You whip up a quick fix, create a new libzlib.so.5, and drop it into your system. You've just fixed all of your libzlib dependent programs, right? In fact, you fixed programs you didn't even know used libzlib. You may also have broken programs that you didn't know use libzlib. And, short of testing every program on your system, you don't know. The more complex the patch, the more likely you are to have broken many things.
Quick. What is a utility which will tell you all the shared libraries that an application uses?
Use of third party binaries
Third party binaries can just as easily be distributed in source form or in a library that is statically bindable. Static binding is preferable, since you are unlikely to use a large fraction of a kitchen sink shared library - where the authors have no idea how the programmers will use it. Source is preferable, since the documentation rarely specifies enough semantic detail to allow proper use.
Plug ins
OK. Your application is Apache, and you want some real flexibility. If Apache is compiled so that modules can be loaded at run time, then the administrator can add the new module and turn on it's use in the configuration. This doesn't save any RAM or disk, but it may allow the admin to change a line of config, restart the web server, and start using some new feature.
For Apache, the admin can also recompile with the new module compiled statically. I've done it both ways. My measurements show a small run time advantage to static compilation.
Granted, if you can't recompile IIS, then DLLs will give you the same flexibility in exchange for a small performance penalty.
The Dark Side of Shared Libraries
If you compile your application statically, then upgrade your OS, you can copy the old application to the new OS, and it just runs.
If your app has shared libraries, you have to track them down on your old OS, and copy them to your new OS. If you make a mistake, and copy your old libc.so over your new one, you run the risk of trashing every program on your new system. Brilliant.
Take netscape as an example. It comes installed in it's own /usr/local/lib directory
tree. In /usr/local/bin, netscape is a
script which sets up the shared library search
path to include the libraries that netscape needs,
then runs the binary. This introduces script
overhead
and shell dependencies on a complicated package.
And, when you upgrade your OS, you still need
to find the old libc.so and copy it forward.
RPMs
Many seem to think that RPMs solve all these problems. However, many packages have bugs in their dependencies, etc. Many RPMs use different versions of the same shared libraries. I find that I have to override the dependencies to get stuff to install. Often, the requried package IS installed. Not just once in awhile. Much of the time. The difference between theory and practice is that, in theory, they are the same.
Conclusions
Shared libaries seldom save RAM or disk space. The problem with using them to fix bugs globally is that you don't know what you fixed, or even if you broke some things. Third party binaries should invariably be statically linked. In an open source environment, plug ins are not strictly needed. Shared libaries make OS upgrades more painful.
So, what I'd like is a Linux distribution with no shared libaries. The compiler, gcc, would be configured to compile statically by default. Then, after some years of running the system in production, and after adding hundreds of applications to it, I'd be able to upgrade to a new distribution without having to recompile or do the shared library search.
-- Stephen.
Unfortunately, even when 1GB is standard, the problem is that people will be running Windows KAE-T (Kick Ass Experience - Trusted) which requires about 927MB of memory without themes.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Sure if this capability were overused it would be a mess. On the other hand, judicious use of it would solve a lot of problems. Normally I'm not a fan of MS but if they do it right (big if I know) it's a GOOD idea.
Maybe some policy would help a bit. I'm thinking that things like services, especially public net facing ones be forced to use the latest DLL whether it breaks anything or not. If it's compatible, the service stays up. If it's not the service dies and doesn't make a public nuisance of itself. Reporting tools would help too. If it were easy to get a list of which apps were using which DLL, it would be possible to intelligently manage the situation. For that matter, make apps use the newest by default and then fall back to the oldest only if that doesn't work and it isn't a public facing service.
Yes, this can cause problems but if they include the right tools and sane policy they're managable. This isn't intriniscally new VMS did something like this. Unix admins have been doing manually for years. MS just wants to automate it.
Yes. It's amazing that MVS had concepts such as the Link Pack Area (LPA) and Link List Lookaside (LLA) over twenty years ago and OS designers are still trying to get to grips with essentially the same problem.
There's still a lot of stuff in MVS (even base 3.8 circa 1980) that modern OS designers could learn from - but they think they have to invent it all.
Yes but this raises a new security threat. Say there is a remote root hole in a certain DLL. If you get the newest version, some programs will still use the old DLL, witht he hole staying behind. That could be a big problem.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I have raised this point in the past, but it once again applies:
With storage space being so inexpensive and abundant, all programs should be fully independent, self-contained entities. The idea of linking programs against a set of standard set of DLL's is a great way to make smaller programs, but if you haven't noticed small and efficient is not the most important aspect of any program these days.
DLL's and Linux's library dependencies can be completely solved in this way, and management would become much simpler.
And, for those who believe that this would mean huge programs... take a look at the Phoenix web browser, it installs completely in it's own folder and is still very small and efficient.
www.GamezCore.com For Hardcore PS2 Gamerz : By Hardcore PS2 Gamerz
Even though this article isn't really about DLL's, why do we have NEWER versions of DLL's breaking applications anyway? The whole point of making a new minor release of a piece of software (DLL, component, whatever), is to fix things, NEVER to change the API or change the behavior of existing functions. It's these changes that break existing applications.
New major releases should be considered a completely different DLL/component, since it conceivably has a different API or changes its behavior in some incompatible way.
It seems to me that DLL's/components need to be treated as self-contained applications. They need to go through a rigorous testing and QA cycle (except that they don't generally expose anything directly to the users, but to other applications), and need to be installed as if they were their own application. Windows applications that have dependencies on DLL's can, during installation, tell the OS which DLL's they need and what the minimum version should be.
Bundle these with the application if you need to, but to suggest that DLL's/components need to be kept at the same *minor* version to avoid breaking applications indicates a bad problem with how you build and test DLL's. I'd rather fix this problem than introduce this layer of version matching.
Why do you invision[sic] that? This system is actually going to prevent such a thing. As it is on a Windows platform if you install an old program that needs and installs an older dll it will simply overwrite the newer one causing new programs to break. It's called dll hell and it's been the scourge of win32 developers for a long time. This new system allows the old program to install the version it needs but the system still has a copy of the new one that the newer programs need and each program calls it's respective dll.
.Net handles dll versions using the
.Net, if you prefer you can instead simply copy the dll to the bin directory inside the application directory and that application will use that dll. That's usually refered to as XCOPY deployment.
If you want more information on how this is going to work simply look into how
Global Assembly Cache (GAC):
The GAC can be used to register a dll on a system wide basis and allow other programs on the machine to link to that dll. It handles the different versions of each dll and how they are configured. BUT you do not have to use the GAC to use a dll within
The trade off of this system is that you have more files on the filesystem which need to be managed. It has it's own drawbacks. But to anyone who's ever f'd a win32 machine because a system dll got replaced when they installed that dvd player app from 1997 and it just happened to replace a critical system dll that was just updated in the last service pack, this is a godsend.
What you are describing is essentially 'modular programming' which IIRC was the hot methodology in the mid 1970's. The whole idea of loadable libraries as opposed to statically-linked monolithic programs arose from this way of thinking.
It seems we are doomed forever to reinvent the wheel. Each new generation of computer scientist repeats what his forefathers did - only somewhat less efficiently and with more fuss and expense.
I code in assembly and a few other languages. I can understand that it can be a very good thing to reuse one piece of code in several different places. I understand also that it can save space to reuse. No news here...
As for the idea of "Strong Binding", I wonder what Billy G. expects to acomplish by adding yet more poorly designed, poorly documented LIBs to the programming mess that Windows has evolved into. On top of that, I wonder why I would need to save EVERY SINGLE VERSION of a DLL that makes it to release...
Version tracking will become a nightmare.
Consider:
+User installs program COOL_PROGRAM.EXE
-COOL_PROGRAM uses MS_COOLNESS.DLL
+User gets an update to MS_COOLNESS.DLL:
MS_COOLNESS_V2.DLL
-The fix in V2 repairs a buffer overflow
in a function that COOL_PROGRAM used from
COOLNESS.DLL.
Question : Does the installer for V2 know that COOL_PROGRAM is dependent on it? If this is the case, Billy G. is gonna have his hands full trying to keep track of what goes where with third party devs.
If not, perhaps COOL_PROGRAM will go by default to the newest version of COOLNESS.DLL. Ok, now Billy will likely contend with tracking and modifying functions that have previously been used in highly specialized ways for security/system critical functionality that Windows does not provide either by accident or by intention. So NOW third party devs developing well organized and functional code/programs are forced to keep up with the madness of Windows development to save space. Hmmm... Guess it got the better of the buffer overflow this time. Or maybe they introduced a new bug into the system {par for course with MS}...
Better yet, how about people developing security/system critical environments use their own code to avoid this whole mess? Ok, now you dont need DLLs do you? How about 3-5 times as many? Wait for the next Windows release? So the effort YOU made during XP to keep up with DLLs and other updates is pointless right? Or XP+1? The style of MS defines itself....
Security/system critical programs?...
Thats only one side?...
Ok. Try this:
Graphics, network comunication, encryption, file editing, database editing? Or maybe drivers, file converters, scripts, inter-app comunication, diagnostics?
The list goes on. The problems generated by and complications arising from this framework are not worth the hassle.
Instead of building a system where things get more complicated I would recomend a redesign of the system itself. Current and past states of instability/insecurity are more than I care to witness again. Billy has enough money to sit around daydreaming for the rest of his days while still paying his programers for doing nothing but daydreaming themselves for the rest of theirs... Perhaps they could get up off their butts and design a system from the ground up that is easy to use, safe, fast, and reliable for users old and new... Logical?
I love C programming. C++ and Java are lots of fun. But IF you want something done right the first time, assembly and careful thought is the only answer...
S-()-u-|-s-!-|)-E
I really don't think WINE was high on their list of priorities here. I think their idea had several desired outcomes:
.NET API, and
1 - force all non-longhorn users to upgrade
2 - force all software vendors to code to the new
3 - integrate SQL*Server into the OS
Also, imagine what a nice kick in the teeth to Java (which I'm sure is a bigger radar blip than WINE) this will be. I think this will backfire on them, lack of full backwards compatibility is *one* of the reasons why XP never took off. This one lacks any backwards compatibility so you can just extrapolate the barriers to adoption.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
ls /usr/lib
Mcrt1.o X11 apache bcc bison.hairy bison.simple cgi-bin cracklib_dict.hwm cracklib_dict.pwd cracklib_dict.pwi crt1.o crti.o crtn.o cvs docheckgroups elm emacs entity-map games gcc-lib gconv gcrt1.o getopt gnupg groff innreport_inn.pm innshellvars innshellvars.pl innshellvars.tcl ispell kbd ksirc ldscripts libBrokenLocale.a libBrokenLocale.so libIDL-0.6.so.0 libIDL-0.6.so.0.4.4 libIIOP.so.0 libIIOP.so.0.4.0 libImlib.so.1 libImlib.so.1.9.7 libORBit.so.0 libORBit.so.0.4.0 libORBitCosNaming.so.0 libORBitCosNaming.so.0.4.0 libORBitutil.so.0 libORBitutil.so.0.4.0 libQwSpriteField.la libQwSpriteField.so libQwSpriteField.so.1 libQwSpriteField.so.1.5.0 libapm.a libart_lgpl.so.2 libart_lgpl.so.2.1.0 libaudiofile.so.0 libaudiofile.so.0.0.0 libbeep.a libbfd-2.9.5.0.22.so libbfd.a libbfd.la libbfd.so libbsd-compat.a libbsd.a libbz2.a libbz2.la libbz2.so libbz2.so.0 libbz2.so.0.0.0 libc.a libc.so libc_nonshared.a libc_stubs.a libcfont.a libcfont.la libcfont.so libcfont.so.0 libcfont.so.0.0.0 libconsole.a libconsole.la libconsole.so libconsole.so.0 libconsole.so.0.0.0 libcrack.so libcrack.so.2 libcrack.so.2.7 libcrypt.a libcrypt.so libctgeneric.a libctgeneric.la libctgeneric.so libctgeneric.so.0 libctgeneric.so.0.0.0 libctutils.a libctutils.la libctutils.so libctutils.so.0 libctutils.so.0.0.0 libcurses.so libdb.a libdb.so libdb1.a libdb1.so libdl.a libdl.so libecpg.a libecpg.so libecpg.so.3 libecpg.so.3.0.0 libefence.a liberror.txt libesd.so.0 libesd.so.0.2.17 libesddsp.so.0 libesddsp.so.0.2.17 libfbm.a libfbm.so libfbm.so.1 libfbm.so.1.0.0 libfish_applet.a libfish_applet.la libfish_applet.so libfish_applet.so.0 libfish_applet.so.0.0.0 libfl.a libform.a libform.so libform.so.4 libform.so.4.0 libg++.so.2.7.2 libg++.so.2.7.2.8 libg.a libgd.so libgd.so.1 libgd.so.1.2 libgdbm.a libgdbm.la libgdbm.so libgdbm.so.2 libgdbm.so.2.0.0 libgdk-1.2.so.0 libgdk-1.2.so.0.5.1 libgdk_imlib.so.1 libgdk_imlib.so.1.9.7 libgif.a libgif.so libgif.so.3 libgif.so.3.1.0 libgif.so.4 libgif.so.4.1.0 libgkb_applet.a libgkb_applet.la libgkb_applet.so libgkb_applet.so.0 libgkb_applet.so.0.0.0 libglib-1.2.so.0 libglib-1.2.so.0.0.6 libgmodule-1.2.so.0 libgmodule-1.2.so.0.0.6 libgmp.so.2 libgmp.so.2.0.2 libgnome.so.32 libgnome.so.32.3.8 libgnomesupport.so.0 libgnomesupport.so.0.0.0 libgnomeui.so.32 libgnomeui.so.32.10.3 libgnorba.so.27 libgnorba.so.27.1.8 libgnorbagtk.so.0 libgnorbagtk.so.0.0.0 libgpm.a libgpm.so libgpm.so.1 libgpm.so.1.17.3 libgrove.a libgrove.la libgrove.so libgrove.so.1 libgrove.so.1.0.3 libgthread-1.2.so.0 libgthread-1.2.so.0.0.6 libgtk-1.2.so.0 libgtk-1.2.so.0.5.1 libgtkxmhtml.so.1 libgtkxmhtml.so.1.0.1 libgtop.so.1 libgtop.so.1.0.5 libgtop_common.so.1 libgtop_common.so.1.0.5 libgtop_guile.so.1 libgtop_guile.so.1.0.5 libgtop_guile_names.so.1 libgtop_guile_names.so.1.0.5 libgtop_names.so.1 libgtop_names.so.1.0.5 libgtop_suid_common.so.1 libgtop_suid_common.so.1.0.5 libgtop_sysdeps.so.1 libgtop_sysdeps.so.1.0.5 libhistory.a libhistory.so libhistory.so.3 libhistory.so.3.0 libiberty.a libieee.a libimlib-bmp.so libimlib-gif.so libimlib-jpeg.so libimlib-png.so libimlib-ppm.so libimlib-ps.so libimlib-tiff.so libimlib-xpm.so libisapnp.a libjpeg.a libjpeg.la libjpeg.so libjpeg.so.62 libjpeg.so.62.0.0 libjs.la libjs.so libjs.so.0 libjs.so.0.2.0 libjscript.la libjscript.so libjscript.so.2 libjscript.so.2.0.0 libkab.la libkab.so libkab.so.2 libkab.so.2.0.0 libkdecore.la libkdecore.so libkdecore.so.2 libkdecore.so.2.0.0 libkdeui.la libkdeui.so libkdeui.so.2 libkdeui.so.2.0.0 libkdlgloader.a libkdlgloader.la libkdlgloader.so libkdlgloader.so.1 libkdlgloader.so.1.0.0 libkfile.la libkfile.so libkfile.so.2 libkfile.so.2.0.0 libkfm.la libkfm.so libkfm.so.2 libkfm.so.2.0.0 libkhtmlw.la libkhtmlw.so libkhtmlw.so.2 libkhtmlw.so.2.0.0 libkimgio.la libkimgio.so libkimgio.so.2 libkimgio.so.2.0.0 libkplunger.a libkspell.la libkspell.so libkspell.so.2 libkspell.so.2.0.0 libkudzu.a libl.a liblinuxconf.a libltdl.a libltdl.la libltdl.so libltdl.so.0 libltdl.so.0.1.2 libm.a libm.so libmcheck.a libmediatool.la libmediatool.so libmediatool.so.2 libmediatool.so.2.0.0 libmenu.a libmenu.so libmenu.so.4 libmenu.so.4.0 libmimelib.la libmimelib.so libmimelib.so.1 libmimelib.so.1.0.0 libmodules.a libncp.so.2.3 libncp.so.2.3.0 libncurses.a libncurses.so libncurses.so.4 libncurses.so.4.0 libndbm.a libndbm.so libnewt.a libnewt.so libnewt.so.0.50 libnewt.so.0.50.8 libnsl.a libnsl.so libnss1_compat.so libnss1_db.so libnss1_dns.so libnss1_files.so libnss1_nis.so libnss_compat.so libnss_db.so libnss_dns.so libnss_files.so libnss_hesiod.so libnss_nis.so libnss_nisplus.so libopcodes-2.9.5.0.22.so libopcodes.a libopcodes.la libopcodes.so libpanel.a libpanel.so libpanel.so.4 libpanel.so.4.0 libpanel_applet.so.0 libpanel_applet.so.0.0.0 libpbm.a libpbm.so libpbm.so.1 libpbm.so.1.0.0 libpci.a libpgm.a libpgm.so libpgm.so.1 libpgm.so.1.0.0 libpgtcl.a libpng.a libpng.so libpng.so.2 libpng.so.2.1.0.5 libpnm.a libpnm.so libpnm.so.1 libpnm.so.1.0.0 libpopt.a libpopt.la libpopt.so libpopt.so.0 libpopt.so.0.0.0 libposix.a libppm.a libppm.so libppm.so.1 libppm.so.1.0.0 libpq++.a libpq++.so libpq++.so.3 libpq++.so.3.0 libpq.a libpq.so libpq.so.2 libpq.so.2.0 libpsqlodbc.a libpthread.a libpthread.so libpuke.a libpuke.la libpuke.so libpuke.so.0 libpuke.so.0.0.1 libreadline.a libreadline.so libreadline.so.3 libreadline.so.3.0 libresolv.a libresolv.so librle.a librle.so librle.so.1 librle.so.1.0.0 librpcsvc.a librpm.a librpm.la librpm.so librpm.so.0 librpm.so.0.0.0 librpmbuild.a librpmbuild.la librpmbuild.so librpmbuild.so.0 librpmbuild.so.0.0.0 librt.a librt.so libslang.a libslang.so libslang.so.1 libslang.so.1.2.2 libsnmp.so.0 libsnmp.so.0.4.1.1 libsp.a libsp.la libsp.so libsp.so.1 libsp.so.1.0.3 libspgrove.a libspgrove.la libspgrove.so libspgrove.so.1 libspgrove.so.1.0.3 libstdc++-2-libc6.1-1-2.9.0.a libstdc++-2-libc6.1-1-2.9.0.so libstdc++-libc6.1-1.a.2 libstdc++-libc6.1-1.so.2 libstdc++.so.2.7.2 libstdc++.so.2.7.2.8 libstdc++.so.2.8 libstdc++.so.2.8.0 libstdc++.so.2.9 libstdc++.so.2.9.dummy libstyle.a libstyle.la libstyle.so libstyle.so.1 libstyle.so.1.0.3 libtermcap.a libtermcap.so libthread_db.so libtiff.a libtiff.so libtiff.so.3 libtiff.so.3.5 libttf.la libttf.so.2 libttf.so.2.2.0 libucdagent.so.0 libucdagent.so.0.4.1.1 libucdmibs.so.0 libucdmibs.so.0.4.1.1 libungif.a libungif.la libungif.so libungif.so.3 libungif.so.3.1.0 libungif.so.4 libungif.so.4.1.0 libutempter.so libutempter.so.0 libutempter.so.0.5.2 libutil.a libutil.so libuulib.la libuulib.so libuulib.so.5 libuulib.so.5.0.13 libvga.a libvga.so libvga.so.1 libvga.so.1.4.1 libvgagl.a libvgagl.so libvgagl.so.1 libvgagl.so.1.4.1 libwrap.a libz.a libz.so libz.so.1 libz.so.1.1.3 libzvt.so.2 libzvt.so.2.2.6 linuxconf linuxconf-devel mail.help mail.tildehelp metamail mh mime.types more.help mpage netscape nmh nslookup.help perl5 pgsql pmake python1.5 qt-1.45 rhs rpm sendmail sendmail.hf sgml sgml-tools slrn trn uucp yp
They're probably doing it to break WINE as well. DLL problems aren't that bad with Win2k and XP, system DLLs are protected and with XP you can go back to a restore point.
Gimme a break. DLL Hell has been a problem for a long long time so when they actually try and fix it they are now only trying to fix it to break WINE? That's a strech and I'm sure you know it. Yes you can go back to a restore point but that does not solve the problem. Now one app works but the other doesn't because they are both calling the same dll expecting different versions. Restore points are a temporary solution to a legit problem.
If an app installer is so badly written that it messes up your installation then the software can't be much good either.
So using the current system how do you propose that app developers deal with this? Say when I compile against a dll I am expecting version 1 and it works fine. Three years go by and the dll has gone through 2 new versions released with the latest service pack. Someone installs my application and it copies the old dll over the new one. The system is now screwed. My other option would be to link dynamically and since the new version is on the machine my application simply wouldn't work. BUT using the new system both my application and other applications would work fine, using their appropriate dlls. So how is this a bad thing again?
Can anyone propose a better solution? If so I'm all ears.
Simple. If MS wasn't so much spaghetti code, the problem of backward compatibility would never be a problem in the first place.
.dll, and what does it do to the old functions? Nothing. The older programs are still calling the old functions, and they work just the same way they used to, BECAUSE THEY'RE THE SAME CODE! If it's the case of a bug fix, or something like that, well, sometimes it can't be helped, but even still, no bug fix should fundamentally change the API to a function so radically that it breaks applications that rely on it.
You add new functions to a
Also, no installer should blindly overwrite system files. Version checking is pretty simple, and should always be done before overwriting.
If you're a programmer, and you don't realize this, you shouldn't be programming.
Isn't there one person at Microsoft that sees how Dynamic libraries have been done in UNIX?
Put the version in the name of the DLL file name.
We do not need another level of untracible indirection in the registry.
Have each file have the correct phsical name.
i.e. lib-1.2.dll
Let the program decided latest or specific version. And have the system support this. If I want the latest lib-1.x.dll get it. Latest lib-x.x.dll get it. But directly, not by another dereferencing "ID" in the registry. These clowns love their obscurity.
If an app installer is so badly written that it messes up your installation then the software can't be much good either.
I don't think that's so much the issue. One thing I *hate* is a seeminly simple installation that then requires a reboot.
But, as a bit of a Windows programmer myself, I understand it. If a program happens to require a newer version of some DLL, that is currently in use, it can't replace it. And with Windows' current system, you can't just use a local copy of it either.
When a program loads up a DLL, you can't specify a full path, just the filename. Windows has a specific search order, and the first place it checks is memory. "someapp.dll" is already loaded, so it uses that code -- even if you have a newer version in your own program directory.
I've always wondered why the hell they went with this approach. You have to watch for name conflicts between private DLLs (my program may happen to have "mp3.dll", which is completely unrelated to some other program's "mp3.dll"). And of course if an application uses a newer version of a system DLL (common controls library is a commonly-upgraded one), replacing the system-wide DLL is required, and naturally a reboot is required. And there's always some chance this upgrade may break an older application...
You can also forget about renaming a copy for private use, too; many of the system DLLs reference eachother by name. It works if you hex-edit them to reference the new names (I did this only as a proof-of-concept with VB runtimes)...
In my opinion, the best/easiest solution for developers would be to chnage the search order to start in the application directory -- or better yet, only do this if some registry flag is set, so older apps can have the current default behavior...
However, anything to aleviate this would be nice...
NGWave - Fast Sound Editor for Windows
Unix had journaling years before any Windows system did.
This whole Slashdot story thread is retarded. Obviously no one read the article to see that this really only applies to .NET (ASP/VB/C#/etc.)
.NET takes care of the rest. Piece of cake.
.NET Framework installed, I'd suggest checking out %systemroot\Assembly\ [to see all the assemblies you current have installed, and their versions] and also the "Microsoft .NET Configuration" program under Administrative Tools. In there is an entire interface dedicated to managing the GAC.
.NET rocks the hizzy.
I can't tell you what an improvement assemblies are compared to a "component"/COM object. You'd have to build your DLL, then regsvr32 it into the system.. and if you ever needed to update the DLL, you'd have to stop your service/app that uses the DLL, then regsvr32 -u it... and then overwrite the existing file, then regsvr32 it again, and start your service/program back up..
And now? You just overwrite the DLL.
If you have
It's pretty cool stuff.
Not All Who Wander Are Lost
It's a LOT more complicated than that. Microsoft is trying to solve a very real problem that has plagued developers on EVERY platform that supports DLLs, including Linux. Using symlinks is just one approach. And while it does solve some of the problems, it is not a complete solution.
.Net framework uses, but it is NOT limited to .Net DLLs -- traditional "unmanaged" code can use this, too. I won't go into details here, because it's very well-documented elsewhere, but suffice to say that developers will have a LOT more control over how apps and DLLs bind to DLLs. This is purely a Good Thing, and it IS fully backward-compatible -- it's an opt-in.
Here's one of the main situations that Microsoft is trying to address: Microsoft ships FOO.DLL with Windows, or as part of some SDK (like DirectX). Company 1 develops an app, ships it, and on the app CD, it has a copy of FOO.DLL. Company 2 does the same thing.
Now. A bug is discovered in FOO.DLL, and it must be fixed. Unfortunately, fixing it one way causes app 1 to crash, and fixing it the other way causes app 2 to crash. And both apps link to the same version.
So what do you do? In the past, you just crossed your fingers and looked the other way, and tried to write code that behaved as best as possible in whatever circumstances you could think of. But inevitably bug fixes cause other bugs (regressions).
So, Microsoft is trying to solve this, by changing DLL binding, in two important ways:
1) DLL binding will use much more than just a name. Microsoft has developed a very powerful & flexible way to do DLL binding. This is what the
2) You'll have total control over redirecting DLLs, on a per-app basis. Some docs here. This means that you can override DLL binding -- if app 1 MUST have version 4.3.5.1.34 of FOO.DLL, and app 2 MUST have version 4.3.5.1.35b, then you can write a simple XML file for each one, that controls exactly which version they get.
Anyone who reads some kind of evil into this is just plain stupid, and has never done any serious development. Any programmer worth their salt knows that DLL binding is ridiculously crude -- and that goes for every modern platform. Microsoft suffers from this more than most, and has therefore decided to do something about it, and has designed a pretty good system. If you have half a brain, you should check it out, and try to keep that knee-jerk reaction under control. (I'm not directing that comment at Grishnakh, but at all of the slobbering idiots who just flame Microsoft whenever they see the name in a headline.)