Jean-Marc Lasgouttes wrote: >> Completely infeasible on Windows. The loss of shared text would make >> the working set of the typical application mix grossly exceed even the >> absurd amounts of RAM available in typical machines today. The disk >> space problem would be even worse. > > I meant just for application which feel that they have to distribute > their own version-of-the-day > of whatever.dll. There is no reason to do it everywhere of course.
Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. For someone else to run that binary, they need that exact same version of the MSVC DLLs. In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. Microsoft's solution is for every application linked against any MSVC DLL to include the redistributable DLL package for that specific MSVC version as part of their installer package. So it's not the application developers who want you to install a dozen versions of the MSVC runtime. They don't know what versions you already have installed. There's no way to coordinate versions among unrelated applications. People build and distribute binaries, and they carry with them MSVC version requirements. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
