Slashdot Mirror
"Side By Side Assemblies" Bring DLL Hell 2.0
neutrino38 writes "This is an alert for all developers using Microsoft Visual Studio 2005. At the beginning of January, Microsoft issued a security fix for Visual Studio 2005 forcing the use of new dynamic libraries (DLLs) by all applications compiled with this IDE. Basically, applications compiled with Visual Studio 2005 will not work anymore on an ordinary (non-dev) PC unless the newer DLLs are installed. And we found out that this is true on fully updated PCs. I just posted some details and some suggested fixes." Read below for some more background on Microsoft's so-called "side by side assemblies."
For those unfamiliar with the Microsoft world, native microsoft applications written in C++ rely on dynamic libraries. Two of them are infamous: MSVCRT.DLL and MFCxx.dll. Because of software evolution and security fixes, multiple versions of these DLLs were often present in the system, causing application instability. Where Linux implemented a simple suffix notation on the dynamic libraries, Microsoft created a new beast in 2001: the Side By Side assembly. These are basically DLLs with a companion XML file that identifies them. The XML file contains a digital signature and when the system binds these DLLs dynamically to an application, it checks that the signature of the DLL matches the DLL itself. When everythings runs well, this is pretty transparent. But when issues arise, it becomes excruciatingly difficult to troubleshoot and fix. DLL hell is not over.
For those unfamiliar with the Microsoft world, native microsoft applications written in C++ rely on dynamic libraries. Two of them are infamous: MSVCRT.DLL and MFCxx.dll. Because of software evolution and security fixes, multiple versions of these DLLs were often present in the system, causing application instability. Where Linux implemented a simple suffix notation on the dynamic libraries, Microsoft created a new beast in 2001: the Side By Side assembly. These are basically DLLs with a companion XML file that identifies them. The XML file contains a digital signature and when the system binds these DLLs dynamically to an application, it checks that the signature of the DLL matches the DLL itself. When everythings runs well, this is pretty transparent. But when issues arise, it becomes excruciatingly difficult to troubleshoot and fix. DLL hell is not over.
Microsoft FTL.
Speaking as a user, can we get statically linked libraries? I don't care if it's dependency hell or DLL hell. I want self-contained applications.
Guess what .NET VM is written in.
Everybody who developes applications for the Windows platform should know that you need to include the merge module for the C/C++ runtime libraries in your installer. You've just been luck so far that other applications have installed the DLL's you needed for you. Try your app the way it is on a clean install of Windows XP without the service packs and see how well that goes :P
In fact the SxS assembly system in windows is the only real way out of DLL hell, much better than the versioning scheme for shared libraries used in Linux. Get your facts straight before posting.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
This has been heavily debated in comments in the Visual C++ blog:
http://blogs.msdn.com/vcblog/archive/2009/08/05/active-template-library-atl-security-updates.aspx
Unfortunately, the VC++ team doesn't seem to understand what's wrong with pushing out a critical update through automatic updates that silently updates dependency requirements. I've personally seen projects that were suddenly broken by this update and the ensuing confusion that resulted.
Now that memory is so cheap and disk space even cheaper, do we still need the small process sizes that dynamic linking brings?
Would it be worth burning more RAM (although in an on-demand paged system, there's obviously no need to have your entire processl resident) to get rid of the problems associated with incompatible versions of libraries. Just go back to statically linking everything, so yo only ever need 1 binary - as all the routines it will ever call are already part of it.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
No, because that's what sxs solves. You can have multiple versions of the MSVCxxx libraries installed and each app can find the correct one.
It's similar to the library versioning that unix does, except instead of changing the filename each library has a manifest containing its version number and a checksum of the library, and the loader knows how to fing the right one.
This is a complete non-story written by someone who doesn't test applications on a clean system prior to distribution, then wonders why it doesn't work.
You do understand that DLL Hell exists exactly because version X and Y DO have huge differences?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Yeah SxS works a treat. No more dll hell. Great for servicing too. The problem here is moronic devs not shipping the libraries that they link against. MS would be castigated if they didn't fix security holes. Why oh why does kdawson think this is a return to dll hell? Does he actually know what SxS is? Does he even have experience of windows development?
Writing "managed" code has nothing to do with using sane concurrency abstractions. You can do one without the other. Hell, you can easily write buggy managed code that relies on raw semaphores and deadlocks often, and you can write elegant message-passing C++ code. The key is the abstraction, not the runtime mechanism.
everyone having their own DLL would be the same as just statically linking everything. you'd have tons of code duplicated and loaded. have no easy way to patch common code system wide.
People suffer DLL hell because it is better than not using DLLs at all.
“Common sense is not so common.” — Voltaire
If your installer doesn't make sure that is the case, you're an idiot, cause that's what installers are for.
I'm Rocco. I'm the +5 Funny man.
And yet Office still boots twice as fast as OpenOffice on a typical computer, IIS and MS SQL are completely neck-and-neck with their competitors, and Outlook completely trounces its closest competitor, performance-wise.
I mean, I completely understand what you're saying: having multiple copies of the same function/code block in memory is inefficient. But in practice, it doesn't seem to be hurting them anyway.
Comment of the year
MS shouldn't really be allowing such poor practices. Why should my memory be eaten up by loads of DLL files that are nearly identical. Let's face it, there isn't going to be huge differences between version X and Y.
Versions X and Y of a DLL will be flat-out incompatible if that DLL is written in C++ and the author has changed the number of attributes in an interface class (unless he uses tricks such as pimpl), or if he's added or removed any virtual functions.
And the fact that Microsoft is so good at preserving application backward compatibility, even in the face of "poor practices", is frankly one of the main reasons that Windows is the #1 business desktop operating system in the world.
Microsoft did this intentionally. They deprecated the vulnerable version of the dll. You "solution" to the problem of your customers still running the vulnerable version of the VC dlls should be to either force them to upgrade or install the new dlls for them. Instead you decide the security is a hassle and undo the fix on your developer machine, so you can ignore the larger issue that you are building insecure software and you customers are running insecure computers. Fix the problem, instead of whining about it and continuing to crank out crappy .net software. How hard would it be to have your software check for the problem dll versions, and direct the customer to download/install the new version? Cripes, games do it all the time when they check what version of direct x is installed.
They're virtually identical. Linux encodes the version number in the filename, which is bad practice for the same reason that file extensions defining file types are bad practice, but it's human-readable. Windows encodes the version number in human-readable XML, and goes one step further by giving it a checksum.
The one other visible difference is if you try to gaze into the internal implementation details of Windows by navigating to %windir%\SxS and then take a naive view of the size of the directory, you might get your panties in a twist. Now, granted, the SxS structure there also essentially encodes version information in the directory structure, not so different from Linux, but abstracted away by the OS.
Can you Brainfuck faggots stop bringing it up any time that a programming-related topic is discussed here?
Yes, we already know about Brainfuck. Most of us have known about it for many years now. We don't need cockfools like you bringing it up so bloody often.
Frankly speaking, any sane person compiling C++ code for Windows will just statically link the standard library, rendering this a non-issue.
Most coders just write against API and should not care about binary compatibility.
A well-designed stable API should also ensure binary compatibility. That's almost a given with C APIs, fairly trivial to get with Java or .NET, and needs special attention but definitely possible with C++.
I really hate this /lib stuff. I remember the first time I make a C binary executable with GCC. It worked find on my Linux box, so it must work fine on any other Linux box I thought. Wrong! Turned out I needed to apt-get a whole bunch of libraries...
Seriously, all you are saying is that you didn't understand that your compiler was linking to a bunch of libraries, some of which were distributed with the OS and others were your responsibility to distribute when you created the application's setup/install package.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
"I was really pissed when I discovered that Microsoft had discontinued all versions of Visual Studio Express under the most recent one (2008, I believe?). I had to go and get a copy of VSE2005 off of bittorent since you could no longer download it from the Microsoft web site."
Then you got pissed and used BitTorrent for absolutely no reason whatsoever, because Microsoft are touting Visual Studio Express more than ever nowadays, it's become a core product for them.
http://www.microsoft.com/express/
What gave you the impression they'd discontinued them? Even on the standard Visual Studio pages links to express are and always have been clearly visible.
"It works fine for me" said the MS developer.
I put it down the the decline of Microsoft, I've been working as a MS dev for the past 15+ years, and since Bill left (a coincidence, I feel) the company has started a steady decline - wasting their money on frippery, attempting to get a new growth market, screwing with established systems in place of selling new stuff, and generally trying desperately to get your money off you. At least in the past, they were also focussed on making good technical stuff too.
Put it in stackoverflow.com as a question. And then just answer it yourself.
Robin Smidsrod Certified Linux Administrator
The problem is when MS gimp Windows to hell - they know the workarounds, so Office runs OK.
Oh come on! You can't just say stuff like that without providing any evidence. Do you have any? At all?
It seems to be that Windows performance, in general, is at worst on-par with the competition. Even Vista, if your computer meets the hardware specs. Now you're telling me that the only reason OpenOffice runs slow is because all of Windows is "gimped", and Office contains some kind of cheat code that "un-gimps" it? Seriously?
Comment of the year