Solución:
Sí, libcmt es (una de varias) implementaciones de la biblioteca estándar de C proporcionada con el compilador de Microsoft. Proporcionan versiones de “depuración” y “liberación” de tres tipos básicos de bibliotecas: de un solo hilo (siempre vinculado estáticamente), multiproceso enlazado estáticamente, y multiproceso enlazado dinámicamente (aunque, dependiendo de la versión del compilador que esté usando, es posible que algunas de ellas no estén presentes).
Entonces, en el nombre “libcmt”, “libc” es el nombre tradicional (más o menos) de la biblioteca C. El “mt” significa “multiproceso”. Una versión de “depuración” tendría una “d” agregada al final, dando “libcmtd”.
En cuanto a las funciones que incluye, el estándar C (parte 7, si le importa) define un conjunto de funciones que debe proporcionar una implementación conforme (alojada). La mayoría de los proveedores (incluido Microsoft) agregan otras funciones por sí mismos (por compatibilidad, para proporcionar capacidades que las funciones estándar no abordan, etc.) En la mayoría de los casos, también contendrá bastantes funciones “internas” que son utilizadas por el compilador pero no normalmente por parte del usuario final.
La biblioteca de tiempo de ejecución es básicamente una colección de las implementaciones de esas funciones en un archivo grande (o algunos archivos grandes, por ejemplo, en UNIX las funciones de punto flotante se almacenan tradicionalmente por separado del resto). Ese archivo grande suele estar en el mismo orden general que un archivo zip, pero sin ninguna compresión, por lo que básicamente son solo algunos archivos pequeños recopilados y almacenados juntos en un archivo más grande. El archivo generalmente contendrá al menos algo de indexación para que sea relativamente rápido / fácil de encontrar y extraer los datos de los archivos internos. Al menos a veces, Microsoft ha utilizado un formato de biblioteca con un índice “extendido” que el vinculador puede usar para encontrar qué funciones se implementan en cuál de los subarchivos, de modo que pueda encontrar y vincular las partes que necesita más rápido (pero eso es puramente una optimización, no un requisito).
Si desea obtener una lista completa de las funciones en “libcmt” (para usar su ejemplo), puede abrir una de las solicitudes de comando de Visual Studio (en “Visual Studio Tools”, normalmente), cambiar al directorio donde estaban sus bibliotecas. instalado y escriba algo como: lib -list libcmt.lib
y generará un (largo) lista de los nombres de todos los archivos objeto de esa biblioteca. Esos no siempre se corresponden directamente a los nombres de las funciones, pero generalmente darán una idea. Si desea ver un archivo de objeto en particular, puede usar lib -extract
para extraer uno de esos archivos de objeto, luego use dumpbin /symbols <object file name>
para encontrar qué función (es) está (n) en ese archivo de objeto en particular.
Al principio, debemos entender qué es una biblioteca en tiempo de ejecución; y piense en lo que podría significar con “Microsoft C Runtime Library”.
ver: http://en.wikipedia.org/wiki/Runtime_library
He publicado la mayor parte del artículo aquí porque podría actualizarse.
Cuando el código fuente de un programa de computadora es traducido al idioma de destino respectivo por un compilador, causaría una ampliación extrema del código del programa si cada comando en el programa y cada llamada a una función incorporada causara la generación in situ. del código de programa respectivo completo en el idioma de destino cada vez. En cambio, el compilador a menudo usa funciones auxiliares específicas del compilador en la biblioteca de tiempo de ejecución que en su mayoría no son accesibles para los programadores de aplicaciones. Dependiendo del fabricante del compilador, la biblioteca en tiempo de ejecución a veces también contendrá la biblioteca estándar del compilador respectivo o estará contenida en ella.
También algunas funciones que se pueden realizar solo (o son más eficientes o precisas) en tiempo de ejecución se implementan en la biblioteca de tiempo de ejecución, por ejemplo, algunos errores lógicos, verificación de límites de matriz, verificación de tipo dinámico, manejo de excepciones y posiblemente funcionalidad de depuración. Por esta razón, algunos errores de programación no se descubren hasta que el programa se prueba en un entorno “en vivo” con datos reales, a pesar de las sofisticadas comprobaciones en tiempo de compilación y las pruebas previas al lanzamiento. En este caso, el usuario final puede encontrar un mensaje de error en tiempo de ejecución.
Por lo general, la biblioteca en tiempo de ejecución realiza muchas funciones al acceder al sistema operativo. Muchos lenguajes de programación tienen funciones integradas que no necesariamente tienen que realizarse en el compilador, pero se pueden implementar en la biblioteca en tiempo de ejecución. Entonces, el límite entre la biblioteca en tiempo de ejecución y la biblioteca estándar depende del fabricante del compilador. Por lo tanto, una biblioteca en tiempo de ejecución siempre es específica del compilador y de la plataforma.
El concepto de biblioteca en tiempo de ejecución no debe confundirse con una biblioteca de programas ordinaria como la creada por un programador de aplicaciones o entregada por un tercero o una biblioteca dinámica, es decir, una biblioteca de programas vinculada en tiempo de ejecución. Por ejemplo, el lenguaje de programación C requiere solo una biblioteca en tiempo de ejecución mínima (comúnmente llamada crt0) pero define una biblioteca estándar grande (llamada biblioteca estándar C) que cada implementación debe entregar.
Me lo pregunté yo mismo y me lastimé el cerebro durante algunas horas. Todavía no encontré nada que realmente haga un punto. Todo el que escribe algo sobre un tema no es capaz de “enseñar”. Si desea enseñarle a alguien, tome el idioma más básico que una persona comprenda, para que no tenga que preocuparse por otros temas cuando maneje un tema. Así que llegué a una conclusión que parece encajar bien en todo este caos.
En el lenguaje de programación C, cada programa comienza con el main()
función. Otros lenguajes pueden definir otras funciones donde se inicia el programa. Pero un procesador no conoce el main()
. Un procesador conoce solo comandos predefinidos, representados por combinaciones de 0
y 1
.
En la programación de microprocesadores, al no tener un sistema operativo subyacente (Microsoft Windows, Linux, MacOS, ..), necesita decirle al procesador explícitamente por dónde empezar configurando el ProgramCounter
(PC) que itera y salta (bucles, llamadas a funciones) dentro de los comandos conocidos por el procesador. Debe saber qué tan grande es la RAM, debe establecer la posición de la pila del programa (variables locales), así como la posición del montón (variables dinámicas) y la ubicación de las variables globales (supongo que se llamaba SSA ?) dentro de la RAM. Un solo procesador solo puede ejecutar un programa a la vez.
Ahí es donde entra en juego el sistema operativo. El sistema operativo en sí es un programa que se ejecuta en el procesador. Un programa que permite la ejecución de código personalizado. Ejecuta varios programas a la vez cambiando entre los códigos de ejecución de los programas (que se cargan en la RAM). Pero el sistema operativo ES UN PROGRAMA, cada programa está escrito de manera diferente. Simplemente poniendo el código de su programa personalizado en la RAM no lo ejecutará, el sistema operativo no lo sabe. Debe llamar a funciones en el sistema operativo que registra su programa, decirle al sistema operativo cuánta memoria necesita el programa, dónde se encuentra el punto de entrada al programa (el main()
función en el caso de C). Y esto es lo que supongo que se encuentra dentro de la biblioteca en tiempo de ejecución, y explica por qué necesita una biblioteca especial para cada sistema operativo, porque estos son solo programas en sí mismos y tienen diferentes funciones para hacer estas cosas.
Esto también explica por qué NO está vinculado dinámicamente en tiempo de ejecución como .dll
archivos son, incluso si se llama una biblioteca RUNTIME. La biblioteca en tiempo de ejecución debe estar vinculada estáticamente, porque es necesaria al inicio de su programa. Runtime Library inyecta / conecta su programa personalizado en / a otro programa (el sistema operativo) en RUNTIME. Esto realmente causa que algunos cerebros f …
Conclusión: RUNTIME Library es un error al nombrar. Puede que no haya habido un .dll
(vinculación en tiempo de ejecución) en los primeros tiempos y el problema de comprender la diferencia simplemente no existía. Pero incluso si esto es cierto, el nombre está mal elegido.
Los mejores nombres para la biblioteca en tiempo de ejecución podrían ser: StartupLibrary / OSEntryLibrary / SystemConnectLibrary / OSConnectLibrary
Espero haberlo hecho bien, listo para corrección / expansión. salud.