2009-07-30 13 views
8

En primer lugar, me refiero a un entorno de Windows y al compilador de VC++.¿Cómo actualizar un dll C++ sin necesidad de volver a vincular el exe con el archivo lib?

Lo que quiero poder hacer es reconstruir un dll de VC++ y mantener la compatibilidad con un exe que ya se ha vinculado a la lib sin tener que reconstruir el exe o cargar el dll dinámicamente utilizando LoadLibrary. En otras palabras, ¿hay alguna manera de agregar clases y métodos a un dll (pero no eliminar ninguno) y asegurar que los puntos de entrada existentes permanezcan igual?

Respuesta

8

Si exporta las funciones desde un archivo DEF y especifica manualmente los ordinales, debería ser capaz de lograr esto.

Referencia

http://msdn.microsoft.com/en-us/library/d91k01sh(VS.80).aspx

+5

me gustaría añadir la referencia http: //msdn.microsoft.com/en-us/library/900axts6(VS.80).as px Está a solo un clic del hipervínculo anterior y explica las razones para usar archivos de definición de seguridad y los pros y los contras. – Rich

0

Siempre y cuando no agregue ningún símbolo exportado, los ordinales no cambiarán. Si agrega símbolos exportados a través del mecanismo estándar de dllexport, entonces eso será difícil de controlar. Si usa el archivo de símbolos .xpf de estilo antiguo, es posible que pueda controlar el orden de los símbolos en la lib (aunque no lo sé con certeza, podría reordenarlos como prefiera), pero es difícil de hacer Símbolos de C++ de esta manera.

0

creo que ordinales rara vez se utilizan para resolver las importaciones DLL más - Creo que usted tiene que utilizar archivos .def para obtener el enlazador para usarlos. Así que mientras no cambie los nombres o firmas de las funciones exportadas, el .exe debería funcionar bien.

8

Depende de cómo su EXE utilizó las clases de la DLL. Agregar nuevas clases no debe afectar los puntos de entrada existentes. Aparte de eso, sin embargo, cualquiera de los siguientes afectará el tamaño y/o diseño del objeto, y como tal será un cambio radical (tenga en cuenta que esto es técnicamente VC-specific, pero la mayoría de estos se aplican a cualquier implementación):

  • campos Extracción (incluso privado) de las clases
  • La adición de nuevos campos (incluso privado) a las clases
  • Adición de nuevas clases base a las clases existentes
  • Eliminación de clases base de las clases existentes
  • Adición de nuevo virtuales método antes de un método virtual existente (agregar nuevos métodos virtuales después de los existentes está bien, excepto en el caso descrito en el siguiente punto)
  • Agregando un nuevo método virtual en una clase que se usa como clase base por otra clase en la misma DLL que también tiene métodos virtuales
  • tipo de cambio de los campos existentes
  • Cambio de la firma de los métodos existentes
  • Realización de un método virtual no virtual, y viceversa
+0

Creo que esta es una buena respuesta, pero cambiaría una cosa: cambiar los métodos virtuales en una clase de alguna manera sería sospechoso. No creo que pueda contar con el vtable para tener las funciones virtuales en el mismo orden en que se muestran en el archivo fuente. –

+0

Al menos en VC, puede contar con eso; este es un requisito previo para la compatibilidad con COM (que requiere un ordenamiento vtable definido). –

+0

Gran respuesta Pavel, me pregunto si podría agregar algunas referencias para respaldar sus afirmaciones. ¡Gracias! –

Cuestiones relacionadas