Slashdot Mirror

← Back to Stories (view on slashdot.org)

"Side By Side Assemblies" Bring DLL Hell 2.0

Posted by kdawson on from the long-nightmare-is-not-over dept.

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.

10 of 433 comments (clear)

  1. Speaking as a user by Anonymous Coward · · Score: 5, Insightful

    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.

  2. You should not blame Microsoft for this by igomaniac · · Score: 5, Insightful

    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/
    1. Re:You should not blame Microsoft for this by Tony+Hoyle · · Score: 5, Insightful

      Indeed.. this is a non-story. If the submitter had distributed his app correctly it would have worked out of the box. Instead he decided to rely on a specific version of a DLL being installed on the target system, then blames Microsoft when it all goes to hell.

    2. Re:You should not blame Microsoft for this by JohnFen · · Score: 5, Insightful

      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.

      Better than the Linux scheme + proper shared library design? How? I've done extensive work with both, and the SxS scheme seems like like a gigantic, fairly ugly hack to me (albeit not as ugly as a lot of other hacks) and Linux's scheme, while not perfect, seems much more elegant and reliable.

      I'm not trolling or picking a fight, I really want to know.

    3. Re:You should not blame Microsoft for this by QuoteMstr · · Score: 5, Insightful

      The SxS system also has some additional security since it uses signatures for the DLLs when loading your process, so it's much harder for a hacker to replace the library you're using behind your back (by setting LD_LIBRARY_PATH for example).

      Funny, it's only proprietary software authors that think this way. Over here in the free world, application flexibility is seen as a Good Thing. LD_* hacks might not be the most elegant way to implement certain functionality, but the approach certainly makes hard things possible.

      And again, the SxS signing approach doesn't actually add any real security. Someone wanting to modify an application will find a way to do it regardless of any special "don't modify me" bits the application might contain.

      (Go ahead and moderate this troll. That doesn't make it any less true.)

    4. Re:You should not blame Microsoft for this by Blakey+Rat · · Score: 5, Insightful

      A thing that a LOT of Linux programmers (and a lot of programmers in general) seem to miss is this simple fact, bolded for emphasis:

      Most programmers suck.

      The very fact that you're here reading Slashdot means it's likely that you do not suck. Most programmers do. For most programmers, "cargo cult" programming is a way of life. The majority of programmers do not, and never will, fully understand pointers to the level where they would be able to re-create the C++ STL by themselves. Relevant to this discussion: most programmers don't know how linking works, they just hit the "Play" button on the IDE and off it goes. Most programmers have zero knowledge of user permissions or fast user switching, and see nothing wrong with writing their application data in the Program Files folder.

      Most programmers never, ever read the API documentation. Not only do they have no problem using deprecated functions, but they don't even know what functions are deprecated.

      And when their programs break because of this? They blame Microsoft! It's Microsoft's fault, always Microsoft's fault!

      Now the open source community might be lucky enough that it has no bad programmers. (I doubt it, but let's play along.) Good for you. Microsoft, unfortunately, isn't that way: one of their biggest challenges is to keep terrible programmers from constantly breaking their own apps and/or Windows itself.

      What I'm getting at here is that Microsoft's goal is to make programming for Windows as easy and hands-off as possible. Any solution to this problem that requires the programmer to fix their application is far inferior than a solution that works "automatically."

      The programmer who posted this topic didn't read Microsoft's documentation, and screwed up his application's installer so that it links directly to a specific library version DLL instead of to the version-agnostic DLL. He's one of the bad programmers I've been talking about, but to be fair: considering he's actually posting here, it's probably one of the best of the bad. Hopefully he'll take something away from this and Slashdot won't spend the entire thread bashing Microsoft for no reason, but I doubt it.

      --
      Comment of the year
  3. Discussed on Visual C++ blog by Anonymous Coward · · Score: 5, Insightful

    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.

  4. Re:Non-issue for actual msdn coders like myself by Tony+Hoyle · · Score: 5, Insightful

    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.

  5. Re:Also... by Niten · · Score: 5, Insightful

    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.

  6. You sir are part of the problem! by fluffy99 · · Score: 5, Insightful

    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.