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.
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.
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...
Error: password can't contain reverse spelling of ancient Chinese emperor
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.
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.
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.
Someone with knowledge of .NET internals care to comment?
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
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.
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.
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?
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/
I upgraded my Fallout 3 installation yesterday. After patching, the game wouldn't run, returning some fairly obtuse message about import ordinals. 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..
Belief is the currency of delusion.
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
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.
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%.
It does not seem to affect applications built in other languages (e.g. the .NET Framework).
The summary should probably make this clearer.
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
I read the linked article, 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? "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?
On the other hand, pristine Fallout 3 runs perfect on XP...
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.
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?
Yes, I may be the only one using Delphi, but my apps are self-contained and they run correctly every time.
Summary says this change happened it January. It's October, and you've only now noticed?
Mustn't be impacting too many people.
Just don't use Microsoft Visual Studio 2005. Seriously, just use make. What's the problem?
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.
Everyone (even Windows programmers) should read Ulrich Drepper's piece on how to write shared libraries. (Warning: PDF.) (Likewise, even free software developers should read Raymond Chen's blog.)
Actually that was a big problem with the GDI+ library a few years ago. People have even written their own vulnerable DLL scanners for this sort of thing.
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
hread Ulrich Drepper's piece on [at]http://developers.slashdot.org/people.redhat.com/drepper/dsohowto.pdf ...
404
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Back when Microsoft was first out selling .NET, one of the big promotions behind encouraging us to move to .NET was the 'end to .DLL Hell'. After listening to a few sessions at the TechEd event where all these sales pitches where happening, it dawned on me that Microsoft was simply replacing .DLL Hell with what could just as easily become .NET Hell. At the day's closing Q&A session I put up my hand and asked the presenters just that question. They agreed, but added, "trust us, we've learned our lessons with .DLL Hell and won't do it with .NET". Obviously the lesson wasn't fully learned!
Oh, they decided to uninstall the service pack? What could possibly go wrong? Let's check the security bulletin!
Maximum Security Impact = Remote Code Execution
Your customers must love you guys!
Slightly more on topic, if it's totally impossible to distribute any kind of installer with their product, they should just link to the libraries statically. No luck required!
Not with a .local file.
The revolution will not be televised... but it will have a page on Wikipedia
not having programmed for Windows for many years now what happens when these different versions of library C use different data structures or global variables?
The advantage of dynamic libraries is that a single patch will fix every application that uses it. In your scenario, say that you find a major security hole in x.dll. In order to patch it, you'd now have to find every program that includes x.dll and update it.
Take for instance, the CryptoAPI hole mentioned here. If they didn't use the shared library, IE, Safari, and Chrome would each need to release their own updates to fix this problem. Now, we just need to wait for Microsoft to release a single patch and everything is fixed.
It also would dramatically increase the size of the OS- the same file would have to be on the computer lots of times. That's usually considered a bad thing.
Installed Visual C++ 2008 Express not too long ago, wrote some code, compiled for debugging, so far, so good. Next step was to run the damned thing, this worked for a while, then mysteriously failed because it could no longer find its own stupid runtime DLLs.
Actually, this was really easy to solve, All I had to do was disable incremental linking, which should have been obvious to just about anyone
Links for the skeptic,
Sometimes it is a good thing to use your own DLLs. I'm writing a mod tool for a game at the moment, and I am using Qt4 to provide the graphics. Qt4 on Windows by default is compiled with MinGW, but I compiled mine with Visual Studio. If I had the Qt4 DLLs in the system directory, it probably would cause issues for any other Qt4 using program that might use those particular DLLs. To be on the safe side, I kept the DLLs in the directory of the program.
SSC
...why did we ever move away from statically linked binaries?
I wonder if everybody has looked at using static linking + content addressable filesystem as a replacement for DLLs. Every app would ship with all required libraries linked statically and the elimination of duplicated data would be handled by the filesystem and memory management code so that you don't waste disk / RAM. If you used a suitable protocol you could even save on bandwidth by not downloading file blocks that you already have somewhere on your disk, so the increased executable size would become less of a problem.
because it still doesn't work - I tried that to solve one problem with this update.
Loading dlls now requires manifest files which bind your app to a particular dll version (via some sort of guid), so once you've rebuilt your app, you have to ship the .4053 version of the CRT, ATL and MFC updates to your app's local directory. You might as well install them to the SxS dir, if you have to install them manually anyway.
They just replaced dll hell (which I never suffered from in all my 15 years of windows development) for manifest hell (which I've suffered from 3 times now). MS used to keep things very backward compatible (users may not have been so conscientious, but whenever I've rebuilt an app I rebuild all my user libs too so I don't have to bother being so careful, but MS used to do a good job so the CRT libs were never a problem).
You'll find the same issue will affect you, you'll see it if you try to build using (say) .NET with a service pack, but the user doesn't have that update installed. Its only a poorly documented patch that doesn't have the redist package on WU yet, which is why this is such a problem.
Content addressable systems are a bad idea: consider hash collisions. In normal use, hash collisions are extremely unlikely. However, with billions upon billions of data blocks being checked by hash, the odds of a collision go up drastically, and you end up getting the wrong data. Occasional data corruption is never acceptable for conventional filesystems, so why should it be acceptable for content-addressable ones?
I hate to break it to you, but there is quite a lot of this going on. For instance, if you were to look at the source code of every app that needs to decode png files (just as example), you would probably find only about 50% use the libraries that come with the OS, and the reasons why vary:
* avoiding dll hell (as mentioned)
* the app is cross platform
* poor implementation of official dlls
* politics (at one stage Microsoft made tied certain dlls to the installation of IE, even though they had nothing to do with browser functionality)
I can't believe that the one post that gets it is an AC. Someone please mod him up!
This whole situation is a complete non-issue. Some amateur coder had a bug and made a blog post about it, big deal.
One of the earlier things I learned in this profession (yes I write code for a living): as a normal developer, it is very very rare that you will stumble on a bug or design flaw in your OS or compiler of choice. Now I'm not saying it doesn't happen, but the correct gut reaction is to suspect your stuff, not blame your OS/compiler/tools/vendor.
To the AC: you should really register!
gcc: no input sig
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.
Does this explain why Audio Surf suddenly pops up roughly a dozen Visual C++ Runtime Error messages before actually starting? I thought it was the latest update to Audio Surf that was causing it, but it could very well be this...
It's about time
It's about space
About strange people in the strangest place
It's about time
It's about flight
Travelin' faster than the speed of light
About space people and a brave crew
As through the barrier of time they flew
Pass the Roman Senators
Pass an armored knight
Pass the firing Minutemen
To this modern site
It's about time for you and me
To meet these people of amazing feats
It's about two astronauts and how they educate
A pre-historic woman and her pre-historic mate
It's about time
It's about space
About strange people in the strangest place
They will be here
With all of us
Dodging a taxi a car a bus
Where will they go
What will they do
In this strange place where everything is new
Will they manage to survive
Watch each week and see
Will they get accustomed to the Twentieth Century
It's about time
For our good byes
To all our pre-historic gals and guys
And now ...
It's About Time
Time to load is dimiinished because often the DLL is already loaded /MD so DLLs will be used by most (because they know no better).
Spaec since you only need one code to be loaded (data is always separate, unless shared segment)
In summary, static linking is better today, but the default is to use
go into any open source app. chances are quite good they have just listed a huge piece of the source tree of sublibrary xyz version pdq and dropped it into their project. why? because they are sick of the library not being available or being the wrong version. not only for running, but for compiling... and getting other people to be able to work on the project with them.
another 'interesting' example is firefox, which has its own , basically, everything, from a string library on it (of course.. in the old days,, it actually had --two string classes--.
I just ran into this at work last week. I'm glad it's finally making the tech sites!!
... 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. ...
Isn't the definition of "undocumented" not documented? And therefore, it shouldn't be used, as the providers don't guarantee that it won't be changed. You can't blame Microsoft for developers using undocumented functions: that was the point!
First off, why on earth is the developer still using Visual Studio 2005? We're on Visual Studio 2008, SP1. That, right there, raises a red flag. If someone compiled something with an ancient version of gcc and found out it didn't work, when distributed, on more up to date Linux distributions, wouldn't you think that the appropriate response would be for our man to get his tools straightened out first?
I would think that if the author shipped his system with a copy of the runtimes and had them install in his application directory, he would have no problem at all. The Windows DLL load order is application directory first, then, some other stuff, so his application should always have the right libraries, if he shipped them. In fact, I even think there's some sort of a doohickey that you can do to have Windows look for COM components first in your own directory before it looks for them in common areas. There's no need to have "DLL hell" at all, unless the developer really asks for it.
Frankly, I doubt DLLs of the relatively small size of the CRT should even be used any more across different applications from different vendors.
1. First, you cannot possibly test your application with all the different versions and patch versions of DLLs that are out there, because patch releases now are way too fast. Reliability, right now, not performance, is the pre-eminent problem in the software community.
2. The static linker is now actually capable of removing unused code, from an image, it could not do that before.
3. DLLs have to be relocated when an application loads them into its own process space, so you take a performance hit there.
4. The Windows API has 95% of what you would need the C runtime to do. This isn't like Linux, where, you would die without libc trying to make heads or tales of syscalls and what not. On Windows, I struggle to think of a CRT call that could not be done nearly as simply as in SDK directly. For files there's CreateFile, WriteFile, etc. All of the basic string functions exist within the SDK, and the stuff to display formatted strings in the SDK is better than what the CRT gives you anyway. It's a bit more involved, but, there's articles out there on how to not have a CRT at all. In fact, applications that use the ATL and WTL frameworks even support not having the CRT code, just so you can write really, really tiny applications and gasp, COM components.
This is my sig.
Side-by-side assemblies are not static linking. Quite the opposite, they allow dynamic linking of multiple versions of the same DLL. In other words, only one copy of the old libraries exists, and they are most definitely not in the binary.
Who said, "Sit down!"?
This isn't an issue looking for a fix. The answer is to install the latest VC5 redist when you install the new build of your software. It's backwardly compatible with the previous version, and fixes the massive security hole. The person who posted this story is totally missing the point and making a mountain out of a mole hill. The real issue is that people aren't patching their computers.
...I have yet to see and DLL hell or dependency hell.
I'm by far no Gentoo fanboy, but I think the slotting works very nicely. I even have KDE 3.5.10 and 4.3.1 side-by-side without problems.
I wonder why they don't just create a ports/portage/paludis-like clone for windows...
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Sounds like a lot of "waah" to me - user installs updated security fix from windows update, problem solved? I see this is a good thing as you'll need to get those shitty old insecure copies of the DLLs up to date?
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
My problem with SxS is that the winsxs is taking up 12GB on my 80GB SSD with no easy way to move it.
http://blog.slaingod.com
It's interesting that the bulk of the SxS stuff is Microsoft stuff, not third party stuff.
I recall that when Win95 first came out, and that they were replacing the Win16 stuff with Win32 stuff. Someone remarked that there would be incompatibilities, and that it was for the vendor to rewrite the apps to meet the new APIs. That calling some DLL by name would of course these incompatibilities.
I thought how silly. Inviting third parties to use routines in your DLL is pretty much a kind of contract of support. This is the nature of the operating system, really. If you create a DLL like VBRUN100 for some set of apps to call, then the App expects it to run in that way, and if your new version of VBRUN would cause incompatibility, you should give it a different name, like VBRUN200.
Last time i looked, routines like VBRUN100, BWCC etc, comes to about 9 MB. (There's a download that ye can add to your OS to give these as preinstalled.
Where the problem comes is when some sort of obvious name gets used for different DLLs (eg the three different versions of THREED.VXD that different applications were loading under Win31), or the MFC3xx DLLs where the source code was given to vendors to allow them to add their own functions. (good lord). Even so, Microsoft continues to release DLLs like MSVCRT and MFC40, updated to their latest operating system / compiler.
I don't think anyone else uses such nonsense as SxS or DLL hell: OS/2 VREXX.DLL or EMXRT do the right thing: preserve existing functions, and have a test for version-level.
OS/2 - because choice is a terrible thing to waste.
I really love having to edit various _PATH environment variables and make a thousand symlinks whenever an application doesn't specify exactly which version it wants, since nothing is automatically detected and "simple" means "complete lack of standardization, so it's impossible to determine what is actually desired"
Here's a crazy idea:
- digital signatures are a good thing
- precedence by PATH order was always a stupid idea.
Why the hell do we need to tell anything WHERE to look nowadays, instead of saying --require-compatible-with=SOMEKEY?
In reading this post, I'm trying to understand what is being complained about. In my understanding of the situation, having handled this update for my employer's projects, this is what happens:
You release version 1.0 of a product using VC 2005 SP1 before the update. Version 1.0 therefore depends on version 762 of the DLL.
You install the security update on your build machine.
You release version 1.1 of your product as an update. Version 1.1 depends on version 4053 of the DLL because it was compiled on a build machine with the security update installed.
Your customers install version 1.1 of your product without installing the runtime update from Microsoft.
The program doesn't start because customers don't have the version that 1.1 depends on, 4053.
The same thing occurred when SP1 was released, yet there weren't many complaints then. I think it's more of a lack of education on how this DLL versioning stuff works. It was widespread knowledge that SP1-compiled programs needed a newer runtime. My employer's product doesn't even embed the DLL installer (vcredist_x64.exe); instead, we just dump the raw files and .manifest file into the application's local directory. Interestingly, even though the 762 DLLs are in that local directory, Windows will automatically load 4053 from the WinSxS directory if you have the security update installed.
The moral of the story is if you install the update on your build server, you need to have your customers update as well. Do the right thing and have your update program install it for them, or alternatively shove the files into the local application directory for the same effect.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Microsoft's fault that people use undocumented features that then later change?
Interesting logic.
Ever thought Microsoft had good reason to keep them undocumented, like, you know, that they knew they were going to have to change them later on? Fair play if something is wrong with the documented APIs, but it's hardly Micrososft's fault if someone uses an undocumented API and it gets changed.
Contrary to popular belief, Microsoft don't refuse to publicly document some of their APIs to be dicks. They do it because it costs them money to ensure documentation is fit for the public, because it requires that they are confident the API is stable and will not be changed, but most importantly in the last case, because it can take time and lots of money and lead to delays in releases to get those APIs in a stable fit for public state. If doing that offers them little benefit financially because only a fringe few developers need those hidden features why delay their operating system releases costing them millions and hence up the costs for everyone else?
If an application relies on undocumented APIs it's an application I would not want on my network because it's clearly badly written. People who write this type of software tell us there's no other way to do what they want, but that's always bollocks because there is, you can even use the well documented device driver API if you want to create virtual devices and that sort of thing.
That's the reason for the existence of the virtual store in Vista/7. The problem is that some apps write data to their directory in program files. They were never supposed to since like Windows 2000, but they do. Those of us that administer Windows in a domain setting where people have limited user accounts encountered the problem long ago. Ok well the new security model makes everyone a limited user via UAC. That breaks apps. So MS had two choices:
1) Break lots of apps. Require users to know how to change permissions on directories to fix it. That would never happen, users would instead turn off UAC and declare that "MS broke my software."
2) Add a compatibility feature, so that apps would think they were writing to their directory, but file security was maintained transparent to the user. That is what they did.
Also OSS has plenty of bad programmers. Library hell can be way worse than DLL hell ever was. Recently one of my coworkers was installing a program for our Linux systems. It's installer bombed out on needing a certain version or greater of a library that it didn't include and wouldn't go get. So my friend goes and gets the new version from the site. No love, thing still bombs. So he goes and tracks down the specific version it asks for, which wasn't easy. Still no love. He goes and looks in the make file and finds out that the check is broken, it'll never install no matter what version he has. So he just disables that and goes on to install the program (there were other problems as well).
That is not a better situation. While MS's solution might take up more disk and memory, those things are cheap. You can get 8GB of RAM for $130, a 1TB drive for $90. As such it doesn't matter, if it makes computers easier to use for the average user, it is a better idea even if it takes some more resources because resources are cheap.
As you've said, there are lots of stupid programmers. Windows has them, and Linux has them (and people who don't think Linux does may themselves be stupid programmers). It is a fact of life we have to deal with and I do not see it changing. As such, OSes should do what they can to deal with it.
...the real problem is that Microsoft failed to include the CRT and MFC updates for machines that do not have the development environment installed. So all of our customers that faithfully use Windows update got only the .NET patch instead of all three parts of this release. That "breaks" the software we non.NET developers deliver and that happened without any significant notice to the developers. We get things labeled "security patch" all the time, so many that few of us read all of the details any longer.
I believe that Microsoft could have included a one time message in the Visual Studio patch that opened a message box the next time the IDE (or just the compiler/linker) was run that explained that the redistributables had been changed and would be required for any customer using software compiled after the message box was displayed. SOMETHING would've certainly been better than NOTHING to inform developers of the change clearly, without any ambiguity. Especially for anyone who allows Windows to automatically update while they're asleep (something Microsoft recommends)!
While the side-by-side system is a PITA, it isn't the actual culprit here. The primary issue is Microsoft's failure to adequately inform developers of a change that will significantly impact the software being built with their products.
http://en.wikipedia.org/wiki/Trusted_Computing#Possible_applications
Hands up anyone who knows what an "activation context" is! If you don't you have no idea what WinSxS does, how it does it or how to diagnose it when it goes wrong.
In my opinion, WinSxS is a good mechanism, or at least as good as Microsoft could have made it while working within the constraints of history. However, WinSxS cannot be used in the real world without properly understanding it, and achieving that understanding is very painful indeed. The MSDN documentation is piecemeal, appears incomplete and inaccurate in a few places and lacks a proper overview. I think the only reason I properly twigged what activation contexts are about is that I had recently written a mechanism that operated on similar principles (a thread-local stack of context-related information).
I wrote a Wiki page at work describing what (I think) WinSxS's motivation is, how it works and some of the problems it suffers from. I'd like to put it somewhere on the public internet - any suggestions? It should ideally be somewhere wiki-like where people can correct its inevitable inaccuracies without me having to maintain it, but I'm not sure it's appropriate for wikipedia.
"The Milliard Gargantubrain? A mere abacus - mention it not."
I really don't see what's wrong with just putting a interface version in the filename. It's simple and clear.
;-)
Change the version part of the name of the DLL if you are changing the interface. If you are not changing the interface, you want applications to use the updated DLL.
I really don't like the manifest. It seams to me an attempt to prevent programmers doing stupid things, but by stopping people doing stupid things, you stop them doing smart things too. Also, who want stupid programmers!?
I really should do some research first, but let me see.
The public key signatures are in bundled (as in bundled but separate from) files.
Okay.
Unbundle. Patch the binary. sign it with a key stolen from a lax developer somewhere who happened to load a porn reader that happened to contain a little eavesdropper on an older machine and then used that machine to sign his own work. (If you're only a little bit lucky, it was a Microsoft internal developer that did that.)
Bundle.
Most users are not going to know the difference. They'll see your "Click me if you believe in fairies!" dialog and click, and you're in.
And that's doing things the hard way, to cover your tracks a little more carefully.
Dependencies?
You can't manage versions that way. It doesn't work unless almost all your apps are from a very small number of sources. I mean, small, as in Microsoft plus two, maybe three others.
There's a graph parsing problem in here that just gets way out of control when you have signatures from very many sources.
So, no. Microsoft fails yet again, and this time Moore is no longer going to be able to bring the cavalry over the horizon. Maybe, I suppose, if you have an eight processor box and devote 7 of the processors to untangling the dependencies and checking the signatures, but then there are the race conditions.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
every time microsoft pulls some shit, there are fanbois who are defending them as if there is no tomorrow. but still, i wonder if there is any 'side by side' fanboi left to defend them after all the incompetency and stunts they pulled in the last year.
Read radical news here
microsoft: 2004 called and we want our IDE back.
translation: buy a new one?
room101 -- how much can you stand before they break you?
(they always break you eventually)
I guarantee you the latest VC5 redist isn't fully backwards compatible. Specifically, it is not bug for bug compatible and some software relies on bugs in earlier versions. Why do you think wine developers are having so many problems?
What is so special about Brainfuck anyway?
Yes, a Brainfuck program looks weird, but the language is so simple that any (somewhat competent) programmer can understand it completely after 5 minutes of research.
It's kind of somewhat interesting, I guess, in that it's a fairly Turing Machine-ish language. You have the current memory location, which can be incremented or decremented, and a very small set of operations you can perform on the value stored there (increment or decrement, zero-test with conditional branch, input, output) The set of operations is simple enough to understand - but actually putting them to use would be a challenge. I can sort of vaguely see the appeal here - the language itself is like a puzzle.
At the same time - I can never quite shake the feeling that these "Esoteric" programming languages are just complete junk... Like someone decided obfuscated C wasn't sufficient for their needs, so they created a language that could give them new and exciting ways to make programs hard to write and read... I could sort of envision the process of writing something vaguely complicated in Brainfuck - building up bits of functionality out of the barest instruction set and assembling it into a program with the annoyingly limited set of flow control operators - but I can't think of why I would want to do that. If I took on a somewhat similar challenge by, say, writing PIC assembly code - I'd be starting from a better instruction set but still have a lot of work to do in order to create something useful - but the difference is, at the end, my program would be useful... It's like, have I got so much time on my hands that I need programming to be more difficult for no good reason? Couldn't I be doing something more interesting with my time than writing really simple programs in a language that makes these simple ideas almost impossible to express?
Bow-ties are cool.
Brainfuck, whitespace, etc? These are all jokes. You're never intended to use them at all.
As jokes, they're not especially funny. So I guess whether you regard them as jokes or as programming languages, they're equally worthless.
So pack up that "whoosh" shit and fuck off.
Bow-ties are cool.
the patch actually came out at the end of July, not in January. And the workaround that is mentioned in his blog post (missing a URL link) that Ted authored is here:
http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
What's the difference if it's 1000 SxS bytes or 1000 static bytes?
At one point they merge into one, especially when a system like SxS seems to promote sloppy programming, and the creation of thousands of variations.
I've personally witnessed people buying brand-new Vista-laptops, and their winsxs partition expanded to 15-20 GBs, rendering just a tiny part of the 40 GB harddrive for music and video. These were not technical inclined people, but when told about this "feature" eating up their precious harddrive space all the time, they wanted XP (Vista seems to be gobbling ALL computer resources - SxS and harddrive space just being one of the issues). (Of course XP would not install on their machine by default - having Sata-drives and all - they had tried)
And yes, they had tried reinstalling Vista a couple of times.. It only worked for a few months, then space became an issue again because Vista was using the most of it..! And it's not like you can delete ANY of those SxS files, even if they're never in use anymore. You never know when they might come in use, and crash the OS if they're missing.. It's supposed to clean up after a while, but doesn't seem to function as well in Vista as in XP for some reason. Probably because of "improvements" in the code. Bah
The main thing is that users sees this. They'll just say: My XP worked fine with a 20 GB harddrive, and Vista can barely function with double that!
Too bad shitty PC laptop manufacturers like Dell doesn't support XP, leaving you with scouring the web for half-broken drivers for your "shiny new" laptop which is now crippled beyond imagination. What kind of companies treat their customers like this? Not a company I will ever buy from - or recommend ever again.
At least I could turn my Vista-Dell laptop into a XP one, with only minor glitches in the sound driver and other useless driver not working. But any sane person not wanting to waste days on such endeavour would just give up!
And yes, I know Vista can be made more responsive. Turn off aero. Turn off all useless services. I did ALL that, and almost got Vista "working" sanely. You can't really turn off all the duplicate / "spammy" options in every explorer dialog - worst idea ever to spam users with duplicate choices, instead of just cleaning up all the configs once and for all. But I can live with poor user design, after all, every computer interface is littered with it, or by commercials, even today. But SxS was the "killer feature" that finally made me install XP on a Vista Dell-laptop, and I'm not proud of the result..
But by all means, lecture us about dynamic linking being the final answer to everything. I'll just continue to use most of my programs as PORTABLE binaries whenever I can find them, thank you! Getting a new machine is as simple as copying a whole subdirectory, and voila, emails, browsing, all my settings, all the way I left it on the other machine, contained in just one directory structure named after the person who it belongs to - simple.
Of course, I have to spend a little time installing the last junk that is not portable, and configuring the drooling retarded defaults in Windows, but after lots of practice it's almost getting funny... And since I'm using less and less of the "OS" (IE is NOT part of the OS although its libraries are), every year, there's really less for me to configure.
So all in all, if something is static, I might even buy it. And that's coming from someone who love the idea of dynamic linking, but hate reinstalling, configuring, personalizing everything every time I move between systems. And no, I just want simple directories to copy / backup, no automagic wizards "helping me" move to another system. Especially the "OS" I want as little to do as possible. I don't even want "My Documents", because you never know what programs will do to those directories or what they'll be named next.
"OS" as a platform is overrated in my opinion while Portable Apps are getting better and better. I havent tried Windows7 but I doubt they're moving completely in the right direction, although it is probably an improvement.
KISS and goodbye!