Whatever MSVC runtime does is completely irrelevant to what Windows supports.
Well it is supported or else some applications would break. What is interesting is the reason it is discontinued: The Side by Side Assembly folder is enormous, and the more applications that are installed the bigger it get's. A central system is supposed to minimize the size because libraries are not duplicated. Which kind of went against the purpose.
Since you want "citations" so often:
http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspxFrom that site:
So yes, the WinSXS folder is very large, and it will continue to grow as the OS ages. I hope that this clears up some of the questions about why that is, and what you can do about it. Note that the Windows servicing structure and the layout of the store is subject to change.
Joseph Conway
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support
Ah, now I understand, it's generic Windows bashing! Windows uses names so it's bad, Linux uses names so it's good. Logic got pwned. But seriously, could you expand on that?
Dude seriously relax! I can promise you that this is not generic Windows Bashing, my favorite IDE is VS2010 and I do all my programming in Windows which makes me pretty aware of it's shortcomings. You have to accept, Windows is not perfect. Is it so impossible to grasp that Microsoft can do stuff wrong? They are human aren't they?
It is quite different when it comes to names between Windows and Linux. Linux complements names by symbolic linking meaning a file have several names. So for instance if we take SFML as an example we can have ALL versions of SFML installed on a single machine and any application using any version of SFML can be run without the developer or user raising a finger.
I'll give a basic example leaving out details on how it works using a case where several versions of sfml is installed on the same machine:
libsfml-xxx.a -> libsfml-xxx.a.2
libsfml-xxx.a.1 -> libsfml-xxx.a.1.6
libsfml-xxx.a.1.5
libsfml-xxx.a.1.6
libsfml-xxx.a.2 -> libsfml-xxx.a.2.0
libsfml-xxx.a.2.0
So if we link against sfml-xxx then libsfml-xxx.a.2.0 is used. So when we run the application on any machine it will look for the shared library called libsfml-xxx.so.2.0 instead of libsfml-xxx.so but still let's any other application using 1.5 or 1.6 still to be run. Which solves the first problem with DLL hell(which I want to note only Windows have and no other operating system). Next comes that there is no central place for shared libraries to be placed.
Again, [citation needed].
I can't give you one since Windows lack a common place to put them. It's quite hard to give you something that does not exist. Or you want a citation of someone saying that it does not have a common place to put it? Just google "Where to put my DLL"
If I remember correctly, the "right" way to do it in Windows is to register the DLL in the registry? Or is it add your folder to the PATH variable?
Either way it's more complicated than Linux version that is simply "Put it in this folder and you are done".
Anyway, if Linux is so good at managing shared objects, consider this: I've built some code using distro A with some library version X. Someone wants to run my code on distro B with version Y of that library. There were major breaking changes between X and Y. On both distros this is the most current version available. Now what?
Simple it starts using version X if it is installed otherwise it will just state that the some library with version X was not found. I pretty much covered that in my previous paragraphs. Seriously are you trying to take up an argument without knowing anything about the opponent?
You should just drop this already before any name-calling is starting. You don't have to prove that I am wrong if you think you are right. As long as it works for you. Then if somebody asks how to properly share DLL's on Windows you can just poke in and say "Side-By-Side Assembly" or whatever instead of hijacking the thread when someone else gives a suggestion you yourself don't like.
