Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

"Side By Side Assemblies" Bring DLL Hell 2.0

kdawson posted about 5 years ago | from the long-nightmare-is-not-over dept.

Microsoft 433

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.

cancel ×

433 comments

Sorry! There are no comments related to the filter you selected.

Oh the beauty of fixing what was already working (2, Insightful)

csueiras (1461139) | about 5 years ago | (#29637951)

Microsoft FTL.

And by all developers you mean (1)

liquiddark (719647) | about 5 years ago | (#29637953)

This is C++-only, right? Cuz I develop .NET code all day in VS2005, and it works very happily on all sorts of messed up machine configurations.

Re:And by all developers you mean (1, Insightful)

Anonymous Coward | about 5 years ago | (#29638017)

Guess what .NET VM is written in.

Re:And by all developers you mean (5, Funny)

Anonymous Coward | about 5 years ago | (#29638119)

Java?

Re:And by all developers you mean (3, Funny)

freak132 (812674) | about 5 years ago | (#29638401)

Brainfuck actually. [wikipedia.org]

.NET internals (3, Interesting)

NoYob (1630681) | about 5 years ago | (#29638027)

I don't know. Let's say you're developing in C# or VB and you make calls to a library that is really a bunch of C++ classes and methods with a C# or VB wrappers. Then, I'd assume, you would indeed have this problem.

Someone with knowledge of .NET internals care to comment?

Re:And by all developers you mean (0)

Anonymous Coward | about 5 years ago | (#29638155)

No. There is just no way this will have an effect on .NET applications. If anything they will make an update for the .NET framework. As with previous Service Packs for the framework you won't see any negative effects with that.

Re:And by all developers you mean (1)

Tony Hoyle (11698) | about 5 years ago | (#29638223)

Which version of .net? Which build of that version? No good trying to run code written on .NET 3.5 on .NET 2 for example.

Same with other elements like DirectX.

If your installer doesn't make sure that the right version (or later, if applicable) is installed you'll get exactly the same problems.

Re:And by all developers you mean (0)

Anonymous Coward | about 5 years ago | (#29638267)

Visual Studio 2005 can only work with version 2.

Re:And by all developers you mean (1, Interesting)

Anonymous Coward | about 5 years ago | (#29638271)

.NET 3.5 uses the 2.0 CLR. If you don't use LINQ or WPF or a few other features, then your code will run on 2.0. Also, Visual Studio can target whatever version you want.

Also... (4, Informative)

SigILL (6475) | about 5 years ago | (#29637981)

What might be interesting to note here is that the summary isn't everything there is to side-by-side (SxS) assemblies.

Suppose you're building an application using two DLLs, let's call them A and B. Both depend on a third DLL named C. Now, suppose A uses C version X, and B uses C version Y. You're screwed, right? Not with SxS, since that allows multiple versions of C to be loaded. That's the real added value of SxS.

All this is in theory of course, which as we all know is in theory equal to practice, but in practice is not...

Re:Also... (0)

Anonymous Coward | about 5 years ago | (#29638043)

Bullshit. The real problem is C version Y not being backward compatible to C version X, leading to this idiocy of piling more and more complexity on top of a totally rotten mechanism.

Re:Also... (5, Informative)

SigILL (6475) | about 5 years ago | (#29638109)

The real problem is C version Y not being backward compatible to C version X, leading to this idiocy of piling more and more complexity on top of a totally rotten mechanism.

It might surprise you, but Microsoft isn't actually to blame here. Rather, the legions of incompetent programmers that wrote DLLs such as C are to blame. We'd call them idiots, but Microsoft calls them paying customers. Thus prompting them to design SxS and incorporate it in WinXP.

Also, SxS is what made the restyling of the UI (through common controls version 6) technically possible.

Microsoft takes backwards compatibility very seriously.

Re:Also... (1)

thetoadwarrior (1268702) | about 5 years ago | (#29638159)

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.

Re:Also... (4, Insightful)

mwvdlee (775178) | about 5 years ago | (#29638193)

You do understand that DLL Hell exists exactly because version X and Y DO have huge differences?

Re:Also... (0)

Anonymous Coward | about 5 years ago | (#29638295)

If they do, then they should be different DLLs entirely, not just different versions with the same filename. Like wsock32.dll and ws2_32.dll.

Re:Also... (1)

SigILL (6475) | about 5 years ago | (#29638241)

MS shouldn't really be allowing such poor practices.

What are you proposing exactly, have them automatically analyse all code that is being released (and solve the halting problem at the same time)? And how would you propose they deal with the ensuing shitstorm? There are actually legitimate reasons for DLLs changing you know, like the common controls I mentioned.

Besides, what would you rather have, a program not working in its entirety, or working properly and using a meg more memory (that'd be a huge DLL; the code segment of most DLLs is barely half that)?

Re:Also... (0)

Anonymous Coward | about 5 years ago | (#29638229)

Uh, unless the incompetent programmers you speak of work for Microsoft, WinSxS doesn't apply. The DLL has to be designed to use and install into the WinSxS mechanism, and so far as I can tell only Microsoft is using it for non-.NET DLLs.

Re:Also... (1)

SigILL (6475) | about 5 years ago | (#29638275)

The DLL has to be designed to use and install into the WinSxS mechanism

Oh, yeah, you're right, sorry. Somehow the myriad SxS calls I've seen littering the MFC source must've slipped my mind.

Re:Also... (0)

Anonymous Coward | about 5 years ago | (#29638237)

"this idiocy of piling more and more complexity on top of a totally rotten mechanism"

That's exactly why, in the real world, we sometimes choose to make C version Y not backwards compatible with C version X. It lets us get rid of the cruft. You understand that, right, paco?

Re:Also... (3, Interesting)

Anonymous Coward | about 5 years ago | (#29638279)

.NET's strong requirements mean it no longer matters if "foo.dll version 1.5" breaks backwards compatibility with "foo.dll version 1.4", because the developer has the option to say at compile time "ONLY use foo.dll version 1.4". Consider this from the perspective of the end user, the application developer, and the dll vendor.

The dll vendor is happy, because they can release new versions into the wild on their own schedule. Win.

The application developer may or may not have been aware that the vendor released a new version of the dll. Fortunately the new DLL can't break the old code, so all regression testing that passed on the dev machine will pass on every end user machine, provided the end user didn't delete the original dll. Typically the the application developer has a license to redistribute the vendor's dll with the application; in that case running the setup application will restore perfect functionality. Win.

The end user wants things to just work. Some "advanced" end users may know that the dll vendor released a new version that fixes some frustrating bug in the application, so they pressure the developer to release a new version of the application. Meanwhile, nothing broke. Win.

Win. Win. Win.

The only downside is that "advanced" users can't fuck with the application and try to make it use the wrong DLL. I see that as an added bonus.

Re:Also... (2, Informative)

QuoteMstr (55051) | about 5 years ago | (#29638313)

The only downside is that "advanced" users can't fuck with the application and try to make it use the wrong DLL. I see that as an added bonus.

The rest of your post makes sense (though Unix-style versioning can do the same thing), but this point is wrong. Don't fool yourself or anyone else into thinking you can't modify any application regardless of this stuff. Of course you can: all the SxS stuff might do is make it a touch more difficult.

Re:Also... (0)

Anonymous Coward | about 5 years ago | (#29638045)

And when the two versions of C are in fact functionally identical (except for few bug fixes in the later versions), as is usually the case, you're just wasting memory.

Re:Also... (0)

Anonymous Coward | about 5 years ago | (#29638249)

Ha, what they do with OSGi packages in Java. Parts of your application can use different versions of the same basic library.

Speaking as a user (5, Insightful)

Anonymous Coward | about 5 years ago | (#29637987)

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.

Re:Speaking as a user (3, Informative)

Darkness404 (1287218) | about 5 years ago | (#29638041)

All that is just great until you realize that each application may be -huge-. If someone can make a small script that converts OGG files into MP3 files using both the OGG encoder and MP3 encoder that is already on my system, it saves me from downloading ~20 MB of extra files.

Re:Speaking as a user (2, Informative)

WarwickRyan (780794) | about 5 years ago | (#29638191)

But the other side is that the OS is massive.

c:\windows alone is 11gb, with \winsxs being around 6gb.

Googling shows that \winsxs is where all these dll versions are being stored.

I haven't got close to 11gb of applications installed (and I've got VS, SQL server + office on here).

Re:Speaking as a user (4, Insightful)

Tony Hoyle (11698) | about 5 years ago | (#29638239)

If they were statically linked you'd have way more than 11gb of applications..

Re:Speaking as a user (4, Insightful)

QuoteMstr (55051) | about 5 years ago | (#29638243)

But the other side is that the OS is massive.

It'd be more massive if everything were statically linked.

Remember, shared libraries didn't come first. The world began with static libraries, and shared libraries came later. There were good reasons for the switch, and those reasons apply even today.

Re:Speaking as a user (1)

zippthorne (748122) | about 5 years ago | (#29638409)

Except that now gnome desktop manager needs something in a library provided by the Evolution package, and you're stuck downloading and installing a half-gig email client because you want to run GIMP.

Static linking might very well be worth it in these days of improperly re-factored libraries. Or stuff should be severable. Or the libraries should be sanely provide with in the correct packages.

Re:Speaking as a user (2, Informative)

QuoteMstr (55051) | about 5 years ago | (#29638433)

Or the libraries should be sanely provide with in the correct packages.

Just like in the physical world, bad packaging can fuck up an otherwise good product.

Incidentally, on Fedora, the scenario you describe doesn't occur.

Re:Speaking as a user (3, Interesting)

MioTheGreat (926975) | about 5 years ago | (#29638309)

No. Winsxs is not 6gb. That's just explorer being stupid when it tells you how big it is. There are a lot of hard links in there.

Re:Speaking as a user (1)

omuls are tasty (1321759) | about 5 years ago | (#29638497)

It's not just the disk space, it's also the memory. With shared libraries, you only have to load the code into memory once.

Re:Speaking as a user (2, Informative)

calmofthestorm (1344385) | about 5 years ago | (#29638283)

Also keep in mind you're looking at a huge RAM footprint as well, since multiple copies of the same library will be loaded per-application, whereas sometimes you can make optimizations for libraries shared across applications with paging magic.

That said, I thought that OS X apps were statically linked (except with OS libs), and thus tend to be large, but reduce this issue since so much functionality is based on system libs. I could be wrong; I don't really ever work with non-linux systems.

Re:Speaking as a user (0)

Anonymous Coward | about 5 years ago | (#29638323)

No, they use something called frameworks. I also stick to the linux side of things, but frameworks are definitely the equivalent to dynamic libraries (I believe the equivalent would be to package the so, header, + docs into 1 file).

Very few people do static linking today.

Re:Speaking as a user (5, Informative)

Timothy Brownawell (627747) | about 5 years ago | (#29638069)

That's great until some common library needs to be updated for a security hole, and you have download 20 updates from different vendors (assuming they even provide updates...) rather than 1 item in Windows Update.

Re:Speaking as a user (0)

Anonymous Coward | about 5 years ago | (#29638079)

There's absolutely no good reason, why two programs that use the exact same library, can't share that library. Take a Gnome desktop app for example. Pretty much every Gnome application will use a few standard libraries, such as GTK+ and glib. They aren't THAT big, but do we really want all that code loaded for each and every application that needs them? Memory usage would go through the roof.

Re:Speaking as a user (2, Informative)

lilo_booter (649045) | about 5 years ago | (#29638261)

Totally agreed - and additionally, the rigid static linking doesn't work in a plugin environment where each plugin (which is in itself a shared library/dll) brings in its own (shared) dependencies based on the users requirements. Apologies to the OP, but users really shouldn't make demands at this level - there are many reasons why developers and packagers prefer dynamic loading, and likewise it's *their* responsibility to get it right such that users aren't even aware of this level of detail.

Re:Speaking as a user (1)

moon3 (1530265) | about 5 years ago | (#29638131)

self-contained applications

TFA problem is easily resolved by statically linking the stuff. And the thing you pointed up is the Achiles heel of pretty much any *NIX system where the app dependencies are often much more widespread and the app itself is not self-contained, but rather disseminated over the whole system.

Re:Speaking as a user (2, Informative)

seneces (839286) | about 5 years ago | (#29638325)

Applications can statically link the CRT with /MT or /MTd instead of the (default) /MD and /MDd. It's pretty common, and i've found that the actual increase to binary size is very small. It often cuts down on distribution size anyway, since that allows /OPT:REF (eliminate unreferenced code) to take effect. It'd be nice if the CRT was available on all systems by default and we didn't have to worry about it, but failing that, static linking is a *necessity* for anything that doesn't use a full installer.

Re:Speaking as a user (1)

QuoteMstr (55051) | about 5 years ago | (#29638385)

Why would you need to statically link your libc in order to eliminate unreferenced symbols in your own program? GNU ld can do that without having to link statically. You might be saying that thanks to unreferenced symbol elimination, linking libc isn't that onerous, and you might be right. But your program should never be smaller after static linking.

Re:Speaking as a user (0)

Anonymous Coward | about 5 years ago | (#29638355)

Except the problem with that is that you end up with insecure applications. I'm shocked that the linked article's solution is "Remove the security fix KB971090". I wonder how his customers will react when that's suggested. The complaint that applications won't work unless the new DLLs are installed is pathetic - anyone with the old DLLs will have them updated by Windows Update, and distributing them is just a matter of rebuilding the installer with the new runtime distribution - which is not an onerous task. The comment that this is "Not very convenient" shows they've been too damned lazy to write a proper installer anyway. Added bonus, it's easily possible to write your applications to use the latest version of the DLL, no matter what that is.

Frankly I'd take the bitching of anyone that says users should uninstall a security patch because they're too lazy to write an installer with a *huge* pinch of salt.

Re:Speaking as a user (0)

Anonymous Coward | about 5 years ago | (#29638469)

I think the suggestion was to remove KB971090 on the *developer's* system -- thus causing modules built on that system to refer to the SP1 version of the CRT again. Users can continue to have KB971090 installed -- it installs a policy in WinSxS to redirect references to the SP1 CRT version to the updated DLL.

Re:Speaking as a user (1)

CodeBuster (516420) | about 5 years ago | (#29638443)

Statically linked libraries are no panacea either. For example, suppose that a flaw is discovered in a version of a library which is statically linked into your app. Unless the app is re-compiled with the the newer fixed version of the library your app will continue to use the flawed version and remain vulnerable to whatever code might be injected and executed via the flaw.

Why don't apps just use their own copy of the .dll (2, Interesting)

bit trollent (824666) | about 5 years ago | (#29638011)

Instead of referencing the .dll in \Windows\System\ why don't you reference a copy of the .dll in \Program Files\Your Stupid App\ ?

Seems like a simple fix to me, though I'll admit most of my .dll experience comes from the asp.net/c# world.

Re:Why don't apps just use their own copy of the . (5, Informative)

Anonymous Coward | about 5 years ago | (#29638053)

That defeats the whole purpose of a DLL anyway. The thought was that you wouldn't have to "reinvent the wheel" and you could reuse code. However, Microsoft's failure to document their operating system's API thoroughly in a public manner led to developers relying on undocumented features that were later changed. Then, those applications needed older versions of those libraries and would install them over the newer versions. This, of course, crashed the newer applications. Ugh.

Re:Why don't apps just use their own copy of the . (1)

644bd346996 (1012333) | about 5 years ago | (#29638077)

What do you do when a security vulnerability or other serious bug is found in the version of the DLL? Do you trust the app vendor to be around to release an update in a timely fashion? Or would you prefer Microsoft releases an update that looks for any outdated DLLs anywhere on your hard drive and overwrites them? What if there are games that, as an anti-cheating measure, check the hash of their version of the DLL to detect tampering?

Re:Why don't apps just use their own copy of the . (1)

bit trollent (824666) | about 5 years ago | (#29638407)

Those are definitely good points. The security aspect of it really deserves close attention. At the end of the day you have to weigh the benefits and drawbacks you describe against the possibility that patch Tuesday could kill your application on every computer it is installed on.

Re:Why don't apps just use their own copy of the . (0)

Anonymous Coward | about 5 years ago | (#29638099)

So every time a security bug gets fixed in a system DLL, I have to scour my hard drive looking for versions of it to patch? And when any new program gets installed, I have to apply all relevant security patches to the system DLLs that it ships? Gee, it sure would be convenient if there was just a single location for all of those files!

Oh wait, there is.

dom

Re:Why don't apps just use their own copy of the . (1)

David M. Andersen (711958) | about 5 years ago | (#29638445)

Actually that was a big problem [microsoft.com] with the GDI+ library a few years ago. People have even written their own vulnerable DLL [bleepingcomputer.com] scanners for this sort of thing.

Re:Why don't apps just use their own copy of the . (0)

Anonymous Coward | about 5 years ago | (#29638137)

That doesn't always work. Sometimes the DLL in %system% will be in memory so your local copy won't load or visa versa which could cause issues with apps that need the version in %system%.

Then don't bother (2, Insightful)

OrangeTide (124937) | about 5 years ago | (#29638501)

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.

Re:Then don't bother (1)

QuoteMstr (55051) | about 5 years ago | (#29638537)

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.

Actually, using private, but separate DLLs is much better than static linking. First of all, if there's a vulnerability, it's much easier to find the vulnerable code.

Also, just to play devil's advocate, private DLLs don't necessarily require more memory and disk use. it'd be possible for the operating system to notice two applications are using identical versions of a DLL and to share their pages, even if the two applications are using DLLs that reside in separate files. That'd help on the memory pressure front.

The operating system could even statically link identical copies of the same DLL (or use a copy-on-write approach [lwn.net] ) to cut down on disk use.

Source Engine (1)

Lord_Jeremy (1612839) | about 5 years ago | (#29638023)

Gah! I'm wondering how this is going to affect the source engine. I'm not sure if Valve has migrated their codebase over to a newer version of Visual Studio, but the current versions of the public SDK still use Visual Studio 2005. Hopefully I'll still be able to tool around with my Source mods without too much trouble. As I recall it is possible to use the SDK source code with newer Visual Studio versions, yet you have to jump through some hoops to upgrade the project files.

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.

Re:Source Engine (1)

SigILL (6475) | about 5 years ago | (#29638065)

the current versions of the public SDK still use Visual Studio 2005

For most projects, upgrading sources from VS2005 to VS2008 is really quite painless, no harder than opening the .SLN in 2008 and letting it save the converted result. Are the Source sources really that problematic?

Re:Source Engine (1)

AndrewNeo (979708) | about 5 years ago | (#29638145)

Upgrading projects is not equal to the change in the compliers. Here's the guide on getting the Source SDK working in VS2008: Compiling under VS2008 [valvesoftware.com] .
Actually, upgrading from 2003 to 2005 was far worse, as it required changes to individual files. Fortunately Valve cleaned most of these problems up, making 2005 to 2008 easier.

Re:Source Engine (1)

Lord_Jeremy (1612839) | about 5 years ago | (#29638151)

Admittedly I haven't tried doing the conversion recently, but in the past one would have to solve a large number of compilation issues related to compiler bugs and newer versions of libraries. Looking at the developer wiki article about compiling under 2008 [valvesoftware.com] , this process seems easier than it used to be, but it's still extra unnecessary steps.

Non-issue for actual msdn coders like myself (1, Interesting)

Anonymous Coward | about 5 years ago | (#29638067)

But I always get a chuckle out of the clueless non-coders of slashdot tackling such discussions.

Lol @ all the calls for statically linked libraries (yay its 1982 and I only run one app) or for each app to ship with its own version of the .dll's.

Stories like this really do major harm to slashdots geek-cred. You people really expose yourself as poseurs.

Re:Non-issue for actual msdn coders like myself (1)

mikelieman (35628) | about 5 years ago | (#29638103)

Well, how do you deal with a user who has applications dependent on different versions of libraries then?

Do you just say "FU" to them?

Re:Non-issue for actual msdn coders like myself (5, Insightful)

Tony Hoyle (11698) | about 5 years ago | (#29638181)

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.

Re:Non-issue for actual msdn coders like myself (2, Informative)

sco08y (615665) | about 5 years ago | (#29638219)

YHBT... anyhow, on OS X you can have multiple versions within a framework, and frameworks private to an application. So "it just works."

Packages work beautifully. Anything I need for my app can be bundled right along with it, or in any of the standard directories.

Re:Non-issue for actual msdn coders like myself (2, Informative)

Tony Hoyle (11698) | about 5 years ago | (#29638301)

Multiple versions per framework is essentially how sxs works.. it's the same idea.

Private frameworks to an application isn't new - you can put DLLs local to a windows app too if you want.. OSX has a global frameworks directory that is similar to the sxs directory, and has the same problems eg. if you're linking to the itunes lib you have to check the one you're writing with is on the target system in the package installer (or install it, but for something like itunes that's probably a bad idea).

Re:Non-issue for actual msdn coders like myself (1)

bit trollent (824666) | about 5 years ago | (#29638367)

So your laughing at the people who suggest ways that the .dll update would not have broken their app?

Are you also laughing at the fact that an application that was perfectly functional on monday up and died on patch Tuesday requiring the code to be recompiled and installed on every computer the app is on?

I've had applications that I use (but didn't write) fail after patch tuesday and be restored by a system recovery only to be killed again the next time the system updates. I'm looking at you ATI all-in-wonder tv tuner driver...

But that's not what you are here to talk about. Nope you're here to broadcast arrogant windbag bullshit.

Re:Non-issue for actual msdn coders like myself (1)

OrangeTide (124937) | about 5 years ago | (#29638533)

statically linked libraries have their place. but yes, this isn't one of them.

someone should make a full featured OS where everything is statically linked. and then watch the armchair developers scream about how it requires gigs of RAM to run more than 2 common applications at once.

although actually, there is very little shared code between something like Firefox and something like Office. In the Unix world a lot of libraries (like the whole constellation of X11 libs) are common over many applications. In Windows everyone seems to have their own private framework and toolkit.

You should not blame Microsoft for this (5, Insightful)

igomaniac (409731) | about 5 years ago | (#29638085)

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.

Re:You should not blame Microsoft for this (5, Insightful)

Tony Hoyle (11698) | about 5 years ago | (#29638147)

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.

Re:You should not blame Microsoft for this (1)

Gerald (9696) | about 5 years ago | (#29638217)

How does that work for PortableApps or U3 packages?

Re:You should not blame Microsoft for this (0)

Anonymous Coward | about 5 years ago | (#29638519)

Either they ship private assemblies [microsoft.com] , or they are broken in the first place.

Re:You should not blame Microsoft for this (0)

Anonymous Coward | about 5 years ago | (#29638327)

That's nice, except there are three problems:

1) It was an automatic update. Are you deploying the CRT from DLLs checked into source code control? Screwed. Embedded them into an installer build already? Screwed. In both cases your build breaks first and you have to manually fix it.

2) Many vendors still ship libraries to customers in .lib form. This is a bad idea for many, many reasons, but it's still frequently done. Now you've got your code building against the 4053 CRT and you're trying to link against LIBs that pull in the SP1 CRT. This doesn't work, and you have to convince the vendor to give you updated .libs. This assumes that they will actually accommodate your request, which they might refuse.

3) If you have a large enough build process, you may have modules getting compiled from different machines. Guess what happens if not all of the machines have gotten updated yet?

Re:You should not blame Microsoft for this (1)

igomaniac (409731) | about 5 years ago | (#29638441)

This was a _minor_ version update which means that the newer library gets loaded even for DLLs that reference the older version. So I think your points are all not valid. It's just that this guy forgot to include the runtime libraries in the installer or had some kind of weird setup where he was not including the patched version of the runtime libraries even after his build machine had been patched.

Re:You should not blame Microsoft for this (5, Insightful)

JohnFen (1641097) | about 5 years ago | (#29638329)

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.

Re:You should not blame Microsoft for this (2, Insightful)

igomaniac (409731) | about 5 years ago | (#29638421)

Why do you think it's a hack? I mean, the manifest files used by the SxS assembly system are much more expressive than the three digits used by libtool versioning to tell which shared libraries can be loaded for a specific process. Also note that two DLLs loaded into a process can reference different major versions of the same third DLL without a name clash (leading to two versions of it being loaded), while that's AFAIK not possible with shared libraries.

http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_once_using_autotools

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).

Re:You should not blame Microsoft for this (1)

QuoteMstr (55051) | about 5 years ago | (#29638463)

Also note that two DLLs loaded into a process can reference different major versions of the same third DLL without a name clash (leading to two versions of it being loaded), while that's AFAIK not possible with shared libraries.

This is a terrible idea due to the two versions potentially clashing in other ways (think different definitions of the same shared data structure), but if you really want to do it, OS X's two-level namespace [evaluation.nbu.bg] feature can do that.

Re:You should not blame Microsoft for this (1)

igomaniac (409731) | about 5 years ago | (#29638499)

if one of your DLLs were complied with one version of the datastructure and the other with another version, how else would you try to run this? Do you think the libtool system can solve this? ... Of course it goes wrong if your application starts sending datastructures between DLL A and DLL B which are using different major versions of DLL C, but you can actually code around this. It's better to upgrade your dependencies so they use the same version of DLL C, but sometimes that's just not possible so you have to work with what you've got.

Re:You should not blame Microsoft for this (5, Insightful)

QuoteMstr (55051) | about 5 years ago | (#29638503)

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.)

Re:You should not blame Microsoft for this (2, Insightful)

igomaniac (409731) | about 5 years ago | (#29638547)

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.

You think public key signatures of the executable and it's dependencies is not real security? ... Then what is?

Re:You should not blame Microsoft for this (2, Insightful)

Anonymous Coward | about 5 years ago | (#29638345)

So how is this better? How is it better that when a library has a vulnerability, one has to go over every single application in their system because they all decided to bundle their own, to be sure it won't end up affecting him/her? Not saying you're wrong, maybe I am missing something about what SxS means, but I'm not convinced it is a better scheme.

Re:You should not blame Microsoft for this (2, Insightful)

Cyberax (705495) | about 5 years ago | (#29638453)

Have you tried to install DLLs without using MSI?

It's not so easy with NSIS, for example. And don't get me started on shared DLL usage counters...

DLL hell never left (4, Interesting)

eddy (18759) | about 5 years ago | (#29638093)

I upgraded my Fallout 3 installation yesterday. After patching, the game wouldn't run, returning some fairly obtuse message about import ordinals [google.com] . So I googled the message, and found out it's because the game now links against a newer version of "Microsoft(R) Games for Windows(TM) Live(TM)" whatever. Note that this wasn't some new patch, it's months old and yet this problem, which must realistically be hitting quite a few users, persists. This isn't something you get via Windows Update either, this is just some obscure 'distributable runtime' crap you should know you need?

So let me repeat that: Super mainstream game on a super mainstream platform (Vista x64), no add-ons, I patch to the latest version and it won't start, nothing is mentioned at the developer's site.

Now I recognize good old Bethesda again. Here's how they'd be able to repro: Fully updated Vista machine, install game from DVD, apply patch, notice it won't fucking run.

I don't normally give much for the 'PC-gaming sucks' choir, but c'mon..

... Is it the game or the OS? (0)

Anonymous Coward | about 5 years ago | (#29638227)

On the other hand, pristine Fallout 3 runs perfect on XP...

Re:DLL hell never left (0)

Anonymous Coward | about 5 years ago | (#29638383)

Since Fallout 3 is buggy as Kathleen Fent's pussy on the console, I'd blame Bethesda.

Re:DLL hell never left (2, Informative)

causality (777677) | about 5 years ago | (#29638551)

I upgraded my Fallout 3 installation yesterday. After patching, the game wouldn't run, returning some fairly obtuse message about import ordinals [google.com] . So I googled the message, and found out it's because the game now links against a newer version of "Microsoft(R) Games for Windows(TM) Live(TM)" whatever. Note that this wasn't some new patch, it's months old and yet this problem, which must realistically be hitting quite a few users, persists. This isn't something you get via Windows Update either, this is just some obscure 'distributable runtime' crap you should know you need?

So let me repeat that: Super mainstream game on a super mainstream platform (Vista x64), no add-ons, I patch to the latest version and it won't start, nothing is mentioned at the developer's site.

Now I recognize good old Bethesda again. Here's how they'd be able to repro: Fully updated Vista machine, install game from DVD, apply patch, notice it won't fucking run.

I don't normally give much for the 'PC-gaming sucks' choir, but c'mon..

I had the same problem. Only, I run Fallout3 in Linux via WINE and there is apparently no way whatsoever to get xlive.dll to work in WINE. In addition, you do need the latest Fallout3 patches in order to install the expansions. Personally, I found it unacceptable that I would not be able to use any of the expansions merely because someone decided to add functionality that I never asked for, do not need, and will never use.

I found a solution. There is a patch for Fallout3 that removes all Live functionality, and was sufficient to get the game working for me in WINE because it removes the dependency on xlive.dll. I can now use the game with all five expansions (Mothership Zeta was particularly fun). A page describing it can be found here [loyalkng.com] while a direct link to the download is here [mediafire.com] .

Discussed on Visual C++ blog (5, Insightful)

Anonymous Coward | about 5 years ago | (#29638105)

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.

Please note that this is C++ only (1)

martinmarv (920771) | about 5 years ago | (#29638153)

It does not seem to affect applications built in other languages (e.g. the .NET Framework).
The summary should probably make this clearer.

Re:Please note that this is C++ only (1)

Tony Hoyle (11698) | about 5 years ago | (#29638265)

Yes it does - if you don't have the correct version of .NET installed your app won't run.

It affects *any* external dependency. It's not unique to the MSVCxx libraries at all.

Re:Please note that this is C++ only (1)

martinmarv (920771) | about 5 years ago | (#29638429)

That's a separate thing entirely. Of course applications built against version "A" of the .NET framework won't run on a machine that doesn't have version "A".

OK, I could be clearer here. There may be .NET assemblies that use Interop to call unmanaged C++ assemblies that could potentially rely on some of the DLLs reference in the article.
However, assemblies that do not rely on C++ DLLs will be fine.

Time to question if DLLs are still needed (2, Insightful)

petes_PoV (912422) | about 5 years ago | (#29638169)

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.

Re:Time to question if DLLs are still needed (1)

QuoteMstr (55051) | about 5 years ago | (#29638289)

problems associated with incompatible versions of libraries.

We'll never get rid of the problem with incompatible libraries until processes stop communicating with each other. What if two processes communicate over a shared memory segment where one version is using a data structure with an extra struct field? What about window message differences, drag-and-drop, and file formats? Sure, static linking might paper over some problems, but it won't free programmers from having to think about backwards compatibility.

Re:Time to question if DLLs are still needed (0)

Anonymous Coward | about 5 years ago | (#29638455)

Now that memory is so cheap and disk space even cheaper, do we still need the small process sizes that dynamic linking brings?

You may not have heard of the new fad sweeping the globe: netbooks with solid state drives. Most of these currently ship with 1GB of RAM, and many have only 16GB of harddisk space.

Re:Time to question if DLLs are still needed (1)

PhrostyMcByte (589271) | about 5 years ago | (#29638539)

DLLs also allow better use of your CPU's cache. You might link one program as pure static and see it not lose speed, or maybe even see it go faster. But if all the programs out there started doing it, I'd be really curious to see if it helped or hurt.

Oh? (1)

QuoteMstr (55051) | about 5 years ago | (#29638207)

I read the linked article [com.com] , and don't see anything exciting. How is this any different from the shared libraries that have been used in the Unix world for 23 years [faqs.org] ? "Private assemblies" can be achieved with rpath or a simple manipulation of LD_LOAD_PATH (see Mozilla). And what does the asymmetric cryptography buy you over simply using the appropriate soname?

Use managed code.. (0)

WarwickRyan (780794) | about 5 years ago | (#29638299)

Honestly there are now very problems which can't be solved more quickly and far more effectively in managed code.

The difference is even bigger when talking multithreaded code. Solving those problems in C/C++ is akin to building single threaded applications in assembly - sure it's faster but the costs to produce bug free code are several orders of magnitude higher with with the modern replacement.

Re:Use managed code.. (4, Insightful)

QuoteMstr (55051) | about 5 years ago | (#29638343)

Honestly there are now very problems which can't be solved more quickly and far more effectively in managed code. The difference is even bigger when talking multithreaded code.

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.

SxS is a fine technology (4, Insightful)

heffrey (229704) | about 5 years ago | (#29638331)

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?

This is why I use Delphi... (1)

SensitiveMale (155605) | about 5 years ago | (#29638353)

Yes, I may be the only one using Delphi, but my apps are self-contained and they run correctly every time.

Nine months. (0)

Anonymous Coward | about 5 years ago | (#29638361)

Summary says this change happened it January. It's October, and you've only now noticed?

Mustn't be impacting too many people.

The solution is easy (according to TFS) (1)

uassholes (1179143) | about 5 years ago | (#29638399)

Just don't use Microsoft Visual Studio 2005. Seriously, just use make. What's the problem?

Re:The solution is easy (according to TFS) (1)

Narmi (161370) | about 5 years ago | (#29638557)

Just don't use Microsoft Visual Studio 2005. Seriously, just use make. What's the problem?

make is not a compiler.

Additional reading (4, Informative)

QuoteMstr (55051) | about 5 years ago | (#29638413)

Everyone (even Windows programmers) should read Ulrich Drepper's piece on how to write shared libraries [slashdot.org] . (Warning: PDF.) (Likewise, even free software developers should read Raymond Chen's blog [msdn.com] .)

dead link (1)

petes_PoV (912422) | about 5 years ago | (#29638545)

hread Ulrich Drepper's piece on [at]http://developers.slashdot.org/people.redhat.com/drepper/dsohowto.pdf ...

404

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?