Delphi Dynamic Dll - variable global

Question

Estoy ocupado codificando un dll que suministra varias funciones a una aplicación host. Esta aplicación llama dinámicamente al dll, lo carga y libera después de cada llamada de función.

No tengo control sobre la aplicación host. Solo puedo trabajar dentro del dll. ¿Hay alguna manera de mantener ciertas variables en la memoria para poder reutilizarlas dentro de cada función? Obviamente, un servidor global se borra cuando la aplicación de host descarga el dll. ¡Guardar el dll en el archivo suena muy desordenado!

¿Alguien puede sugerir una forma de asignar una variable que pueda mantener global?

Gracias

Answer 1

Creo que tiene 2 opciones principales aquí.

1. oferta de 2 versiones de su función, el que tiene ahora, además de otro donde pasan en una memoria intermedia (registro, lo que sea) que se puede leer el estado previo de, y por supuesto actualizar el estado en. Llamar a esto la versión de alto rendimiento de la función. Ellos querrán usarlo.

2. Guarde el estado como lo haría con una cookie (eso es básicamente lo que es) en un archivo en alguna parte.

Opción 1 requeriría la modificación a la aplicación de acogida, pero sería atractiva para los desarrolladores de aplicaciones de host para aprovechar, opción 2 requeriría ningún cambio en la aplicación de host, pero no sería tan performante.

Personalmente, no me gustaría comenzar a perder el tiempo con el recuento de referencias, presumiblemente la aplicación host se descarga por algún motivo, si fuera el desarrollador de la aplicación host, eso me molestaría.

Answer 2

La mejor manera es utilizar una clase que contiene los "globales". Instancias un objeto y lo das como parámetro a las funciones dll. Pero eso no lo ayudará porque no puede cambiar la aplicación de llamada.

Si tiene que mantener los datos globales en la dll, una solución es escribirlos en un archivo. Pero esto tiene un gran impacto en el rendimiento.

Answer 3

Si yo fuera tú, guardaría los valores de esos valores globales en un archivo when el dll se libera y los cargaré cuando se inicialice. No tengo ninguna razón para guardar el volcado de memoria del dll en el disco.

Answer 4

Advertencia, truco sucio:

Usted podría cargar a sí mismo.

Cada llamada a LoadLibrary incrementa un contador de referencia, FreeLibrary lo disminuye. Solo si el contador llega a cero, la DLL se descarga.

Así que si la primera vez que se carga su DLL, solo cargue su biblioteca de nuevo, incrementando así el contador de referencia. Si la aplicación de llamada llama al FreeLibrary, el contador de referencia se reduce, pero la DLL no se descarga.

EDIT: Como señaló mghi, la DLL se descargará si el proceso finaliza, si el recuento de referencias es cero o no.

Answer 5

Otra solución, si tiene una gran cantidad de datos globales para compartir, sería crear un servicio de Windows para "almacenar en caché" los datos de estado. También necesitaría implementar algún tipo de IPC que funcione a través del límite del proceso, como archivos mapeados en memoria, buzones, COM (instancia única para este caso), TCP/IP ect. Puede encontrar que esta sobrecarga sería más que solo escribir el estado en un archivo, por lo que solo recomendaría este enfoque si la cantidad de datos de estado es excesiva, o solo se tratará en partes del todo para cada solicitud en tu dll.

Para el enfoque COM, el servicio no tiene que hacer mucho más que solicitar (y mantener) una instancia del objeto com que va a utilizar para mantener el estado. Dado que es un objeto com de instancia única, todas las solicitudes se realizarán en la misma instancia, lo que le permitirá guardar su estado entre solicitudes. Las solicitudes al objeto se serializan, por lo que esto podría ser un problema de rendimiento si tiene varios clientes que solicitan datos en la misma máquina al mismo tiempo.

Answer 6

Escriba los valores en el Registro cuando se libera la DLL y lea los valores del Registro cuando se carga la DLL. No olvide proporcionar un valor predeterminado cuando la lectura descubra que no se ha establecido una tecla.

-Al.

Answer 7

Estoy de acuerdo con los comentarios anteriores acerca de que la información global del estado es peligrosa, aunque me imagino que podría ser necesaria.

propongo una versión más limpia de truco sucio de DR que no tiene la desventaja de ser permanente, como la respuesta de skamradt:

Una pequeña aplicación:

No tiene ningún aspecto en absoluto, se mantiene en sí de mostrando en la barra de tareas.

Tarea # 1: Cargar la DLL

Tarea # 2: Tome la línea de comandos es, ejecutarlo y esperar a que termine.

Tarea # 3: Descargue el archivo DLL

Tarea # 4: Salir.

El instalador:

Se encuentra en el acceso directo (s) a la aplicación principal y los modifica por lo que las pequeñas series de aplicaciones, la ubicación original en el acceso directo señaló que se convierte en el primer parámetro.

Resultados: La DLL permanece en la memoria solo mientras se ejecuta la aplicación principal, pero no se descarga cada vez que el programa la descarga.

Answer 8

Esto también puede ser útil

option 1: crear un área de memoria compartida que mantiene sus variables respaldados por archivo de paginación - si usted es capaz de abrir esa área de memoria compartida, el archivo DLL se cargó previamente (asumiendo "privada "nombre de memoria compartida, tal vez llamado algo así como nombre_de_proceso_nombre_de_comprado"); si no puede abrirlo, cree e inicialice la primera vez. Si lo crea, entonces no se molesta en eliminarlo, pero si lo abre, lo cerraría, al momento de la descarga. Creo que el área se lanzará cuando se cierre la aplicación, ya que ninguna otra aplicación debería tener identificadores para este área de memoria compartida "particular" en particular.

option 2: Crear un segundo.dll que existe solo con el propósito de administrar sus variables globales. Su dll A puede cargar ese dll B, y no liberarlo, colocando en dll B lo que necesite para administrar las variables globales. Debería desaparecer cuando la aplicación desaparezca, y no creo que deba preocuparse por el recuento de referencias (presumiblemente inútil) involucrado (ya que no estaría descargando dll B).