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."
When 1Gb of memory becomes standard, then maybe. In any case, it is downright inefficient to have the same code in 3 or 4 places in memory, even if you have got loads to spare.
Conversion Rate Optimisation French / English consultant
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
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.
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/
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.
Old hat, already been done. See IBM MVS LPA, CLPA, and VLF , Virtual lookaside Facility (handles any object not just dlls. Oh what about the hyperthreading bug for XP sp1.
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.
Try using a different shell. It seems to me that explorer takes up a ton of ram, especially when doing anything besides looking at the background. Aston shell does great, and when paired up with the newest Phoenix build, everything seems to just zip and open up fast, and memory usage is a lot lower. :)
No I didnt spell check this post...
All true, and all reasons why shared libs are a good idea.
Trouble is, having several instances of essentially the same library causes many of the same problems that static linking does.
I think that the way it's done on OSX works well.
The application is distributed as an application bundle that contains, as well as the executable, any support files. The bundle looks like a normal file but, like a directory, can be browsed and contain sub-directories.
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
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."
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.
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.
It adds versioning to dlls -- that's all. Multiple programs can use the same version. If a new version of the dll is added (even if it has the same name), the system will direct old applications to the old dll and new ones to the new dll.
See this
I've been working on this problem. I created an application that creates a compressed virtual filesystem containing the EXE, DLLs, and datafiles that can be deployed in a "pre-installed" state. When the application runs, a virtual machine technology similar to WINE is used to allow the application to load DLLs directly from the archive rather than go to the operating system. Unlike VMWare/WINE, however, the virtual filesystem is transparently merged with the real filesystem so the application can access files from ether place with no source changes. Also 90% of Windows API calls do not need to be replaced so there a very few compatability problems. The next version will have support for a merged virtual registry as well, so you can deploy ActiveX/COM controls without having to register them or even write to the system registry at all.
Check it out:
http://thinstall.com
-- Virtual Windows Project
Don't discount the amount of memory that you can save from shared libraries and DLL's. If you have a DLL which consumes, on average, 5M of ram and it's used by three applications at the same time (e.g. word, excel, outlook), that's a savings of 10M (3x5-5M; one still has to use it). It doesn't take too many applications (think GUI widget sets) to be run concurrently for this to significantly add up.
It also helps reduce application start up times on MS platforms. In the case of Win, they don't generally use load on demand as one thinks of from the unix world. Instead, they load all references into the page file and then demand load from the page file as needed. This means, shorter start times for applications which share DLL's as they only have to be loaded once (into the page file).
Really most UN*X systems (in particular those which are glibc based) already implement Microsoft's "new" scheme. For example, in /usr/lib/:
Note that this scheme can create a "unique identifier" allowing an application to use a particular function using "libname.particular.version" and the the name of the function.If an application just wants to use libgtkhtml but doesn't care what version it uses it will use "/usr/lib/libgtkhtml.so" and will get the most current version. If the application has a requirement of a version 19 of libgtkhtml it would use "/usr/lib/libgtkhtml.so.19" and get the latest version of libgtkhtml.so.19.0.1. If an application wanted version 20.1.3 it would merely use "/usr/lib/libgtkhtml.so.20.1.3". At any rate, you get the idea.
It amuses me every time Microsoft comes out with a "new" twenty year old technology (such as say, symlinks). It's a move in the right direction but I think they lack the humility to say that they've been rejecting the right answer all along.
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).
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 ;)
I can definitely see that that is where this is going. Perfect example: XP is skinnable. But, only MS certified skins can be run on XP. MS has not made any avenues for making certified skins. The result? Download a hacked DLL and then use non-certified skins.
There is a massive community of XP-Styles, all centered around a hacked uxtheme.dll. If Explorer specifically looks for a specific version of uxtheme.dll instead of the filename, they're SOL.
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.
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!
I think this simply works by allowing different versions of the same DLL.
Right - given N programs using foo.dll, how many different versions of foo.dll do you expect will be needed? Based on my experience with Windows, I would expect somewhere between N and 2*N (allowing for "upgrades" of N[i] which won't remove the "old" DLL version.
Yes, theoretically, you'll have a smaller number of DLLs than you do programs. Realistically, I don't see it happening. The various versions of Microsoft's XML DLL (which comes to mind because of the security patch which requires you to figure out which versions you have installed, which is always more than 1) illustrate this perfectly.
Quick. What is a utility which will tell you all the shared libraries that an application uses?
librt.so.1 =>
libc.so.6 =>
libpthread.so.0 =>
-- I speak only for myself.
Untrue.
The permissions of symbolic links are not used.
From chmod(1),
AFAIK, symbolic links aren't actually changed, only created and deleted.
In order to do that, you need write permission on the directory.
HTH.
www.timcoleman.com is a total waste of your time. Never go there.
Yea, he's just saying they would try to take credit for it if they could.
In all fairness NTFS had journaling years before any linux filesystem did.
If you wanna get rich, you know that payback is a bitch
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 is not clutter, apart from the fact that your list includes static links and directories, about two thirds of the dll's you listed are symbolic links to versioned filenames to avoid clutter.
He saw some dirty arabs and fired. Too bad it was just some friendly kurds, BBC reporters and his fellow cowboys.
Actually as far as the .NET Framework goes, you have what is called Publisher Policy. In the Global Assembly Cache (GAC) are all of your shared assemblies (dll's). To get a shared assembly in the GAC you have to "Strong Name" it and give it a version number. Any new versions of said assembly put in the GAC with the same strong name/version number will overwrite the old ones (and note that the strong name is made by take a hash of the contents of the dll, so it would be awfully hard to fake).
However, if you are a good developer and modify your version numbers on subsequent builds, when you put that assembly in the GAC you'll have two versions. Publisher Policy is an XML file compiled into a dll that allows a developer to say "don't use version 1.1.2.345, use 1.1.2.456 instead". Then all requests for the old version will be redirected to the new version instead.
Hence, if you do it correctly, there's no security risk with what you're talking about.
-- What did Spock find in Kirk's toilet? The captain's log.
You increment its minor version number. All the applications should be linking to a major version number. For example:
libfoo.so -> libfoo.so.4
libfoo.so.4 -> libfoo.so.4.3
libfoo.so.4.3 -> libfoo.so.4.3.2
libfoo.so.4.3.2 (this is an actual file)
libfoo.so.4.3 -> libfoo.so.4.3.5
libfoo.so.4.3.5 (4.3.2 file deleted)
This system has been around for decades in the Unix world.
I think you're taking this to the extreme. They're doing this by using a similar method (if not the same) that .NET uses for versioning their assemblies. You simply tell your .exe by using an attribute in the source code which assembly version to use. Then, you compile the assmbly saying it is whatever version you want. If in the future, another program comes along that installs new software, it'll be compiled to use the newer assembly. Then, if the original author determines that the new assembly is compatible, they simply release a patch that has a file called 'myprog.exe.config' and the .config file is an XML file saying the new version to use.
.dll files can use this scheme as well. So, installing your service pack won't break half of your programs, but it may still allow them to implement new security and usability features. TONS of programs use the generic windows dlls so it's not like you're completely getting rid of the idea of dynamic libraries.
.config file. However, 1) you'd have to be an admin to write to the dir and 2) there are things called "Strong Names" which involve encryption keys that also help with identifying assemblies and dlls, but I'm light on the technical details of this.
.so's all over the place and I have no idea what programs are linking to it (if any).
Not just programs will use this, but the generic Windows
This brings in security implications because anyone can write a
So, don't draw conclusions and knock it down so quickly. It's actually a really good way to allow old programs to keep working until it's determined that yes, you can upgrade. As far as removing old dlls so you don't get cruft, I'm not exactly sure how that will work, but it's not like Linux doesn't have this problem as well. After awhile, I have tons of
-Shippy