Windows aún usa DLLs y parece que los programas Mac no usan DLL en absoluto. ¿Hay beneficios o desventajas de usar cualquiera de estas técnicas?¿Cuáles son los pros y los contras de usar una DLL?
Si la instalación de un programa incluye toda la DLL que requiere para que funcione al 100%, ¿será lo mismo que vincular estáticamente todas las bibliotecas?
MacOS X, al igual que otros sabores de Unix, utiliza bibliotecas compartidas, que son solo otra forma de DLL.
Y sí, ambos son ventajosos ya que la DLL o el código de la biblioteca compartida se pueden compartir entre múltiples procesos. Lo hace mediante el sistema operativo cargando la DLL o la biblioteca compartida y asignándola al espacio de direcciones virtuales de los procesos que la utilizan.
cómo es que los programas mac usualmente son tan grande, como 27 MB o incluso 106 MB? –
@Jian Lin - grande en comparación con qué? –
@Russ muchas veces, el EXE de Windows es muy pequeño, como 5 MB o 16 MB. –
En Windows, debe utilizar bibliotecas cargadas dinámicamente porque las bibliotecas GDI y USER solo están disponibles como DLL. No puede vincular ninguno de ellos ni hablar con ellos utilizando un protocolo que no involucre carga dinámica.
En otros sistemas operativos, desea utilizar la carga dinámica de todos modos para aplicaciones complejas; de lo contrario, su binario se hincharía sin una buena razón y aumentaría la probabilidad de que su aplicación fuera incompatible con el sistema a largo plazo. a corto plazo, la vinculación estática puede protegerlo de los pequeños cambios que se producen en las bibliotecas). Y no puede enlazar en bibliotecas propietarias en sistemas operativos que dependen de ellos.
Windows aún usan DLL y Mac parece que los programas no usan DLL en absoluto. ¿Son beneficios o desventajas de usando cualquiera de estas técnicas?
Cualquier tipo de modularización es buena, ya que facilita la actualización del software, es decir, no es necesario actualizar todo el programa binario si se soluciona un error en el programa. Si el error aparece en alguna dll, solo el dll necesita ser actualizado.
El único inconveniente con esto es que introduce otra complejidad en el desarrollo del programa, p. Si un archivo DLL es una C o C++ DLL, diferentes convenciones de llamada etc.
Si una instalación del programa incluye la DLL que requiere, será la mismos como estáticamente que unen todas las bibliotecas ?
Más o menos si. Depende de si está llamando a funciones en un dll con el que supondrá un enlace estático. El dll podría ser una biblioteca dinámica "libre", a la que solo se puede acceder a través de LoadLibrary() y GetProcAddress() etc.
Una gran ventaja de las bibliotecas compartidas (DLL en Windows o .so en Unix) es que puedes reconstruir la biblioteca y sus consumidores por separado, mientras que con las bibliotecas estáticas tienes que reconstruir la biblioteca y volver a vincular a todos los consumidores, lo que es muy lento en los sistemas Unix y no muy rápido en Windows.
El software MacOS también usa "dll's", solo reciben un nombre diferente (bibliotecas compartidas).
Dll tiene sentido si tiene código que desea reutilizar en diferentes componentes de su software. En general, esto tiene sentido en grandes proyectos de software.
La vinculación estática tiene sentido para aplicaciones pequeñas de un solo componente, cuando no hay necesidad de volver a usar el código. Simplifica la distribución ya que su componente no tiene dependencias externas.
Sí, ver esto text:
La vinculación dinámica tiene las siguientes ventajas :
ahorra memoria y reduce intercambio. Muchos procesos pueden usar una única DLL simultáneamente, compartiendo una sola copia de la DLL en la memoria . Por el contrario, Windows debe cargar una copia del código de la biblioteca en la memoria para cada aplicación que se haya creado con una biblioteca de enlaces estáticos.
Guarda espacio en disco. Muchas aplicaciones pueden compartir una sola copia de la DLL en el disco . Por el contrario, cada aplicación construida con una biblioteca de enlace estático tiene el código de la biblioteca vinculado en su imagen ejecutable como una copia separada .
Las actualizaciones a la DLL son más fáciles. Cuando las funciones en una DLL cambian, las aplicaciones que las usan no necesitan volver a compilarse o volver a vincularse siempre que los argumentos de la función y los valores devueltos no cambien . Por el contrario, el código de objeto enlazado estáticamente requiere que la aplicación se vuelva a vincular cuando cambien las funciones .
Proporciona asistencia postventa. Por ejemplo, una DLL de controlador de pantalla se puede modificar a para admitir una pantalla que no era disponible cuando se envió la aplicación .
Admite programas de varios idiomas. Los programas escritos en diferentes lenguajes de programación pueden llamar a la misma función DLL siempre y cuando los programas siguen la convención de llamadas de la función. Los programas y la función DLL deben ser compatibles en las siguientes maneras: el orden en que la función espera que sus argumentos a se insertan en la pila, si la función o la aplicación es responsable de la limpieza de la pila, y si se pasan los argumentos en los registros.
Proporciona un mecanismo para extender las clases de biblioteca MFC. Usted puede derivar clases de las clases existentes de MFC y colocarlas en una DLL de extensión de MFC para su uso por las aplicaciones MFC .
Alivia la creación de versiones internacionales. Al colocar recursos en una DLL, es mucho más fácil para crear versiones internacionales de una aplicación . Puede colocar las cadenas para cada versión de idioma de su aplicación en un recurso independiente DLL y tener las versiones de idioma diferente cargar los recursos apropiados .
Una desventaja potencial de al usar archivos DLL es que la aplicación no es autónoma; es depende de la existencia de un módulo DLL separado.
Algunas de estas razones tuvieron sentido hace años cuando el espacio en disco era caro. Pocos lo hacen hoy en día. Personalmente prefiero vincular mis aplicaciones estáticamente siempre que sea posible. –
Pero en los grandes sistemas empresariales es más eficiente tener módulos separados, ¿debes estar de acuerdo? – lsalamon
¿Más eficiente en términos de qué? –
Además el uso de espacio de memoria/disco, otra ventaja importante del uso de bibliotecas compartidas es que las actualizaciones de la biblioteca serán recogidos automáticamente por todos los programas en el sistema que utilizan la biblioteca.
Cuando había una vulnerabilidad de seguridad en las bibliotecas ZIP de InfoZIP, una actualización de la DLL/.so automáticamente hacía seguro todo el software que las usaba. El software que estaba vinculado estáticamente tuvo que ser recompilado.
Esto se ve comúnmente como una desventaja: ¿Alguna vez se ha oído hablar de "DLL Hell"? –
Sí, pero principalmente en conexión con MS Windows. Por lo que puedo decir, ocurrió porque MS Windows (antes) carecía de un administrador central de paquetes/software, como la mayoría de los sistemas Linux/BSD. Sin el seguimiento de la dependencia que proporciona un administrador de paquetes, el infierno de DLL es realmente un problema. Pero creo que las versiones modernas de Windows abordaron esto. – sleske
Sí, esto ahora se maneja mediante la instalación de archivos DLL SxS (lado a lado). Ahora puede haber múltiples copias, por lo que el problema DLL clásico (sobrescribir una DLL por una versión anterior) ya no debería pasar. – MSalters
Windows todavía usan DLL y los programas de Mac parecen no usar DLL en absoluto. ¿Son beneficios o desventajas de usar cualquiera de estas técnicas?
Ambos usan bibliotecas compartidas, solo usan un nombre diferente.
Si la instalación de un programa incluye toda la DLL necesaria para que funcione al 100%, ¿será lo mismo que vincular estáticamente todas las bibliotecas?
Algo. Cuando vincula estáticamente las bibliotecas a un programa, obtendrá un archivo único, muy grande, con archivos DLL, tendrá muchos archivos.
El archivo estáticamente vinculado no necesitará el paso "resolver bibliotecas compartidas" (que ocurre mientras se carga el programa). Hace mucho tiempo, cargar un programa estático significaba que todo el programa se cargaba primero en la memoria RAM y, luego, se producía el paso "resolver bibliotecas compartidas". Hoy, solo las partes del programa, que en realidad se ejecutan, se cargan a pedido. Entonces, con un programa estático, no necesita resolver los archivos DLL. Con las DLL, no necesita cargarlas todas a la vez. Por lo que respecta al rendimiento, deberían estar a la par.
Que deja el "DLL Hell". Muchos programas en Windows traen todas las DLL que necesitan y las escriben en el directorio de Windows. El efecto neto es que los últimos programas instalados funcionan y todo lo demás puede estar roto. Pero hay una solución alternativa: instalar los archivos DLL en el mismo directorio que el EXE. Windows buscará primero el directorio actual y luego las diversas rutas de Windows. De esta forma, perderás un poco de espacio en el disco pero tu programa funcionará y, lo que es más importante, no romperás nada más.
Se podría argumentar que no se deben instalar DLL que ya existen (con la misma versión) en el directorio de Windows, pero entonces eres vulnerable a alguna mala aplicación que sobrescribe la versión que necesitas con algo que rompe tu cuello. El inconveniente es que debe distribuir soluciones de seguridad para su aplicación usted mismo; no puede confiar en Windows Update o cosas similares para proteger su código. Este es un lugar difícil; los crackers están ganando mucho dinero por cuestiones de seguridad y a la gente no le gustará cuando alguien robe sus datos bancarios porque no emitió correcciones de seguridad lo suficientemente pronto.
Si va a admitir su aplicación muy estrechamente para muchos, por ejemplo, 20 años, la instalación de todas las DLL en el directorio del programa es para usted. De lo contrario, escriba un código que verifique que estén instaladas las versiones adecuadas de todas las DLL y cuéntele al usuario al respecto, para que sepan por qué su aplicación comienza a fallar repentinamente.
Desde mi punto de vista, un componente compartido tiene algunas ventajas que a veces se consideran inconvenientes.
Así que creo que el uso de coponentes compartidos ayudará a que el software se organice mejor.
posible duplicado de [Cuándo utilizar bibliotecas dinámicas frente a estáticas] (http://stackoverflow.com/questions/140061/when-to-use-dynamic-vs-static-libraries) –