Enlace estático o dinámico de CRT, MFC, ATL, etc.

Question

En los años 90, cuando empecé con MFC, solía vincular dinámicamente mis aplicaciones y enviaba las DLL de MFC relevantes. Esto me causó algunos problemas (¡demonios DLL!) Y, en cambio, cambié a la vinculación estática, no solo para MFC, sino también para CRT y ATL. Aparte de los archivos EXE más grandes, la vinculación estática nunca me ha causado ningún problema, así que, ¿hay alguna desventaja que otras personas hayan encontrado? ¿Hay una buena razón para volver a visitar la vinculación dinámica? Mis aplicaciones son principalmente STL / Boost hoy en día FWIW.

Answer 1

Hay algunas desventajas:

• Tamaño de archivo ejecutable más grande (especialmente si envía varios exe)
• Problemas al usar otras DLL que dependen o asumen enlaces dinámicos (por ejemplo: DLL de terceros que no se pueden obtener como bibliotecas estáticas)
• Diferentes tiempos de ejecución de c entre DLL con enlace estático independiente (sin asignación / desasignación de módulos cruzados)
• No hay servicio automático de componentes compartidos (no es posible que el proveedor de un módulo externo actualice su código para solucionar problemas sin volver a compilar y actualizar su aplicación)

Hacemos enlaces estáticos para nuestras aplicaciones de Windows, principalmente porque permite la implementación de xcopy, que simplemente no es posible con la instalación o el uso de DLL de SxS de una manera que funcione, ya que el proceso y el mecanismo no están bien documentados o son remotos fácilmente. Si usa DLL locales en el directorio de instalación, funcionará un poco, pero no está bien soportado. La incapacidad de realizar fácilmente la instalación remota sin pasar por un MSI en el sistema remoto es la razón principal por la que no usamos el enlace dinámico, pero (como usted señaló) hay muchos otros beneficios para el enlace estático. Para cada uno hay pros y contras; Esperemos que esto ayude a enumerarlos.

Answer 2

La mayoría de las respuestas que escucho sobre esto involucran compartir sus archivos DLL con otros programas, o actualizarlos sin la necesidad de parchear su software.

Francamente, considero que son desventajas, no ventajas. Cuando se actualiza una dll de terceros, puede cambiar lo suficiente como para romper su software. Y en estos días, el espacio en el disco duro no es tan precioso como lo era antes, ¿500k extra en tu ejecutable? ¿A quien le importa?

• Estar 100% seguro de la versión de dll que usa tu software es bueno.
• Estar 100% seguro de que el cliente no va a tener un dolor de cabeza por dependencia es bueno.

Las ventajas superan con creces las desventajas en mi opinión

Answer 3

Mientras mantengas tu uso limitado a ciertas bibliotecas y no utilices ninguna DLL, deberías ser bueno.

Lamentablemente, hay algunas bibliotecas que no se pueden vincular de forma estática. El mejor ejemplo que tengo es OpenMP. Si aprovecha el soporte OpenMP de Visual Studio, tendrá que asegurarse de que el tiempo de ejecución esté instalado (en este caso, vcomp.dll).

Si usas dll, entonces no puedes pasar algunos artículos de un lado a otro sin gimnasia seria. std :: cuerdas vienen a la mente. Si su exe y dll están vinculados dinámicamente, entonces la asignación tiene lugar en el CRT. De lo contrario, su programa puede tratar de asignar la cadena en un lado y desasignarla en el otro. Siguen cosas malas ...

Dicho esto, todavía vinculo estáticamente mi exe y dll. Reduce mucho la variabilidad en la instalación y considero que vale la pena por las pocas limitaciones.

Answer 4

Una buena característica del uso de DLL es que si varios procesos cargan la misma DLL, su código puede compartirse entre ellos. Esto puede ahorrar memoria y acortar los tiempos de carga de una aplicación que carga una dll que ya está siendo utilizada por otro programa.

Answer 5

No, nada nuevo en ese frente. Mantenlo de esa manera.

Answer 6

Definitivamente.

La asignación se realiza en un montón 'estático'. Dado que la asignación se debe realizar en el mismo montón, esto significa que si envía una biblioteca, debe tener cuidado de que el código del cliente no pueda llamar 'su' p = new LibClass () y eliminar eso objeto mismo usando delete p; .

Mi conclusión: puede proteger la asignación y la desasignación del código del cliente, o vincular dinámicamente el CRT.

Answer 7

Hay algunas licencias de software como LGPL que requieren que use una DLL o distribuya su aplicación como archivos de objetos que el usuario puede vincular. Si está utilizando una biblioteca de este tipo, probablemente querrá usarla como una DLL.