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
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 ?
How does Linux deal with the issue of linked libraries? I'm assuming it has something similar.
You really can't win... One nice thing about shared libraries is that you ~can~ upgrade the libraries independent of the applications. If there turns out to be a nasty buffer overflow you can fix the library and all the applications get fixed.
If an application is tied to a particular DLL, you'll have to replace the DLL and ~all~ applications that depend on it. Similarly, if you add features to the DLL (say a better file-picker dialog box or more features in something like GNU readline) you don't get the new features.
Just more confusion for Wine.
DLLs were always to me one of the largest reasons preventing programming for a Windows platform. I've never been able to find adequate information to help simplify using them, and since the topic is DLL's, I was just wondering if anyone had any good resources for programming to make use of DLL's.
hrrm.
When you recompile a new version, why not call it shell32_444.dll, for example, instead of shell32.dll. That way you could refer to the version you wanted by file name.
by the end of this, I'm gonna have 1,000,000 files in system32.
Now Microsoft is hoping to end when has become known as DLL Hell by building into Windows Server 2003 a system that will stop updated DLLs installed by new applications from overwriting older versions of the same DLLs that may still be used by existing applications.
W2003 - W95 = 8 Years to have that briliant idea!
Of course, it will only apply to dotnet assemblies, where strong name is created by signing the file by the vendor (the side effect is eliminating any modifications to shared libraries).
Anyone interested in these things should read documentation in net sdk. It will not solve native code dll hell, nor it will solve hunger in the world, yada yada.
Nothing to see there, move along folks.
This will solve some problems where installing software blows away a specific version of some DLL that is required by some other piece of software, but at the expense of introducing hard to solve problems where two programs A and B expect to use the same DLL, but end up using different ones. Knowing M$, it will probably not be possible to manually change which version is linked in.
What I envision with this system, is that old programs will probably break new ones, ie. make it impossible to install them or run well.
With the large amounts of harddrive space that comes standard with just about every computer why should single DLLs still be referenced by different programs? How about we get back to self contained programs? The slight install size increase would certainaly be worth it.
Chika Chik-ah... do-e ow ow.
DLL clutter uses up HD space and more importantly increases number of directory entries in system directories and smallish fragmentation-inducing files. This hurts HD performance and uses CPU power, thus driving the development forward at this sad time, when ancient, many years old computers can reasonably run even the newest office applications.
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...
From what I've seen, Gentoo already has.
Life sucks, but death doesn't put out at all....
--Thomas J. Kopp
Not if you depend on Redhat ^_^
Sorry, but my karma just ran over your dogma.
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.
Microsoft re-invents static linking.
Christ, if you are going to do this, why not create a recompiler that bundles the executable and all of its referenced DLLs into one EXE and be done with it.
As a nice side effect it'd make it a hell of a lot easier to move programs around your disk and between machines... Oh, ok, now I get it.
-josh
I already have to juggle DLLs, I don't want to contend with windows...
from article: "copy capability files, directories and even whole drives from one destination to another. "It is good for scaling out--it means you can copy applications instead of reinstalling them" sounds to me like this is an attempt to catch up to open source in the areas where ms lags behind... it sounds like a good thing, but i have to wonder, won't this be a huge open door for piracy? i mean, software pirates don't typically use windows server, but what prevents them from starting?
In the days of limited disk space, I could see a reason for reusing the same .DLL for applications. However, what are the issues involved in just plain putting all needed .DLL's in the same folder with the application? This would end .DLL hell by making it so that each program only uses the .DLL's that they install. True, there might be multiple copies of COMCTL32.DLL, but so what? we've got the disk space. What other issues are involved?
The preceding comment has been reviewed and declared to be compliant with HIPPA Phase II regulations.
I might be feeding the trolls here, but...
As a RedHat user, I don't know what all the complaints are about. RPMs are very easy to use, whether it's installing, upgrading, removing or even building them. The system was created to make package management easy as well as to satisfy the dependencies of all the programs. Installing the correct packages and not using the '--nodeps' or 'force' options maintains a nice clean and happy RPM database. It don't see what all the complaining is about.
Signed,
A very happy RedHat user since 1998.
P.S. To the Debian users who cry "apt-get, apt-get!" I use Apt for RPM, and that kicks ass too...
------
Random, useless fact: I type in startx entirely with my left hand.
This is a capability of the .NET framework. It has nothing to do with the next version of Windows.
.NET assemblies. .NET assemblies are the equivalent of DLLs for the .NET system, but this won't solve the problem of "DLL hell" unless all applications are re-written in .NET.
.NET, but this article is just the Microsoft PR/marketing machine, and is nothing new technically.
It isn't really DLLs either, but rather
This is a great feature of
I have never understood the reasoning behind shared DLLs personally. What the hell is wrong with an application running completely independent of other applications? Why must you share a DLL with anyone. Just install it in your own application directory and use it when you need id. Are we still concerned about saving precious storage space on our 80Gb hard drives?
cp -R
This book contains all you need to know about working on Win32, including a pretty comprehensive section on DLLs.
It's all very well in practice, but it will never work in theory.
Forgetting RPM's and apt-get/dselect, what about the /usr/lib dir? Instal 2 different versions of gdk, get something like libgdk.1.so, libgdk.2.so
Unix does the same thing. Granted, unix systems are a more well put together, so that windowmaker doesn't distribute gdk, where Forte Agent probably distributes some pretty standard windows libs.
Both are messy.. but unix does the same thing.
--
"I'm not bright. Big words confuse me. But Wanda loves me and that should be enough for you." - Cosmo
Wasn't that the point of the Registry?
"Would it kill you to put down the toilet seat?" -- Maya Angelou
I bet that if they tested new versions of DLLs, they would not break older apps.
I like this method because it doesn't force me to spend more money on disk space. Disk is cheap, true, but that doesn't justify them forcing ME to buy more of it.
**In other news, Microsoft just purchased controlling interests in all storage manufacturers**
Don't believe anything I say. I crash test crack pipes for a living.
Please disregard all grammer and spelling mistakes. It is before coffee. You know they should swap the submit and preview button so we would preview our stuff first.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Is it just me, or does it seem that slashdot mostly regurgitates BBC News, osnews.com, and The Register? If you just quickly walk through these three sites, it's quite predictable what will turn up on slashdot.
Librarys have version numbers /lib you will see you have several links to various version of a c library e.g. libc.so.6, libc.so.5.
look in
These point to the actual library.
As long as a libraries API doesn't change between major versions (as it should) there is no problem.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
There's some Artificial Intelligence: (from the article): "The system will first look for a local version of the component, and will then look in the cache to find an exact match for the strong name of the required component. Failing that, the system will use heuristics to find the next best component".
If you can read this, thank an english teacher.
Are you kidding me? I've had a hell of a time even getting some programs to install(using the gui RPM manager even); it often won't let you keep old libraries.
You usually have to blow away old versions of gcc or qt to install something that needs a different lib version! "No conflict now, it's just gone!"
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.
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.
...because I haven't had a single DLL conflict since I diched win98 and moved to win2k... I remember this from the bad old days of DirectX 3 vs DirectX 5, and two games I had that installed incompatible dlls, but that must be like 4-5 years ago. Maybe if you're aware of the problem you should be able to go back to old versions, but is that really that often? I really don't feel the need to bog down my machine with several dll copies for no reason.
Kjella
Live today, because you never know what tomorrow brings
Sounds a lot like what Apple did with OS X's Frameworks.
Read more about that here. Be sure to read through the section on Framework Versioning.
Also note that MacOS has long done a great job at packaging applications together so that the installer is unecessary.
This is the single biggest annoyance imho. Why can't they just do it the Mac way? Put everything for one programm in a single directory and that's it. No more problems with installing, just copy the directory from CD to HD or from HD to HD and you're good to go. :-)
Add a small script to register file associations and maybe to add alink to the Startmenue and voila: Instant profit
Seriously, what's the problem with that? Save disk space by reusing components? Please, with 1$==1GB for Desktopsystems that shouldn't be a problem...
Hendrik
MS is suggesting we move from the current situation to one where apps have their own DLLs, indexed by ID?
I'm not sure I'd call that getting rid of DLL hell. Maybe leaving one area in hell to another, but that's another story.
It is getting to the point that I'd rather just have an executable, itself, without worrying about its information in the registry, its DLL IDs, etc.
This doesn't seem to make the Windows internals more accessible, which is really the whole point of the problem.
I instruct people in Linux, and my biggest complaint with RPM is that the user must solve his dependencies himself.
E.g. we had made an installation, but left out the development tools. When you try to install gcc, it says which packages are missing, but not where you can find them. You have to dig them up yourself from the CD-ROM's, and sometimes you have to look on all of them.
I do not have any problems with the RPM system itself, but why has Red Hat still no system implemented like Debian apt ? After the installation it asks for the CD-ROM's, scans them and builds a database about what packages reside where.
So, in the case of gcc, it would say what packages are missing, select them automatically, load the needed packages onto the disk and asking for the appropriate CD-ROM whenever necessary.
This is much more friendly than the stock Red Hat approach. Oh, I know there are tools to do that with Red Hat, but you still have to install them yourself. It should come out of the box.
As if you never had a library version problem under unix!
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!
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
I will use BeOS forever, i've never heard of these DLL things, I don't even know what a file extenstion is. My OS just goes, and quickly.
This has been around for ages in .NET, and doesn't look like anything new to me. The image that comes to mind is of Dr. Evil putting "la-ser" in hand speechmarks.
Ok, if you're going to do this, why not just make it easy on EVERYONE and keep the flippin' installations in their own directories. Keep all the crap out of the /windows and /system directories and make it easier for EVERYONE.
Compile the DLLS with the actual programs like folks stated. That way when I delete the damn program, it deletes ALL the included DLL's, and no one program is dependent on a DLL you may delete out of the windows system directory because a program thinks it's the only one that uses it!
Come on, this is a TRIVIAL problem. Do we really need to reinvent the wheel to fix it?
Another feature of Windows Server 2003 will be that .Net components will have no registration policy. "This means it will be easy to take a .Net component on server and copy to another server," he said. Microsoft is calling the feature xcopy deploy, after a command used in DOS to copy capability files, directories and even whole drives from one destination to another. "It is good for scaling out--it means you can copy applications instead of reinstalling them," said Salmre. "The whole process becomes much simpler."
Microsoft making it easier to "xcopy" an application from one server to the next in spite of obvious invitation for piracy. Could this be the answer to our prayers??! Is Microsoft really coming around?
No...
No, it can't be. Don't trust them, we mustn't trust...
We must NEVER trust Microsoft!
Can't you see?! You fools!!! We've all been tricked!!! It's a trap of the evil empire, I tell you - turn back while you still can!
Look to Linux for your salvation not some Microshaft technobizzle. Don't let them brainwash you - we've heard it all before, "Yup, should be reeaall stable this time.." We must not believe their lies!!!! Don't let them strong bind YOU.
You are receiving this message because your browser supports Slashdot Sigs and you have Slashdot Sigs enabled.
Wasn't COM supposed to deal with some of these issues?
Actually, there are often additional numbers for even more specific versioning.
redhat does provide a tool oob to help with dependencies, its called up2date, you need a dependency, up2date -i apache-devel if you need apache-devel, mind you if apache-devel has dependencies you dont have youll have to get those first too. apt-get for rpm's works really well to solve this problem but its not oob. but you have to give redhat credit, its much more user friendly than the usual linux approcah of make and make install.
Noone writes jokes in base 13!
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?
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.
The Windows architecture is fucked up at the core, and adding new features over it, even though it seems like an improvement, is really just a time saver. If MS wants to make a good Win, they need to rebuild it from the ground up instead of adding clutter after clutter which makes it into even bigger elephantine bloatware.
In my (parent) post I said:
P.S. To the Debian users who cry "apt-get, apt-get!" I use Apt for RPM, and that kicks ass too...
But I still hear:
I do not have any problems with the RPM system itself, but why has Red Hat still no system implemented like Debian apt ?
Go to http://apt.freshrpms.net and download apt for RPM. Works very nicely. Even though it is not supplied by RedHat directly, it works as though it was. Plus all the security/bug updates can be 'apt-get upgrade'-ed, and there are custom packages also that RedHat do not offer, which also work flawlessly in most cases.
------
Random, useless fact: I type in startx entirely with my left hand.
A cleaner solution would be to do things right and make sure that applications don't install random DLLs to start with. If an app needs foo.dll then it should be up to the administrator to install the package providing that library beforehand - or an automated dependency analysis in Windows's package manager could do this. This would also have the happy side effect of making app downloads less bloated.
-- Ed Avis ed@membled.com
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.
C'mon guys - this isn't news - .NET 1.0 already does this. Looks like the tech writer is clueless. (and so is the moderator - ahem).
day 1! Shared libraries always have a form of versioning. Any flavor of using that uses shared
libraries does this. Microsoft is just copying.
somelibrary.so.2 somelibrary.so.3
.NET. Each DLL in .NET that gets put into the GAC has a unique id so you never need to worry about DLL hell. Its just garbage hell.
Its already been done. Heck, Microsoft already does it in
- gtaluvit (prnc. GOT-tuh-LUV-it)
It's funny reading through the different replies to this story-
.
Reply 1- "This is a horrible idea! Look at all the RAM/disk space this is going to use. M$ programmers are idiots!"
Reply 2- "VMS/Apple/*enter slanted fav OS here* already does this! This was a good idea when it was done 10 years ago by ____
Reply 3- An idea like this is so stupid, it will NEVER work right.
So, its a stupid idea that will never work EXCEPT it has already been done BUT will take up too many resources UNLESS it is done by our fav OS AND then thats okay
*grin*
---"What did I say that sounded like 'Tell me about your day?'"---
Indeed most libraries have subversions, but most apps just link to the major version. When an app insists it needs version 6.3.2.4.33 it gets nasty...
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
Mandrake HAS fixed the dependency problem for RPM's.
(URPMI)
still reading?
This means that if you have somelibrary.dll-123 and somelibrary.dll-234, they will end up both getting cached (wasted memory) or only one will get cached at a time. An application that uses the one not cached will have the load the other, even though the two DLLs may be identical save a few minor details. There will certainly be greatly increased disk access and if you thought Windows was a hog on your disk now...
Why bother.
The first time I read through that I thought it said "Strong Badding". Homestarrunner has gone to my head.
they will die in their own creation : the DLL HELL!!
(who said Frankenstein?)
I thought .NET was the supposed to be the end of DLL Hell. Whatever, I just got my PowerMac, so let them rot in in DLL Hell.
"It's like polishing a turd." -FZ
This raises the point, "When is Microsoft going to solve Registry Hell"?
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?
Dont use there software either! (I'm talking to you MacOS guys out there)
This has nothing to do with DLLs, but with .NET components. Read the article carefully! .NET application can bind to a specific version of a component, but that's not even news - it already exists in .NET 1.0 and some aspects of it were already available in COM years ago. .NET components are usually exported from DLLs, but this won't solve any of the problems with 'normal' DLLs.
A
The only aspect of it that has to do with DLLs is that
Someone should teach these computer scientists a little respect for the word "technology". Not every fucking program you write and every database you create is a new "technology"!
This won't effect existing .dlls... this "new" technology is part of the .NET framework. Each assembly (which is just a compiled binary of .Net classes) has a version number and guid. When you compile one assembly that references another assembly, there's information that tells the CLR what versions of the referenced assembly are acceptable. There another thing called the Global Assembly Cache that keeps track of the different versions of each assembly.
.dll hell for existing stuff.
So, anyway, it will only help future programs. We'll still have to suffer from
--
"What do you want me to do? Whack a guy? Off a guy? Whack off a guy? Cause I'm married."
Maybe this should be re-phrased as, "When are we all going to get rid of Microsoft Hell"?
There's this new thing called an "object".
Basically, you can create an object of a particular type anyplace that has access to the definition of that object.
Find a bug in that object? No problem...just update your single definition of that object ( the DLL, loadable library, module, etc ).
If every time I wanted to connect to the database or check an MD5 signature, I had to include that code into my project, that would really suck.
Instead of having 1 version of that code, I would now have as many versions as there are programs using it.
If I found a bug after using it in several places, I would have to recompile perhaps dozens of programs that use the same code.
With DLLs and libs, we can make reference to the object defined in the external library, and just use them from anything that _can_ reference them. I find this is very much my preferred method, and the reason people in general prefer to use external libraries when they can.
Imagine actually having to include all the code from CGI.pm, DBI.pm and DBD::Mysql everytime you wanted to just make a simple call to the database.
Here's an example to show how many modules you would need to copy + paste into even the most simple perl script if not for loadable libraries (you can see what I'm saying here):
Windows--
perl -e "use CGI;use DBI;use DBD::Mysql;use Digest::MD5;print $_. ' => ' . $INC{$_} . chr(10) foreach sort {$a cmp $b} keys %INC"
Other--
perl -e 'use CGI;use DBI;use DBD::Mysql;use Digest::MD5;print $_. " => " . $INC{$_} . chr(10) foreach sort {$a cmp $b} keys %INC'
This is the output I get from running that 1-liner on my windows box: :/perl/lib/Carp.pm .pm .pm /vars.pm
AutoLoader.pm => C:/perl/lib/AutoLoader.pm
CGI.pm => C:/perl/li b/CGI.pm
CGI/Util.pm => C:/perl/lib/CGI/Util.pm
Carp.pm => C
Config.pm => C:/perl/lib/Config.pm
DBD/Mysql. pm => C:/perl/site/lib/DBD/Mysql.pm
DBI.pm => C:/perl/site/lib/DBI
Digest/MD5.pm => C:/perl/site/lib/Digest/MD5.pm
DynaLoader.p m => C:/perl/lib/DynaLoader.pm
Exporter.pm => C:/perl/lib/Exporter
Exporter/Heavy.pm => C:/perl/lib/Exporter/Heavy.pm
constant. pm => C:/perl/lib/constant.pm
overload.pm => C:/perl/lib/overload. pm
strict.pm => C:/perl/lib/strict.pm
vars.pm => C:/perl/lib
warnings.pm => C:/perl/lib/warnings.pm
warnings/registe r.pm => C:/perl/lib/warnings/register.pm
Loadable modules are cool.
How old is HFS+?
I still don't see how this will help when DLLs are overwritten, though.
mbbac
What will this do to WINE and it's dll running capabilities? Would a new version be in order and would it maintain this?
a/s/l here. Sorry, adding domain tags to your s
Indeed most libraries have subversions, but most apps just link to the major version. When an app insists it needs version 6.3.2.4.33 it gets nasty..
Stop spreading FUD. You can access any library you want with LD_PRELOAD. So if libfoo is at 6.3.4 and you have a 6.3.2.4.33 on the system that your app absolutely requires, a simple
will do the trick. In fact, I do this specifically for StarOffice so I can use my local copy of freetype2 with the bytecode hinter turned on instead of the version which comes with StarOffice.
Isn't up2date a tool to just make sure that for some installed software the patches get installed via the Internet ?
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.
..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
This sounds like Microsoft just "invented" things like MesaGL.so.1.2 - We've been doing that for years... or have I missed something?
Keyboard and Microsoft Mouse or compatible pointing device>
Does my middle finger qualify?
Informatus Technologicus
If they did that, wouldn't it become very hard to use GPL'ed software with Windows? GPL itself forbids linking against closed libs, and this would make all applications statically linked.
But then, maybe that is the point...
I remember hearing, reading, and watching demos about this before Visual Studio .NET was released.
.NET that could be considered substance.
.NET.
It was all part of the ".NET revolution", and was hyped for some time. It seemed a nice idea from the marketish resources, as a matter of fact. One of the things about
Of course the new version of Windows will do this, because it includes and is based on
But in case you haven't noticed, the blasted thing has been available for years now.
Am I wrong in thinking this was included from the beginning?
Freedom is the freedom to say 2+2=4, everything else follows...
I don't think there was any 'FUD' in that statement.
If an application _requires_ a certain sub version to work (by that I mean version == x.y.z, not version >= x.y.z), then there's something wrong with either the design of the application, or the design of the library...
Advanced users are users too!
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.
Microsoft said side-by-side DLLs would end DLL Hell. Then it was Windows File Protection... that was really going to end DLL Hell this time. Honest! Then came Fusion. Now it's Strong Binding.
As long as there will be progress in Operating System development, whether with Linux, BSD, Windows, OS X..., whatever, there will be so-called dependency problems, proving once again that programmers are not gods. On the Linux side of the fence, Debian has come the closest to perfection in resolving library and dependency issues. FreeBSD is quite close if not equal. Gentoo Linux also. As far as broken apps go, they are caused more by the desire, or should I say compulsion to have the latest and greatest on the bleeding edge. We are all happy victims of the syndrome.
Just statically link the library and be done with it!
Is this truly the only Earth I can live on?
Nice nick. Maybe we could grab a beer and take turns blaming each other for all the worlds problems.
You think that I'm crazy, you should see this guy!
In fact, I do this specifically for StarOffice so I can use my local copy of freetype2 with the bytecode hinter turned on instead of the version which comes with StarOffice.
Do you live in the USA or Canada? It wasn't clear from your web page because your résumé is 404. If you actually live in the USA, or if Canada has software patents, then go directly to jail, do not pass go, do not collect $300 Canadian, because YOU are breaking Apple's patent on bytecode hinting by using LD_PRELOAD.
(posted without bonus because it's tangential)
Will I retire or break 10K?
sounds very simalir to kernel module versioning ...
Selling software wont make you money, selling a service will.
Yes, Microsoft has implemented a few ideas to help resolve DLL hell. The problem really is not with Microsoft though. The problem lies with lame software vendors. Everyone and their dog tries to write Windows software, and many applications (especially vertical market stuff) is designed very poorly. I hate seeing a client spend $100,000 on a piece of software that looks like it was written by a beginning VB programmer.
Microsoft itself doesn't put out software affected by DLL hell, but other software vendors do.
Case in point: How long as MS told software vendors to check file versions before overwriting files? Or to not overwrite operating system files? Software vendors don't listen, so MS has to implement "system file protection" in Windows 2000. If you look on software development newsgroups, you STILL see posts of lame software developers trying to circumvent this.
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?
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.
The .net FLC also supports classes for creating weak references to objects.
You can resurrect your objects, after they go out of scope if garbage collection hasn't as yet removed them.
But at the same time setting a weak reference to an object allows for the garbage to remove them if another process requires the memory. Comes in handy for objects that are large and non-trivial to create.
advertise here... call us now.
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.
MS already advises software developers to put application-specific DLLs in the application folder. The reason some DLLs need to go in a global location is because they are shared by MULTIPLE APPLICATIONS. Sure, you could put copies of each DLL in each app's folder, but that leads to other problems as pointed out by other messages here. (Wasted disk space, wasted RAM by loading multiple similar DLLs, difficulty in upgrading all those DLLs, etc).
... having the shared objects named as mylib.so.2.3.0 for example? Indeed, isn't this better? Instead of having each installer trying to overwrite every dll in the system, each one copys the one that suits its needs if its not already there o newer. All that not talking about the security issue already posted...
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.
Oh great, I read the artical and it sounded logical but now the conspiracy theorist in me is crying out "A NEW DISCOVERY IS COMING OUT AND THEY DON'T WANT YOU TO KNOW ABOUT IT!". I'd let him out but then I wouldn't be able to make them nifty foil hats.
The only people I have sympathy for are people who pirated XP to run on their PII-266 and people whose hardware is limited to 128 or 256 megs total memory (like a crappy old Sony Vaio desktop I have to setup for a relative).
Such as the class of 2003 at my school. Replace "pirated" with "got a site-licensed upgrade to" and "PII-266" with "school-issued PII-333 laptop". Laptops have slow hard drives designed for low current drain rather than for fast performance, and that doesn't help boot times or hibernate/wake times much.
Will I retire or break 10K?
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.
What's that? When you take a bite out of the Earth?
Maybe I should have put "garbage collect" into quotes. What I meant was that I want the system to remove the files from the disk when their reference count reaches zero. Not literal RAM garbage collection, just an analogy.
Windows dynamically loads code segments out of a Win32 executable as well. It does NOT load the entire thing into RAM.
The name stays the same but it makes use of the date and size to distinguish it or perhaps adds a hash to the name.
Yes I'm joking you clown
The artical doesn't make it very clear, but I think it only applies to applications developed using the .NET framework. So, for all those other applications out there it's dll hell as usual ;)
Am I the only one who remembers how small and efficient code used to be? One of the biggest problems with Window$ is the bloated and incompatible code nightmare we have today (and have for the past several years). XP(letive) doesn't solve these problems, and as long as the programmers have free reign to add bloat to their code it will not get any better.
Have you hugged your penguin today?
From what I've seen, Gentoo already has.
Well, while yes, Portage is a wonderful package manager, it certainly isn't alone in that respect. There's apt for Debian, whatever the BSD's use (I've not used BSD, but portage keeps getting compared to it). If you just want to focus on RPM distros, Mandrake has urpmi, SuSE has their YAST thing.
I really can't speak on RH since I haven't bothered with it since around 6.2 or so, so I don't know if up2date handles deps as well as the others do, but you can use apt on RH these days anyway, so that's a plus.
I think all the RPM hell jokes are getting rather dated these days. There's been solutions out for quite a while now.
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
Does anyone else see this as a pre-registry registry?
Just wondering because I've not heard of it before.
Not really. There are tools for it:
apt,rc,up2date etc. I like rc from Debian:
rc in gcc
and it installs what needed. Sometimes you
add --usubscribed
So this will be just like having libc.so.4 vs libc.so.5.
..
Or just like having MSVBRNT40.DLL MSVBRNT50.DLL MSVBRNT60.DLL (i don't remember the names.. referring to the MS Visual Basic runtime DLL)
It's like DUH... Have the application tell the OS what version of the library it's expecting, then have the OS query the library to find out what works for it./
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
I think it works by 'indexing' the dlls which are required only based on version. call me old-fashioned, but i like to read the article first. ;-)
why run from Vincenzo?
The real solution is to indicate whether a DLL is a bug-fix release or whether it represents a significant and incompatible change to the APIs. You know, like Linux major/minor dynamic library versioning, for example.
In short, I find it very useful and have some experience with it, but find that it fails miserably on anything like an apt-get dist-upgrade, most recently asking to remove the followinf very important packages:
Maybe that's why it's still at 0.39?
Put identity in the browser.
>The fact that Windows stupidly loads the entire .exe is shoddy design from the start..
Well, I'd agree with you - just three problems...
1) It doesn't
2) You don't have a clue what you're talking about
3) VMS a serious OS? - oh, maybe you meant MVS!
Microsoft itself doesn't put out software affected by DLL hell, but other software vendors do.
That is flat out false. Remember when MSVC 6 came out and Adobe Photoshop stopped working because they had made non-backwards compatible changes to the only MFC DLL?
Microsoft is just (if not more) likely to introduce backwards compatibility problems into system DLLs. How is IE (which updates all kinds of system DLLs) any differnt from a user application?
Just because they (meaning the OS group) doesn't mean that they (meaning the applications group) knows what they are doing. They've been making half assed attempts to fix this problem for years -- this is just yet another lame attempt. It's also a good example of "Press Release Engineering" -- they don't have to actually do anything, just mention it in a press release, then people will complain and they'll decide whether to do it or not.
I am not a number! I am a man! And don't you
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
Great. All we need are more DLLs on the hard drive and increase the chances of DLL rot.
DLL rot, for those who may not know what it is, is when Windows, for some reason or another, let's a file rot away on the hard disk causing programs that use that DLL to stop working properly all of the time. Most of the time this can be fixed by copying the affected DLL from the installation and overwriting the current one. I don't see why they don't just enforce reverse compatibility for DLLs or allow a technology like symbolic linking in Linux. That would cure all of the problems.
--If only there was a license required to use a computer.
.DLL's are what makes the Windows platform so easy to code for. What's happening with ".dll hell" is bad installers made by 3rd party apps that fuck things up. In Installshield, it's a single radiobox for "Automatically overwrite files without asking" vs. "Only overwrite older versions of files". The .dll is what makes apps so easy to write in Windows. Need access to the FS? It's there. Need to use IE? It's there. Need to access kernel functions? It's there. It's all there in .dll's already. MS should NOT change their system because of some shitty thrid party vendors. What they should do is have "approved" third party programs, which are ones that DO install correctly.
GPL itself forbids linking against closed libs
Section 3 of the GNU General Public License permits linking against proprietary libraries that were bundled with your compiler:
I'm not a lawyer nor a judge, but I'd think "that component itself" refers to a whole compiler (a "major component[]"), not to a library (which is a component of a component and thus probably not "major"). See also what the GPL FAQ has to say on this issue.
Will I retire or break 10K?
I said once, and I'll say it again . . . there is NO need to go through this. Linux has adapter; you haven't. Observe:
urpmi gcc
Okay, I did have to SPELL gcc correctly, but other than that it was pretty painless.
Not looking forward to making this same post next week . . . but, everything at slashdot seems to be repeated.
Sdelat' Ameriku velikoy Snova!
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.
When dealing with packages installed on the Red Hat CDs, often it works just as well to use the "redhat-config-packages" tool which will automatically figure out both dependancy problems and will tell you which of the Red Hat CDs to insert to get a package installed.
It's not a perfect solution, particularly for 3rd party packages distributed online. But if someone builds an RPM will a million obscure requirements, I'll either try compiling from source or ignoring the software entirely.
Ita erat quando hic adveni.
Unix has had library versioning from the very beginning. Shared library filenames specify what version of the shared library the file contains, and when programs load they can request a specific version thru the file name.
And here comes M$ taking the same idea, and adding a point of failure in the form of some binary index of dlls. Jeezz this is just another thing I'm gonna have to fix when my windows friends start having trouble with thier computer. Really unnecessary. Couldn't they have just outright copied the Unix method? At least then they would have done it right.
Wouldn't it be a lot easier for Microsoft to teach their people to design things before coding them, so that they don't wind up releasing incompatible updates all the time? IBM came up with this kewl new thing called backward-compatibility -- maybe Microsoft should ask them about it?
Dynamic libraries had the version number in the filename, and the OS was smart enough to be able to load a slightly newer but still API-compatible (minor version) of the library.
Come to think of it, Unix doesn't have this problem, either.
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.
This is what .net is all about, this has been IN PRACTICE since .net was released (about a year ago). All this article does is describe what is already in place as something new for Windows Server 2003.
One of the best ideas I've heard from MS in a long time.
Comment removed based on user account deletion
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
Maybe they need something like VMS's file versioning. If done right, they could keep the directory clutter down, while maintaining multiple versions. To an extent, the multiple DLL's could appear as one file.
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...
Mandrake has an excellent tool for handling rpm dependencies called urpmi (Universal RPM Insatller). I guess RedHat has their reasons for rpm being how it is, but remember, there's all sorts of package managers out there. That's why I like gentoo. emerge appname.. it doesnloads and compiles the source and all dependancies for you, optimized for you architecture.
Everyone is entitled to their own opinion. It's just that yours is stupid.
This solution is bad...
One, the system has no way to tell a non-ABI breaking dll change from an ABI-breaking one, so it always duplicates and wastes space. This is really bad, clutter is worsened.
Adding to that, how do security fixes work? Typically they replace the library with a new, ABI compatible fixed dll. Now the insecure one will be archived? I presume there will be some mechanism for actually replacing a dll at install time, but will that be available to third parties? Would MS get control over security updates?
Unix has it right, keep a symlink with the generic name for compile-time *only*, and maintain the actual libraries for runtime with the version numbers as the filenames. This way, a library installer has an intelligent recourse as to specifying what kind of update it is, ABI compatible or not.
XML is like violence. If it doesn't solve the problem, use more.
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!
This is just another flavour of side by side installation that MS has been promoting since Win 2000. In this case they are talking exclusively about .NET assemblies which side by side installations have always been a feature. With Win 2000 developers have had the option of protecting there applications from their application being broken by later installs of other application or server packs. While this can lead to some redundancy it is a trade off with your app not working. While dll hell will never totally go away the current state of MS development for Win 2000 is way ahead of what we had to deal with in NT 4 and 95.
All systems have problems with how to implement them in a predicatable and sensible way. I have had many issues with updating libs on my Linux install to the point of making many apps unusable. Yes I know I suck as a Linux admin, but then again that is not what I do. I know my weaknesses unlike most of the 4+ posters to this MS bashfest.
Nothing new here just a opportunity for people who know nothing about development or are just crappy MS developers given an opportunity to display their ignorance.
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
I figured they would just rename DLL's, like they did with the GPF problem
I think this would work better if it were more granular than simply versioning the DLL. Perhaps when DLLs are initially loaded on a system it could diff the individual functions to find differences, and then provide these individual functions to programs which use different versions from those already installed.
scott
Now it will be even more convoluted. Windows is becoming more and more like out tax system (with holes) while Linux makes progress on "dependency hell" with systems like Gentoo ports and Debian's apt-get.
To be fair, I can see that some such mechanism as this could be of use as part of a long-term program to clean up the API hell. However, I'm not convinced that the same result could not be better achieved by consciously deciding to build up a parallel set of APIs (Trusted-Win32, perhaps?) where professional design and implementation practices are enforced. It's not as though it's difficult to understand: disciplined design and implementation of APIs with upward compatibility taken for granted have been standard practice for decades in non-Windows enterprise environments (mainframe, VMS, more recently Unix, etc.)
Finally Microsoft have started to figure out how to use cut`n`paste, so they could copy the method used in everybodys favorite os. The /lib/ dir have as far as shared objects go always used an unique id for its libraries, this is called a version number. and usually build up the name of the library, like my-incrediblelib.so.9.2.1
Let me explain this because many people seem not to understand.
.NET way of doing things is different though, and Microsoft won't logo or certify apps unless they follow these practices:
When a program installs a "shared" DLL, the assembly manager looks at the DLL version. One of three things will happen:
1. The DLL does not exist in the assembly cache - it is added.
2. The DLL exists, but all other instances of it are a different major/minor revision. (X.Y.0.0) In this case, the DLL is added to the assembly cache as a separate version.
3. The DLL exists in the cache, and the major/minor versions are the same. In this case, if the installing DLL has a newer revision (0.0.X.Y), then it will overwrite the old DLL. Otherwise, it is thrown away.
When a program executes, it's manifest specifys what major/minor version of the DLL it needs, and the assembly cache will fetch it. HOWEVER, bug fixes, etc are supposed to be changes to the revision numbers only, so if a bug fixed version of the DLL is installed, the app will use that version.
The assembly cache also keeps track of what set of DLLs go together. If version 1.2.7.X of FOO.DLL needs to also be run with 1.2.7.X of BAR.DLL, then the assembly cache can make sure a program never uses a mismatch, which has been a
MAJOR cause of difficult to track instability over the years.
The "new"
1. If you have a DLL only used by your application, install it in your application's folder.
2. If you have a suite or many apps that work together and use the same DLL, install it into program files\common\yourname.
3. ONLY install DLLs into the System folder if they are very very widely used, or are actual system objects or libraries. (I.E. your app needs a newer version of the microsoft common dialog runtime. In that case, you ship the MSM which has the latest version of common dialog and related libs that are all known to work together, for EACH version of windows. The Windows Installer knows how to read the MSM and pick the appropriate set of files for the current OS/service pack level you are on. That way, developers running Windows 2000 don't b0rk a Win9x user by shipping the w2k libraries.)
3a. An even easier way of handling things is to write your app for a specific service pack level on each OS (or possibly hotfix if a bug was fixed that is affecting your app.) In this way, you just tell your users "you need service pack X on OS Y, or service pack Z on OS A" to run the app.
Natural != (nontoxic || beneficial)
This sounds very errily similar to the library database within AIX... it does version tracking, etc... god I hope MS isn't going to try to patent this.. they'll loose....
Or am I missing something?
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.
Two questions. First, why do Slashdot users insist on writing novel length responses, full of technical detail, about subjects that are purely speculative? There are scores of posts explaining in detail why this will not work but yet the original article doesn't even go into how the system itself works. How can you debunk something from a technical standpoint without knowing, even vaguely, how it works? The second question; why do I read them and add fuel to the fire by responding?
Well, Microsoft does one thing better than any other company. It can take a bad idea and make it even worse than it was before.
It has a lot of things. The first is, as another poster pointed out, what's called soname or libtool versioning. That is, you append the major version number, which represents a specific ABI (not to be confused with API) to the end of the filename, and then apps link against that name , for instance, libfoo.so.2
The actual file on disk is more likely called libfoo.so.2.0.22 - as long as they have the same major version number, they are compatable (in theory). GTK for instance preserves ABI compatability between all 2.x versions, so if you have an app written for GTK 2.0, you can install GTK 2.4 and all the apps will still work.
For some libraries, they are very big and it doesn't make sense to install a totally new copy of the library when perhaps the only thing that's changed is one function. Then we use something called symbol versioning, which is like lib versioning except the actual symbols are renamed. glibc uses this, as do a few other things. In future Wine may do this as well. Symvers are somewhat complex and can't always be applied though. In particular they aren't portable.
Finally, both the developer and user can control the process. Developers can bind to a specific sub-version of a library, if they so wish, although that's rarely used. Developers can also link relative to the binary itself, so you can ship private versions of a library if you don't want to statically link. Users can control the process by setting environment variables.
Having said that, although using these mechanisms Linux avoids "DLL Hell", it has other forms of hell. If you don't use a distro with a large library of prepackaged software (ie anything other than debian or gentoo basically), resolving dependancies is hard.
Sometimes, you encounter "Symbol Fixup Hell", which is one most people aren't aware of, as it's mostly masked by the fact that people prepare binaries for individual distros (and therefore individual sets of libraries). It tends to bite the people packaging stuff for a distro, rather than users. That's when you have 2 versions of the same library mapped into a process at once (ie, libpng) at different points in the link tree. The linker mixes up the symbols and the app segfaults. The glibc team are aware of this, but the fix is complex and they are busy with other stuff :( Hopefully it'll be fixed soon.
It's horribly slow today, do something!
no big deal to solve problems quickly with the sourcecode available
Really... I can't recall falling victim to "DLL Hell" in years... since the install of Windows 2000 I can't recall actually being affected by this problem. So it *is* a problem on 95/98/ME/NT but it's not on 2000 or XP, so why does it need to be "fixed mo' bettah'" for a future version?
I do have to say that after going through years of DLL Hell, .Net has really fixed things up.
.Net development environment works a LOT better than it used to. You don't get permission denied every time you want to compile your DLLs so badly that you have to shut down all of VStudio just to get anything to work. And to refresh all of your references to their latest version... just click refresh! (What a concept)
- You can finally overwrite DLLs, even if they are locked by IIS or anything else, primarily because of the Global Assembly Cache (GAC). Basically it caches the DLL in memory, so any processes currently using a DLL keep using the old version until the references are destroyed and any new processes are given the new version. Now granted you still have the problem of version compatibility, but I see that as more a responsibility of the developer to adhere to a good internal process for versioning.
- As far as projects go (EXE or Web Projects) the
For what they are talking about with versioning and separate lists of file versions, etc. etc... I just hear "Marketing marketing marketing blah blah blah."
You want to talk about versioning and storing lists of DLLs and handing applications the correct versions of things... check out: HKEY_CLASSES_ROOT
Now check out HKEY_CLASSES_ROOT\CLSID or HKEY_CLASSES_ROOT\TypeLib
Spend a few hours and try to figure out exactly how a COM application request figures out which binary file to instantiate. Now throw something like Transaction server in the mix and look again.
I've gotten my hands dirty enough in the registry, and I'd rather it didn't get a lot messier in there.
Can you imagine the tech support for this? Good lord...
Solution: STATIC LINK you nits! If that doesn't work, use a VERSIONED FILNAME. And lastly, your install should NEVER put something into the system folder(s).
There was a simple reason they created SHARED libraries, to save on hard drive space. That isn't a problem any more.
Why break an old program because you over-wrote a 116k file in the \windows\system folder. Just keep all of the applicable dll's in the programs own folder. Then, nothing else breaks. When you upgrade your OS, it could search for and update each programs dll's, and put a little exe in each directory that restores the old ones if the program stopped working...
Shared DLL's blow.
"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 'really large hard drives'."
Query of the unix gurus: how does the library versioning handle an upgraded "DLL" (don't know the unix term) that you want older apps to use? Such as perhaps a new arithmetic library that takes advantage of new FP hardware?
In Linux, .so libraries have numbers attached to the filename, such as "libz.so.1.1.4". The first number is the important one; ABI-incompatible changes to the library cause that number to increment. The other two numbers are for the library maintainer, and are optional.
The dynamic linker maintains symlinks with just the major number: "libz.so.1". Dynamic apps contain references to this. So, if you added MMX support to your zlib for faster compression, you might install it as "libz.so.1.1.5" or "libz.so.1.2.0". When you run "ldconfig", the dynamic linker updates its symlink for "libz.so.1", and apps you run past that point get the MMX zlib.
Were you to change the ABI in an incompatible way, you'd up the major number to give something like "libz.so.2.0.0". This would cause ldconfig to create a symlink to "libz.so.2". Apps linked against the older version still link to the older version; newer apps link to the newer version.
It's even possible to override ldconfig's symlinks and downgrade your system. You need to keep older versions of libraries around, but that's allowed under this system if you use the minor version numbers.
As I understand it, just about all Unix and Unix-clones have something like this, although the specifics are different for each.
Microsoft re-invents static linking.
Let's hope that they don't decide to patent the concept of a statically-linked executable file. Lord knows the US Patent Office will hand them the patent on a silver platter, completely oblivious to a preponderance of prior art.
Look out for the next DRM-enabled version of xcopy.
How nice it is to live in the future.
OS X bundles even allow for multiple architectures (although no one can put it to use yet).
Wow, I haven't touched Windows in years. LOL.
My Vic 20 had cartridges that you could just plug in when you wanted to use them.
Worked Great!
There are many days when I wish for that again.
Have you not heard that this is a better way of distributing applications?
I mean, why bother to make sure that you write the "shared" library correctly since you can distribute it whenever you want. Code, compile and distribute, oh yeah I forgot, to test... No problem I can send out that DLL again. Ooops security leak, no problem I can send out that DLL again...
You see with static libs, oops DLL's, you save bandwidth because static apps require full compile and larger distribution foot prints..... And we all want to do our part on saving bandwidth....
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
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.
"Microsoft is attempting to do away with DLL version conflicts"
Imagine Bill Gates in a black mask and with a much cooler voice:
"There is no conflict".
graspee
Microsoft kills Neowin.net. Didn't we see this before? No, wait, it was the US government. But, really, what's the difference?
Beware: In C++, your friends can see your privates!
No app that I know of links to the specific shared library (libpng.so.1.0.89, in your example) unless they do it explicitly with dlopen() and friends.
The problem here is that Microsoft doesn't provide a facility for identifying ABI versions (that would be the libpng.so.1 example in your post), and they aren't disciplined in preventing ABI changes. No amount of cruel hacks will alleviate the need for this.
I guess Slashdot needs to change their tagline to: Discussion for Nerds.
FORMAT C:
In all the replies, I don't see even one that says, "Why did Microsoft allow this problem in the beginning?"
When there is a news story that says, "Abuser says it will stop abuse." People debate how wonderful it is rather than show skepticism or ask why they were abused.
It would be better if we had more efficient social mechanisms for recognizing and stopping abuse.
How is this any different than the CLSID which already exists?
Skiers and Riders -- http://www.snowjournal.com
The thicker and gummier the layers of paint, the easier they are to strip off with a heat gun.
Keep your packets off my GNU/Girlfriend!
msgbox('Please install new 40gb harddrive for DLL storage and click continue')
-- Insert wisdom here:
Unix had journaling years before any Windows system did.
why doesnt Macrosuck just steal the idea of crating a folder called EXTENSIONS and let users delete or make inactive what they want?
And I was wondering what to do with all that free disk space. I was leaning towards using it to store digital pictures of my family, but 300 versions of the same DLL seams a much better use. And keeping track of these will be easy because the Registry is so easy to understand anyway.
Since you can already (under NTFS) have multiple "streams" in a file, why not have a generic name for the DLL as the main file, which points to the latest version (for the I don't care users), and then store the different versions as separate file streams. You can mimic this with yet more "special" folders under FAT. Then you can, since NT derivatives can have disk compression, store just the differences between the versions in the streams (requires a bit of a change to the NTFS but not much, and all the APIs are already in place). This maintains a low on disk foot print. And, if the loader where exceptionally clever and the DLL mechanism and format (obviously for future DLLs) for building and linkage were slightly modified, you could cause the loader to map the common readonly segments across all the versions to one space in memory. Very compact and virtually no additional overhead if done correctly. Less space in memory and less space on disk. One of the alternative means would be to actually use the NTFS versioning features (present in the meta-format data but not currently used) for the on disk structure, although that is tougher to mimic on non-NTFS volumes. Best solution though would be to _dump_ FAT now that the "consumer" OS is based on NT. BTW Microsoft, much as I like the Mac platform, feel free to contact me for research or OS dev positions!
Of course, then you'd want to make a few changes to support multiple stream files better in the GUI and some other utilities. The command line already does of course, although you might add some flags to some commands to expose the multiple streams rather than require explicit filenames that identify them. "DIR" would be a good start, so it could display the multiple streams by default, or optionally. The file tree display is another venue for change, and a few more. "CMD" already recognizes them when you specify them, so you can invoke most commands with a particular stream of a multistream file. Then its just a simple matter of doing a bit of compression/versioning and voila, a much saner approach.
- Tjp
I am in wallow with my inner money grubbing capitalistic pig. ... Oink!
If you need the functionality that Sendmail provides, there are alternatives out there.
'nuff said!
It's been in .NET for years now. It's called a Global Assembly Cache, and if you know anything about it, not all dll's are put into the GAC, only those that are 1) Strong Named (with a signature) 2) Need to be accessed globally (eg, system dll's).
.NET support this, and versioning can be put into the PE manifest, an external manifest, or managed by the GAC.
All PE's in
All hail Bill Gates, chairman of Strongbindia. Check out his majesty! I wonder if the next version of windows will come with a dragon named Trogdor.
Can anybody here spell M-u-l-t-i-c-s? Microsoft *still* hasn't re-invented the wheel -- their version is all corners.
I smell a Strong Binding patent approaching...
I believe that the whole dll hell has been caused by poor software quality. The idea of using dll's or share libraries to make the applications and systems more modular is a very sound idea. Dll's and share libraries should be independently upgradable. However, to make it working, the API's have to be very clean, consistent and well designed. The shared components have to be very stable. The shared dll's in windows are part of the platform. If the platform is not stable (got changed rapidly), it will be like putting up buildings on float sand. Of course, it will be hell.
It is very awkward when two MFC42.dll's shared the same file name and in fact they are two different versions. Different versions of a dll should be made more explicit, such as using minor release number as in the Unix world. In Unix, we manage by looking at the file name of the shared objects. In Windows, a lot of time we resort to look at the date a dll is created and its size.
Application developers have no choice but to install some of the dlls that they get from Microsoft since these components don't get installed with the operating system. When installer of an app installs a newer version of a dll and breaks some other apps, most of the time, it means the API and the exposed behavior of the dll has been changed.
The changes may be desirable and intended to be there to fix a previous bug or a previously misintepretation of the interface. However, for the shared component scheme to work, API and behavior of the components have to be stable. If there are changes in API and behavior, we may have to change the major revision number of the component, and in Windows, to use a different file name.
The changes may also be a newly introduced bug in the shared component. If a component is shared by a lot of apps, I would expect the provider to be very careful when making bug fixes and changes.
Sometimes, the fault may lie in the app developers. They may have misintepreted the API, or there are bugs in their apps, which depend on some bugs or undocumented behavior of the shared component for the app to work properly.
To solve the dll problems, we can do:
(1) have a clean and consistent set of APIs.
(2) provide high quality shared components so as to minimize changes between major upgrades. When bug fixes are needed, they should be done very carefully.
(3) provide an easy way to specific a particular version of DLL to load for a given app in the rare occasions when conflicts come up. Done in Unix by specifying search path for the shared objects.
(1) and (2) are fundamental but hard to do. If they are not done, I don't think we can fix the problem. To do (3) when most home users don't have the knowledge to manage the dlls, we have to provide a tool and build some intelligence in the OS to help the users and ttack all the dll dependency.
The solution mentioned in the article will not fix the problem. It may alleviate the problem somewhat by backing away from the concept of using shared components.
quote: "I would think this might add to DLL clutter however."
Please, if you are going to coin a phrase could you come up with one as catchy as DLL Hell? "DLL clutter" just does'nt have as good a hook.
Also, if your argument is that somehow archiving several versions of DLLs will lead to a shortage of storage space or further operator confusion over versioning; *whispers* ever try and draw a dependency tree for the average developers linux box?
_____________________________
It is easier to stay out than get out - Mark Twain
-- "It was as if the paint factories had decided to deal direct with the art galleries." - Thursday Next
Look for this in Linux 5 years from now. Leave it to Microsoft to introduce the idea of unique ID's in libraries and Linux to copy it.
1. Horribly inefficent way of implementing a "good idea."
2. OTHER OS/etc. already solves this problem another way (10 years ago?)
3. Probably will lead to more problems in this manner.
This problem is solved with what are known as "strongly typed assemblies" (MS doesn't use that term). A Strongly named assembly consists of four attributes that uniquely identify the assembly: a file name (no extension), a version number, a culture identity and a public key token There could be a 100 MyTypes.dll on the same machine..but using public and private key technology instead of guids, etc, also allows the checking of the integrity of the assembly's bits as they are installed on the hard drive. So any company that wants to mark its assemblies as unique must acquire a public/private key pair, and its this distinction that allows two companies to create assemblies that have the same name, version, and culture without conflict. These word's are Richter's, not mine :)
Solid!
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 seems like the best approach would be to have a app that you can drag anywhere to install, that the first time it is run sees if system common libraries are there and if not installs them.
Basically an install run by the app the first time it's run, or anytime the libaries vanish (like after a system reinstall).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Is this in any way related to Strong Bad?
"Everybody To The Limit!!"
DLL Hell is a great illustration of Microsoft's general approach to a whole lot of things. The original idea of DLLs was great if you can trust that everyone who modifies a DLL will maintain backward compatibility. In real life that won't happen. Strong Binding is a workaround for shortsighted thinking.
... which is pretty much how Microsoft deals with the rest of the world.
The mentality that everything would be ok if only everyone else would just do everything the same way you do only works if you can force everybody to follow your way
Workarounds in applications that break when the library gets fixed are in themselves broken. The correct thing for an application developer to do is to test for the presence of the bug and then pick either the workaround or the version corresponding to the published API and behavior. Then, the application doesn't break when the fix gets released.
What Microsoft is doing is the right way to do it.
No, it's wrong. You merely have the blind leading the blind.
Ideally, upon upgrade of a DLL, there should be a way for the application to contact the mother ship (i.e. the home page of the developer) and ask for approval to upgrade to the new DLL.
And the fact that you consider this "ideal" is typical of why Windows is such an awful platform.
The "ideal" is that if applications have workarounds for library bugs, that they apply those workaround quietly and correctly only when needed. And it's an ideal that's easy to achieve for anybody who has the slightest idea of what they are doing.
When was it? Oh yeah. In the Windows 95 docs. And again in Windows 98. I don't think ME mentioned it, but XP certainly did.
Another Slashdot "plum". Posting stories that are months old (shame on zdnet for treating this as a new subject.) This is simply the new "Assemblies" technology introduced with the .NET framework. Unfortunately, I've had the "pleasure" of working with it lately. I don't know what Miguel D'Icaza is so fired up about ... It's java with a M$ twist. Anyways, anyone who thinks this is an end-all-be-all solution to DLL hell is wrong. I've recently gone through 3 hours of chasing my tail while trying to deploy some code that was dependant on a DLL in the Global Assembly Cache (one I wrote.) More a VS.NET issue than a .NET framework one, I had changed some lines in the AssemblyInfo.cs source (which controls the metadata for the assembly such as title, copyright, version, etc.) and low and behold my code couldn't find it. Don't want to digress here, but want to say that no, this isn't the promised land ... just another road apple with whipped cream on it (to use McNealy's analogy).
Pimpin' all the Karma Hoes!
Microsoft claimed no DLL Hell on Windows XP before. This MSDN TechNet article says it's rock solid and no problems with DLL...
The alleged memo on why Sun doesn't use Java internally was largely about applications breaking when the Java environment was upgraded. Once again, problems resulting from using dynamic binding instead of static binding at application build time.
See What Perl, Python, and Java need to learn from C for more details.
Dynamically Linked Libraries are good, because it allows for sharing common code, saving on memory and speed resources and with all the other advantages /. posters have already mentioned(so I will not analyse here).
/windows/drivers, /windows/dlls, /windows/help etc.
The problem lies with the generic file hierachy: most DLLs reside in the 'system' or 'system32' directory; these DLLs exist alongside a multitude of bitmaps, text files, help files, driver files, system fonts, executables and God knows what other. This is also true for the winnt/windows directory. In a few words, it is a mess.
A good solution would be to:
1) provide hard links to DLLs from the directories of the applications that installed them; moving the application directory would not affect the DLL; deleting the application directory would delete the file and the hard link, too. I don't know, but does the NTFS filesystem provide hard links ? I think it does not.
2) add one more attribute to each file: the file version. If I can recall correctly, the Vax filesystem tagged each file with major and minor versions so as that files could have the same name in the same directory as long as their version was different. That would really solve the DLL problem, since an application no longer would request linking with the DLL by name but by version also.
3) provide separate directories for each class of files:
It is this type of problems that always make me negative towards Windows. Although it is clear that there is a group of much-talented developers behind it, how come they did not think of such a simple solution (versioning) ? Vax predates Windows by quite a few years, yet in some ways it was more sophisticated than NT.
Dynamically Linked Libraries are good, because it allows for sharing common code, saving on memory and speed resources and with all the other advantages /. posters have already mentioned(so I will not analyse here).
/windows/drivers, /windows/dlls, /windows/help etc.
The problem lies with the generic file hierachy: most DLLs reside in the 'system' or 'system32' directory; these DLLs exist alongside a multitude of bitmaps, text files, help files, driver files, system fonts, executables and God knows what other. This is also true for the winnt/windows directory. In a few words, it is a mess.
A good solution would be to:
1) provide hard links to DLLs from the directories of the applications that installed them; moving the application directory would not affect the DLL; deleting the application directory would delete the file and the hard link, too. I don't know, but does the NTFS filesystem provide hard links ? I think it does not.
2) add one more attribute to each file: the file version. If I can recall correctly, the Vax filesystem tagged each file with major and minor versions so as that files could have the same name in the same directory as long as their version was different. That would really solve the DLL problem, since an application no longer would request linking with the DLL by name but by version also.
3) provide separate directories for each class of files:
It is this type of problems that always make me negative towards Windows. Although it is clear that there is a group of much-talented developers behind it, how come they did not think that such a simple solution (versioning) would solve a big problem ? Vax predates Windows by quite a few years, yet in some ways it was more sophisticated than NT.
They couldn't call them .ass, right?
This is a big argument to start using cross platform, or at least VM style languages like Perl and Java.
Java has one library, and it's standard and open. You install it once and don't have to worry about all this. Backwards compatability is getting better and better with each version.
Script languages take up less harddrives space, and can be compiled at run time.
Low level languages have their advantages, but they are dwindling down to speed.
and about time. Will there never be inodes in windows?
I could be (probably am) wrong, but I was under the impression that DLLs were the Windows-equivalent of Linux libraries. That is, you can have multiple programs link to the DLLs/Libraries at compile/link/run-time thus saving hard disk space and resulting in smaller code. But, if each program has its own DLL, wouldn't it just be better to hard-code the DLL functions into the program. I am speaking on something I don't know much about, so if someone could steer me straight...
How many slashes would a slashdot dot, if a slashdot could dot slashes?
Depends.exe shows you graphically what the dependencies are and what those dependencies depend on, and so on. It also shows you neat stuff like exported functions and their byte offsets, and if the dependencies exist or not.
I'm not sure if depends.exe comes with Windows or not though. I know it comes with Visual C++. But my dumpbin.exe is in the Visual C++ directory too, so maybe users don't have either of them.
No.
How do those standalone libraries get there? That's what my idea is addressing, installing these system-wide libraries without need to ever have an application "installer".
Actually, you can genericise my thinking along these lines - given an application "X" that has an installer that performs a set of tasks "Y" (of which there are many examples), you can just make an app bundle for X that the user can copy anywhere that does "Y" the first time it runs.
Thus, you would never need to run an installer again...
What's wrong with that plan? Seems nice to me to make all apps consistent and get rid of "installers".
"There is more worth loving than we have strength to love." - Brian Jay Stanley
$echo file.sample
$cat shit
shit
$cat shit > file.sample
$cat file.sample
shit
$cat poop > file.sample
$cat file.sample
poop
Hmmm, uh oh... perhaps the simplest form of concatenation would help with DLL overwrite from different sources. Then again... what about duplicate classes that merely add attributes and/or members? Well, that is when an internal checking method should be in place that indeed just adds but does not simply replace the older class with the newer one. It internally concatenates the added portion.
There could however be a method to completely overwrite but instead of a simple replacement there could be (through a priority or any other rules based system) a method to selectively choose which portions must be overwritten or simply deleted wholesale. This would allow for example a class that has been "upgraded" to keep its upgrades internally but those portions that must be deleted or changed can be taken out.
However, the real issue is that it is stupid to ever allow an "upgrade" that is not explicitly set aside and labled as an upgrade. Internally there should be a "default" pointer to the most recent version. This allows DLL's to be upgraded in a transparent manner but still allows a program that explicitly requests a particular version to do so. I don't get what all the fuss is about. The real issue IMHO is a lack of professionalism and self restraint shown by many developers. You just do not rush in like so much male bovines into a China store and screw everything up because you have thought of a better way to do it. Perhaps a more polymorphic method of object linking should be pursued thus giving the benefit of relinking code (thus giving the benefit of a good abstraction minus the actual run time BS of lookups, translations, calls, etc) when the new version is installed while not requiring so many layers as to turn even the fastest machine into an expensive door stop.
Everyone already uses libraries versioning that perfectly fits into existing filesystem and linking procedures, and only mental giants at Microsoft can't use such a simple solution and have to create an additional layer of hideous mess to accomplish the same thing.
Bravo!
Contrary to the popular belief, there indeed is no God.
nt
If you wanna get rich, you know that payback is a bitch
If it doesn't include DepTricketyTrackTronTronixTronTron 12000, I don't want to know about it.
/ 20 01-March/000381.html
http://lists.siena.linux.it/pipermail/slug-tech
Cheers
Stor
"Yeah well there's a lot of stuff that should be, but isn't"
Boy, that would be nice. Nearly every program I know of is linked to serveral dlls and writes half a dozen registry entries. Including the actual files, that's three things to keep track of. Not fun when you need a program working now.
I wonder where this Global Assembly Cache will be stored, if not the registry. I hope it isn't, the registry is bloated enough as it is.
If I want to build something for personal use that someone has a patent on... there isn't a problem with that.
From USA patent law, 35 USC 271 (my emphasis):
If you think USA patent law contains a a broad exemption for private home use of a patented invention, please show me where it is "otherwise provided in" Title 35, United States Code.
Will I retire or break 10K?
Second, It is my understanding that patents do not apply to personal, non-distribution use, in the US or abroad.
Not so to my knowledge. The letter of USA patent law is "makes, uses, offers to sell, or sells". Details in this comment (which I'm linking here to get on your Slashdot Message Center radar).
Will I retire or break 10K?
If they put the version number of the library into the filename, they wouldn't have these problems. Multiple versions of libraries could *easily* coexist.
Either that, or they could just fucking statically link the binaries.
Jesus Christ.
It's ok. Microsoft promised the same thing between Windows 3.1 and 95 :)
This will allow for several functional differences for the user, under the single premise of "making things easier for lazy developers who shouldn't be allowed to work on computers in the first place":
1) it'll make programs bloat up even more, providing more hardware-based computer purchases when people start experiencing more and more bloat as new versions of their software packages are released, and more and more versions of various DLLs are added into the fray.
2) it will likely make older windows-based programs have a hard time figuring out what DLL is required, and as a result, will cause instability. This, in turn, will 'require' the latest version of the product, which is "Microsoft-certified" and provides a -whole- yaer's worth of free software updates (after that, they're 5$/month (whatevre)
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
The present DLL system can handle this sort of thing, they just failed to use it properly - as did all the vendors who use DLLs. Versioning information is available on each DLL already, and utilizing the versioning information would be a matter of a few more light calls. Further logistics could have been a folder with the name of the DLL, and names of files within being the versions.
Microsoft did not standardize this well.
If I told you I had a car every day, and I told you I was going to drive it in a few years, would you get excited? I certainly hope not.
I don't think there was any 'FUD' in that statement.
The FUD was that Linux (well any OS utilizing ELF-based libraries) has the same DLL hell as Windows.
I completely agree that requiring a specific version of a lib and not any further releases is a design flaw in the application (or perhaps just not a maintained one, if the library API has changed), but that is a far far cry from DLL hell.
Like any system such noble efforts it is necessary to give the architect of the implementation (the programmer in this case) the ability to build it in the way they see fit. MS is already famous for reducing choice and dictating terms to the end user... why would I want such methods restricting my ability to design programs?
In fact, what I took from it was that the obvious and very well known problems (scalability, extensibility, reuse, etc) of using a fine tuner like assembly must be weighed against the more long term-friendly architecture of using higher level languages with dynamic libraries.
Geez, that didn't offend me one bit... but then again I didn't become a hypocrite and put on my MS fanboy hat and type this. You extremists should all be sterilized. The fanboy mentality is the sign of never learning to control your id... in other words you are an arrogant, hypocritical asshole who has no clue how ironic his statements are that even remotely hint of being "anti-MS" as you are so obviously "pro-MS". Fucking monkeys... I wish the zoo would quit teaching you shit eaters to type.
If more programmers would show a little long term thinking ability then this problem would not manifest as much.
Instead of simply relying on an error (or exception if you use something with those) to tell you what is wrong then perhaps your component should include multiple failure and success states and perhaps also different levels/priorities.
On a higher level, this reminds me of how often Windows based programs will spam you with some useless garbage about there existing an error... yet it does nothing to actually give you a hint as to the what or why. Then those who try to automate some task will simply say unto themselves "Hmmm, self... I think we will make an ASSumption that if it fails to work perfectly then obviously it is because of this particular reason."
"Yes doctor I do have a fever... Oh, you say that is positive indication of kidney failure and it must be removed immediately? No prob, doc!"
Too much pointing fingers... too many stupid programmers pointing exclusively at the OS or third party apps and too many stupid OS and third party app programmers pointing fingers at everyone but them. The best architecture means nothing if it is mangled by poor practices. However, a lack of clean architecture can at least be made into something good by good programmers (which btw, includes those programmers interoperating)
OK, it would seem that the time limit is not the case... what is relevent is the actual operations I run at about that time index. Namely, turning on the environmental controls, radio, windshield wipers, turning on the lights or putting it into gear. Gas or break pedel while in Park does not appear to affect operation.
Hmmm, after further testing I have disovered that if my radio, environmental and lights are removed then the problem does not manifest. I suppose I can tough it out without AC or heater and radio, but lights are a must... who designed this thing anyway?
Interesting. I have discovered that there is a device under my hood that converts the fuel into another similar but yet incompatable with standard fuel mixture. This device seems to have been added when I took the car into the dealership for the recall maintenance last month. I wonder why the "solution" both changes the nature of the fuel to the point that you require additional devices to use it as well as changing the external connection points, shapes, sizes and flow regulation for both the fuel and the electrical components. Seems this fix was very much an unprofessional hack done by someone with no mind for engineering.
What in the... after removing the "added component" for fuel I have discovered that the dependancy relationships between the various parts of my car have an odd "worst of both worlds" mixture of fuel inefficient and slow translations/conversions (with a mechanical system of "looking up" the location of various parts) along with a very hard coded method that seems directly to link to very specific implementations of the component lookup system. I have heard mutterings of "abstraction" as the reasoning for this. Seems they do not understand the meaning of that term in either a systems context or even in the specific part's own context... much less that they appear to have confused "abstraction" with "ambiguous." Again, I wonder if this was system, the vehicle or the latest process of the fix (and the fix itself) was designed by engineers... or just monkeys with degrees and a ready list of buzz phrases. It would seem that this bureaucratic mentality is actual disease and my own problems merely one of the many symptoms.
Hmmm, I hear there is a new type of car around that has the possibility of running much better and being safer. However, it is well known (to those that employ critical thought at least) that the new car design is riddled with many of the same stupid idiots and stupid decisions that my current car's designers are plagued with. However, there are signs that some are recognizing this. Basically they believe that "anti" and "pro" rhetoric are useless if aimed at particular implementations but if aimed at methodologies and standards of work they are invaluable. These people will readily ignore the wanna be's that simply want to rebel for rebellions sake and "strike out" either for or against either the old car companies or the newest. They want to learn from the past in order to grow from the experiences... not just parroting certain bits and pieces of wisdom only when convenient to their emotionally derived opinions and decisions. I will do my best to support these people if only because I know they understand that elitism and "tude" do not a superior car make.
Yes, this lets you have different versions of *global* DLLs, but most developers from now on won't be creating global DLLs, they'll just make their own DLLs local.
.Net from version 1.0 allowed you to just put all of your own .exe's and .dll's in your own app directory and forget about the registry and other apps and .dll's and their versions, etc.
.Net platform itself) in your own app directory and run it. To install it on another machine, just drag the folder over and it's installed. To delete it, just drag the folder into the trash. It's independent of anybody else's app. It's a trip back to the 1980s.
.Net, they've changed it so that the default way is to forget the registry, forget sharing to save disk and memory space, and encapsulate for reliability, portability, and scalability.
The design of
Put everything your app needs (other than the
Some people have taken this approach for years, using static linking or other techniques, but the "official right way" to do it was to use DLLs that you registered in the registry, etc.
With
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
its more useful than that man up2date or up2date --help next chance you get, its accualy pretty useful. it updates any package that is on the distro cd's or you can install the latest version of those packages if there not already installed.
Noone writes jokes in base 13!
That wasn't what he said at all...
> Indeed most libraries have subversions, but most apps just link to the major version. When an app insists it needs version 6.3.2.4.33 it gets nasty...
That, to me, is saying that Linux doesn't have DLL problems, since most versions link to the major version (which is correct). "When an app insists it needs version 6.3.2.4.33 it gets nasty" does not at all imply that linking to specific versions is a common habit, only that if there are any applications that did, things would get nasty. Which they would.
Advanced users are users too!
If you read the article, you'll see that this is the GAC (Global Assembly Cache) in .NET Framework. This isn't for general purpose DLL's as you and I know them, but for .NET assemblies.
me schpeak engrish too wells. meez soe smarts
One could not be a successful scientist without realizing that, in contrast
to the popular conception supported by newspapers and mothers of scientists,
a goodly number of scientists are not only narrow-minded and dull, but also
just stupid.
-- J.D. Watson, "The Double Helix"
- this post brought to you by the Automated Last Post Generator...