¿MSVCRT está bajo Windows como glibc(libc) bajo*nix?
(4)
Con frecuencia encuentro programas de Windows que combinan en MSVCRT (o sus equivalentes más actuales) con los ejecutables del programa. En una PC típica, encontraría muchas copias de los mismos .DLL. Tengo entendido que MSVCRT es la biblioteca C runtime, en cierto modo análoga a glibc / libc.so bajo * nix.
¿Por qué los programas de Windows deben llevar consigo sus bibliotecas C, en lugar de compartir la libc de todo el sistema?
Actualización: gracias a Shog9, comencé a leer sobre SxS, lo que me abrió los ojos a los problemas de vinculación de DLL (DLL Hell) - http://blogs.msdn.com/b/martynl/archive/2005/10/ 13 / 480880.aspx es una introducción útil al problema ...
¿Respuesta corta? ¡Porque, hasta SxS, MSVCRT no fue versionado de manera confiable ! ¿Puedes imaginar la locura que resultaría si los programas compilados y probados contra libc 5 comenzaran silenciosamente a usar libc 6? Esa es la situación en la que estábamos por muchos años en Windows. La mayoría de nosotros preferiría nunca más confiar nuevamente en MS con los cambios de última hora en una versión
Los programas están vinculados con una versión específica del tiempo de ejecución y no se garantiza que exista esa versión en la máquina de destino. Además, las versiones coincidentes solían ser problemáticas.
En el mundo de Windows, es de muy mala educación esperar que los usuarios salgan y encuentren e instalen una biblioteca separada para usar su aplicación. Asegúrese de que cualquier dependencia que no forme parte del sistema host esté incluida con su aplicación.
En el mundo de Linux esto no siempre es tan simple, ya que hay una variación mucho más grande de cómo se verá el sistema host.
[Soy el actual mantenedor de la tecnología Native SxS en Microsoft]
Se lanzan nuevas versiones de MSVCRT con nuevas versiones de Visual Studio y reflejan los cambios en el conjunto de herramientas de C ++. Para que los programas compilados con versiones de VS lanzadas después de que una versión particular de Windows continúe puedan funcionar en niveles más bajos (como los proyectos de VS 2008 en Windows XP), el MSVCRT es redistribuible, por lo que se puede instalar allí.
La instalación de CRT deja las librerías en% windir% / winsxs /, que es una ubicación global del sistema, que requiere privilegios de administrador para hacerlo.
Como algunos programas no desean enviar un instalador, o no quieren que el usuario necesite privilegios de administrador en la máquina para ejecutar su instalador, agrupan el CRT directamente en el mismo directorio que la aplicación, para uso privado. Entonces, en una máquina típica, encontrará muchos programas que han optado por esta solución.
Realmente no hay una "libc de todo el sistema" en Windows.
En * nix, generalmente hay un compilador, un enlazador y, con ellos, un formato de archivo de objeto bien definido, una convención de llamadas y una especificación de cambio de nombre. Esto generalmente viene con el sistema operativo. El estado semi especial del compilador (más un énfasis en la portabilidad a través de diferentes * nixes) significa que se puede esperar que haya ciertas cosas allí, que se nombren y / o se versionen de forma tal que los programas puedan encontrarlo y usarlo fácilmente.
En Windows, las cosas están más fragmentadas. Un compilador no viene con el sistema operativo, por lo que la gente necesita obtener el suyo. Cada compilador proporciona su propio CRT, que puede tener o no las mismas funciones que MSVCRT. Tampoco existe una especificación única sobre las convenciones de llamadas o cómo deberían aparecer los nombres en las bibliotecas, por lo que diferentes compiladores (con diferentes formas de hacer las cosas) podrían tener problemas para encontrar funciones en la biblioteca.
Por cierto, el nombre debería ser una pista aquí; MSVCRT es la abreviatura de "MicroSoft Visual C ++ RunTime". No es realmente una biblioteca de "todo el sistema" de la misma manera que, por ejemplo, kernel32 es, es solo la biblioteca de tiempo de ejecución utilizada por los compiladores de MS, que presumiblemente usaron al construir Windows. Otros compiladores podrían vincularse, pero (1) podría haber problemas de licencia; y (2) los compiladores vincularían su código a los de MS, lo que significa que (2a) ya no tendrían forma de agregarlos al tiempo de ejecución o corregir errores, salvo por la esperanza de que MS los solucione; y (2b) si MS decide cambiar lo que está en la RTL (que pueden hacer a voluntad, y probablemente lo tengan en cada versión nueva de VC ++), o cómo aparecen los nombres, esos otros programas podrían romperse.