Newsgroup: it.comp.lang.delphi
Titolo: ShareMem e FreeLibrary

Ciao ragazzi, ho un problema:
programmo con delphi 2005, creo un progetto nuovo DLL con il wizard. La
dll che chiamero pippo.dll non fa assolutamente niente, non esporta
alcuna funzione, aggiungo solo nelle uses la libreria ShareMem. Carico
pippo.dll da programma con LoadLibrary e fin qui tutto ok; alla
chiusura del mio programma faccio la FreeLibrary di pippo.dll e mi si
pianta tutto. Ho notato che chiamando la FreeLibrary di pippo.dll senza
che quest'ultima contiene Sharemem non da problemi. C'e percaso qualche
accorgimento da tenere nel caso si voglia usare la libreria Sharemem in
una dll affinche non dia problemi la freelibrary???? Grazie a presto.

Sharedmem è usato anche dall'applicazione chiamante?
Bye,
Raktzo

 una dll affinche non dia problemi la freelibrary???? Grazie a presto.
La unit /ShareMem/ deve essere utilizzata sia dalla libreria (DLL) sia 
dall'applicazione e deve figurare come la prima unit elencata nella 
clausola *uses* di entrambi i progetti.
Usa /SafeLoadLibrary/ al posto di /LoadLibrary/ per sopprimere 
l'eventuale messaggio di errore che ti viene restituito da Windows nel 
caso in cui la DLL non venga trovata.
Tieni anche conto che la unit /ShareMem/ ti consente di condividere il 
gestore di memoria (Borland Memory Manager) ma č necessario distribuire 
la DLL "borlndmm.dll" assieme al tuo file eseguibile e alla tua libreria.
Infine, molto importante, l'uso di /ShareMem/ ti consente sě di 
condividere il memory manager per poter passare tranquillamente tipi di 
dati come le stringhe, autonomamente gestite appunto dal manager, ma se 
fai uso di classi ed elementi della VCL come Form, componenti e 
controlli, č meglio fare uso di un package o comunque abilitare per 
entrambi i progetti, applicazione e libreria esterna, la compilazione 
con i "runtime package" pena il verificarsi di effetti collaterali.
In questi frangenti, č piů sicuro fare uso dei package per questo 
motivo, ma non sono sicuro che si tratti del tuo caso (al massimo, me lo 
confermerai).
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 In questi frangenti, è più sicuro fare uso dei package per questo


 con i "runtime package" pena il verificarsi di effetti collaterali.
mi inserisco nella discussione e ne approfitto per chiederti una cosa: se 
uso i package runtime, posso passare tranquillamente le strighe? O devo 
ancora includere ShareMem (e distribuire borlndmm.dll)?
Questo perchč sto iniziando a usare i package runtime, senza ShareMem e 
borlndmm.dll, e non ho (ancora) avuto problemi con il passaggio di 
stringhe.
E' un dubbio che ho sempre avuto: quindi i BPL includono il memory manager?
-- 
Mauro Falzari 
 
 "Se guardi nell'abisso, anche l'abisso guarda in te." 
   (Friedrich Nietzsche)

 cosa pensare......
Si tratta di C++Builder? In caso affermativo, è possibile che vi siano 
possibilità di interazione usando /ShareMem/ tra applicazione e 
libreria; in caso contrario, a mio avviso devi limitare la tua libreria 
ad utilizzare i tipi standard delle API di Windows, ad esempio passando 
un tipo PChar per le stringhe, allocando esternamente un buffer di 
memoria in cui copiare la stringa da utilizzare, evitando poi l'uso di 
oggetti e altre strutture dati "Delphi bound".


 E' un dubbio che ho sempre avuto: quindi i BPL includono il memory manager?
Buona domanda... ;-)
Faccio qualche prova tecnica, indago e poi ti faccio sapere. :-)


La cosa strana è che la mia dll non fa assolutamente niente, non
esporta alcuna funzione. Praticamente facendo partire il wizard dll di
delphi, mi apre un nuovo progetto dll e l'unica cosa che aggiungo è la
sharememe nella clausola uses, basta. Eppure l'eseguibile che chiama la
freelibrary schianta.
P.S.
Il compilatore c/c++ e il Visual C Microsoft, ma penso che questo non
sia il problema. Grazie ancora Marco
Marco Breveglieri ha scritto:


 E' un dubbio che ho sempre avuto: quindi i BPL includono il memory manager?
Ci ho dormito sopra e, nei sogni, ho pensato che deve essere sicuramente 
come dici tu. :-)
Nessuno ha mai dovuto includere alcuna unit particolare per poter 
utilizzare i runtime package all'interno della propria applicazione, 
quindi deduco che la struttura interna del package BPL fornisca tutto il 
supporto per poter utilizzare le classi e le risorse all'interno del 
package stesso.
In fondo, questo "servizio" lo ritengo indispensabile, altrimenti non ci 
sarebbero grossi motivi per favorire i package BPL alle classiche 
librerie DLL.


 del package stesso.
io ho compilato un'applicazione coi runtime packages (sia static linkink 
che dynamic loading), applicazione che scambia "tipi di dati Delphi" 
(classi che includono anche proprietà di tipo string). 
Ho provato l'applicazione su un computer "nudo" (senza Delphi installato 
sopra, nè BPL in %systemroot%\system32) e gli ho piazzato nella root 
dell'applicazione i package richiesti e sembrava funzionare. Della serie 
"non so il motivo, ma funzia".
Ovviamente senza ShareMem, quindi deduco che:
- la ShareMem serve solo per lo scambio di stringhe da/verso le DLL 
standard Windows;
- i package sono un tipo molto evoluto di DLL.
