¿Está MSVCRT bajo Windows como glibc (libc) bajo * nix?

Question

Con frecuencia me encuentro con programas de Windows que se agrupan 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 de tiempo de ejecución de C, algo similar a glibc / libc.so bajo * nix.

¿Por qué los programas de Windows tienen que llevar sus bibliotecas de C con ellos, en lugar de simplemente compartir el libc de todo el sistema?

---

Actualización: gracias a Shog9, comencé a leer sobre SxS, 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 is una introducción útil al problema ...

Answer 1

[Soy el mantenedor actual de la tecnología Native SxS en Microsoft]

Las nuevas versiones de MSVCRT se lanzan con nuevas versiones de Visual Studio y reflejan los cambios en el conjunto de herramientas de C ++. Por lo tanto, los programas compilados con versiones de VS lanzadas después de una versión particular de Windows pueden funcionar en un nivel inferior (como los proyectos de VS 2008 en Windows XP), el MSVCRT es redistribuible, por lo que puede instalarse allí.

La instalación de CRT coloca las bibliotecas en% windir% \ winsxs \, que es una ubicación global del sistema, que requiere privilegios de administrador para hacerlo.

Dado que algunos programas no desean incluir un instalador, o no desean 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.

Answer 2

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, una convención de llamada y una especificación de identificación de nombres bien definidos. Estas cosas suelen venir 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 ciertas cosas pueden esperarse estar allí, y ser nombradas y / o versionadas de tal manera que los programas puedan Encuentra y utiliza 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 propio. Cada compilador proporciona su propio CRT, que puede tener o no las mismas funciones que MSVCRT. Tampoco hay One True Spec sobre las convenciones de llamadas o cómo deberían aparecer los nombres en las bibliotecas, por lo que los 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 un " en todo el sistema " biblioteca 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 probablemente usaron al construir Windows. Otros compiladores podrían posiblemente vincularse con él, pero (1) podría haber problemas de licencia; y (2) los compiladores estarían vinculando su código con los de MS, lo que significa que (2a) ya no tendrían ninguna forma de agregar errores en el tiempo de ejecución o corregirlos, sin esperar que MS los solucione; y (2b) si MS decide cambiar lo que está en la RTL (lo que pueden hacer a voluntad y probablemente tener en cada nueva versión de VC ++), o cómo aparecen los nombres, esos otros programas podrían romperse.

Answer 3

¿Respuesta corta? Porque, hasta SxS, MSVCRT no fue versionado de forma confiable ! ¿Te imaginas la locura que resultaría si los programas compilados y probados contra libc 5 comenzaran a usar libc 6 en silencio? Esa es la situación en la que estuvimos durante muchos años en Windows. La mayoría de nosotros nunca volveríamos a confiar en MS para evitar cambios en una versión

Answer 4

Los programas están vinculados a una versión específica del tiempo de ejecución, y se garantiza que esa versión requerida no está garantizada en la máquina de destino. Además, hacer coincidir versiones solía ser problemático.

En el mundo de Windows, es de muy mala educación esperar que sus usuarios salgan y encuentren e instalen una biblioteca separada para usar su aplicación. Asegúrate de que las dependencias que no forman parte del sistema host están incluidas en tu aplicación.

En el mundo de Linux, esto no siempre es tan simple, ya que hay una variación mucho mayor en cuanto al aspecto del sistema host.