Delphi Dynamic Dll - variabile globale

Question

Sono occupato a codificare una DLL che fornisce diverse funzioni a un'applicazione host. Questa applicazione chiama la DLL dinamicamente, caricandola e liberandola dopo ogni chiamata di funzione.

Non ho alcun controllo sull'app host. Posso lavorare solo con la DLL. C'è un modo per mantenere determinate variabili in memoria in modo che possa riutilizzarle all'interno di ogni funzione? Ovviamente una variabile globale viene cancellata quando la DLL viene scaricata dall'app host. Salvare la dll in un file molto disordinato!

Qualcuno può suggerire un modo per assegnare una variabile che posso mantenere globale?

Grazie

Answer 1

Penso che tu abbia 2 opzioni principali qui.

1. offerta 2 versioni della vostra funzione, quello che hai ora, più un altro dove passano in un buffer (registrazione, a prescindere) che si può leggere lo stato precedente da, e, naturalmente, aggiornare lo stato in. Chiamala la versione ad alta perf della funzione. Vogliono usarlo.

2. Salvare lo stato come si farebbe un cookie (questo è fondamentalmente quello che è) in un file da qualche parte.

Opzione 1 richiederebbe la modifica al app host, ma sarebbe interessante per gli sviluppatori di applicazioni host per trarre vantaggio, opzione 2 richiederebbe alcuna modifica l'applicazione host, ma non sarebbe così performante.

Personalmente non sarei incline a iniziare a chiacchierare con il numero di riferimento, presumibilmente l'app host sta scaricando per un motivo, se fossi l'app per l'host, mi avrebbe dato fastidio.

Answer 2

Il modo migliore è quello di utilizzare una classe che contiene le "globali". Si istanzia un oggetto e lo si assegna come parametro alle funzioni dll. Ma questo non ti aiuterà perché non sei in grado di cambiare l'app chiamante.

Se è necessario mantenere i dati globali nella DLL, una soluzione è scriverli in un file. Ma questo ha un impatto grave sulle prestazioni.

Answer 3

Se fossi in te, salverei i valori di tali vars globali in un file quando la DLL viene liberata e caricata quando viene inizializzata. Non ho motivo di salvare il dump della memoria della dll sul disco.

Answer 4

Attenzione, sporco trucco:

Si potrebbe caricare te stesso.

Ogni chiamata a LoadLibrary incrementa un contatore di riferimento, FreeLibrary lo diminuisce. Solo se il contatore raggiunge lo zero, la DLL viene scaricata.

Quindi, se la prima volta che viene caricata la DLL, è sufficiente caricare nuovamente la libreria, incrementando così il contatore di riferimento. Se l'applicazione chiamante chiama FreeLibrary il contatore di riferimento viene decrementato, ma la DLL non viene scaricata.

MODIFICA: Come indicato da mghi, la DLL verrà scaricata se il processo termina, indipendentemente dal fatto che il conteggio dei riferimenti sia zero o meno.

Answer 5

Un'altra soluzione, se si dispone di una grande quantità di dati globali da condividere, sarebbe quella di creare un servizio Windows per "memorizzare" i dati di stato. È inoltre necessario implementare una sorta di IPC che funzioni attraverso il limite del processo, come i file mappati in memoria, le cassette postali, COM (singola istanza per questo caso), TCP/IP ecc. Potresti scoprire che questo overhead sarebbe più che la semplice scrittura dello stato in un file, motivo per cui consiglierei questo approccio solo se la quantità di dati di stato è eccessiva, o sarà trattata solo in parti del tutto per ogni richiesta nella tua DLL.

Per l'approccio COM, il servizio non deve fare molto altro che richiedere (e trattenere) un'istanza dell'oggetto COM che si utilizzerà per mantenere lo stato. Poiché si tratta di un oggetto com a istanza singola, tutte le richieste saranno relative alla stessa istanza, consentendo in questo modo di salvare lo stato tra le richieste. Le richieste all'oggetto sono serializzate, quindi questo potrebbe essere un problema di prestazioni se più client richiedono contemporaneamente dati sulla stessa macchina.

Answer 6

Scrive i valori nel registro quando la DLL viene liberata e legge i valori dal registro quando viene caricata la DLL. Non dimenticare di fornire un valore predefinito quando la lettura scopre che una chiave non è stata impostata.

-Al.

Answer 7

Sono d'accordo con i commenti precedenti sull'informazione di stato globale che è pericolosa, anche se posso immaginare che potrebbe essere necessaria.

propongo una versione più pulita di hack sporco di DR che non ha il rovescio della medaglia di essere permanente come la risposta di skamradt:

Una piccola applicazione:

Non ha l'aspetto di sorta, si tiene da mostrando sulla barra delle applicazioni.

Task # 1: caricare la DLL

Task # 2: Take è a riga di comando, eseguirlo e attendere il completamento dello stesso.

Task # 3: Scaricare la DLL

Task # 4: Exit.

Il programma di installazione:

Essa trova la scorciatoia (s) per l'applicazione principale e li modifica quindi le piccole serie di app, la posizione originale il collegamento indicò diventa il primo parametro.

Risultati: la DLL rimane in memoria solo finché l'app principale è in esecuzione ma non viene scaricata ogni volta che il programma lo scarica.

Answer 8

Questo può anche essere utile

option 1: creare un'area di memoria condivisa che detiene le variabili supportate da file di paging - se siete in grado di aprire quella zona di memoria condivisa, la DLL è stato precedentemente caricato (assumendo "privato "nome della memoria condivisa, forse chiamato qualcosa come process_id_yourdllname) - se non riesci ad aprirlo, lo crei e lo inizializzi la prima volta. Se lo crei, non ti preoccuperai di cancellarlo, ma se lo apri, lo chiuderesti al momento dello scaricamento. Credo che l'area verrà rilasciata quando l'applicazione si chiuderà, poiché nessun'altra applicazione dovrebbe avere maniglie per questa particolare area di memoria condivisa "privata".

option 2: Creare un secondo.DLL che esiste solo allo scopo di gestire le tue variabili globali. La tua DLL A può caricare quella DLL B, e non liberarla, inserendo in dll B tutto ciò che è necessario per gestire le variabili globali. Dovrebbe andare via quando l'applicazione va via, e non penso che probabilmente ti serva il conteggio dei riferimenti (presumibilmente inutile) in questione (dato che non scaricheresti dll B).