Newsgroup: it.comp.programmare.win32
Titolo: scrivere una dll

Scrivendo una dll nel wizard trovo queste (sotto) due scelte: 
-MFC extension DLL 
-Regular DLL using shared MFC DLL 
Qualcuno cortesemente mi potrebbe illuminare, su cosa significano e cosa
comportano??
grazie ciao
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

c'è ne è una terza.. dll senza supporto mfc
le MFC sono le microsoft foundation class.. le librerie di ms ...
lì si tratta di una autocomposizione.. la dll sarà incapsulata dentro una
classe MFC ...
cmq diventerà pesantuccio.. xchè senza le mfc poi non gira, a menocchè non
le compili staticamente

"Antonio Mazzeo" <a[NOT]mazzeo@email[DOT].it> wrote in message
news:nKQQa.176371$
lK4.5...@twister1.libero.it

OK, grazie.
Ma volevo sapere la differenza tra le due alternative e cosa comportano.
Ad esempio una dll senza supporto MFC che vantaggi ha rispetto all'altra
scelta.
E visto ke ci sono ne approfitto x farti un'altra domanda:
una dll è paragonabile ad un progetto c++?? ovvero posso avere + file
distinti ke costituiscono un progetto DLL?
grazie,in anticipo, x la disponibilità.
ciao Sasha


 distinti ke costituiscono un progetto DLL?
una dll č un progetto c++ (se la scrivi in c++ ovviamente) al 100% .. cambia
soltanto
il tipo di eseguibile prodotto .. cmq pensa ad una dll come ad una libreria
C++ che
non viene linkata insieme all'eseguibile, piuttosto che viene caricata su
richiesta da parte
del programma che la utilizza..
puoi avere quanti file vuoi.. ma credo che tu possa avere un unico file DEF
(guarda msdn)
dove vai a scrivere quali funzioni o procedure devono essere esportate dalla
dll ..
puoi anche esportare classi .. fai cmq sempre riferimento a msdn x la
sintassi corretta
ciao
antonio

Ok, grazie mille.
Se nn sono troppo pesante ti pongo un altro quesito:
ho optato per una 'regular dynamic MFC' per consentire ad applicazioni
MFC/NOT_MFC di usare questa dll. Un problema mi si pone. Le funzioni
esportate
dalla mia dll si prendono un buffer(*char/*byte etc) dall'applicazione
principale comunicano con un server e riempiono questo buffer con dei
dati
ricevuti dal server. Ho letto su msdn ke il passaggio di puntatori
ad aree di memoria dell'applicazione verso le dll dovrebbe essere
evitato.
Potresti consigliarmi a tal proposito?? 
Ciao Sasha.


 Potresti consigliarmi a tal proposito??
non so dove tu abbia letto quanto dici dentro msdn.. ad una prima occhiata
non l'ho trovato.. ma non so se č corretto o non č corretto,
alla fine dei conti tutte le API del sistema operativo che ritornano
qualcosa in uscita.. richiedono un LPVOID (void *), e ti restituiscono
attraverso un puntatore a intero la dimensione del msg  ... loro lo usano e
ne abusano e poi lo sconsigliano?
il tutto comunque dipende da dove andrai ad utilizzare la dll .. considera
che in VB le stringhe sono allocate dinamicamente, quindi non
so che effetto farebbe alla tua dll una stringa passata da un applicativo VB
(sopratutto se la stringa č vuota, e la tua dll ci va a scrivere dentro!)
ti conviene fare come fa la microsoft
BOOL NOME(LPVOID ptr, LPDWORD size)
cosě se in ingresso dai un ptr NULL in size scrivi quanto deve essere lungo
la stringa di output..
ciao
antonio

[CUT]
Allora....
- MFC extension DLL -
nn è altro che un'estenzione della tua applicazione
cioè se crei un oggetto CObj "ESPORTANDO" tutte le funzioni (class
AFX_CLASS_EXT CObj : public .....)
dalla tua applicazione (exe) nn devi fare altro che linkare al .LIB della
libreria e include il .H di dove è dichiarato il tuo oggetto
Un pà come succede con le MFC, infatti quando usi CDocument tu includi il
.H, linki alla libreria che lo contiene (nn sò se è MFC42.LIB)
è il codice del .cpp nn lo vedi proprio.
Iportantissimo: questa libreria la puoi utilizzare solo con progetti C++
MFC.
 - Regular DLL using shared MFC DLL  -
E' una libreria regolare(puoi esportare e importare funzioni) ma se fai uso
delle MFC
all'atto della compilazione/link ti linkerà le DLL MFC in modo shared ( te
le devi portar dietro se installi il SW su un PC)
Poi c'è la terza che
- Regular DLL with MFC statically linked
Stesso discorso della seconda ma linka alle MFC DLL il modo statico, cioè
include nella tua DLL
Importante:
Se vuoi creare una libreria che esporti solo funzioni
basta creare un semplice .h e un cpp(ovviamente devi dichiaraare
opportunamente le funzioni)
__declspec(dllexport) ..bla bla bla.....
e usarle anche in altri linguaggi dipo VB ti conviene sempre una Regular
ciao
JoGiò

ok, molto chiaro.
ora vorrei un consiglio: la mia dll restituisce un puntatore ad
 array di byte. Io conosco la lunghezza dell'array solo dopo la
ricezione
dal server. E' lecito, secondo voi, allocare memoria nell'heap (new) e
restituire un puntatore a questa memoria dalla dll all'applicazione
chiamante?
 
Grazie in anticipo.
ciao sasha.


 ciao sasha.
Non dovrei rispondere perche' usi le MFC :). Comuqnue non penso sia una
buona idea allocare memoria da una parte e poi deallocarla da un'altra.
Penso sia meglio passare il puntatore alla memoria da riempire come
parametro della chiamata. Per sapere quanta memoria allocare puoi chiamare
la funzione una prima volta impostando tutti i parametri, ma mettendo il
puntatore al buffer a NULL. In questo caso la funzione potrebbe tornare la
quantita' di memoria necessaria per memorizzare tutti i dati. Non e' il
massimo, ma se non hai altro modo di sapere quanto deve essere grande il
buffer...
Luca

chiamante?
è lecito, a patto che tu deallochi nella stessa dll.
sbirish.