Newsgroup: it.comp.programmare.win32
Titolo: domande sull'uso delle DLL

Salve a tutti, sono un neofita e mi sto addentrando nella programmazione 
c++ da qualke mese.
La prima domanda è:
da quel ke ho capito leggendo gli help, faq e newsgroup devo premettere, 
nella/e classe/i ke costituiranno la libreria, a cio' ke voglio esportare 
declspec(dllexport), non mi chiaro invece l'uso ke si fa di 
declspec(dllimport).
Seconda domanda:
leggendo l'help del compilatore borland si fa riferimento ad _export o 
__export . Quale differenza passa tra questo e declspec ? 
Terza domanda:
declspec è una caratteristica propria del VC? Se si qual'e' il metodo più 
standard possibile per scrivere, compilare, linkare una dll? Sempre con il 
metodo "standard" come verrebbero poi utilizzate le librerie cosi' 
ottenute?
Ringrazio tutti i lettori e chi vorrà aiutarmi.
 Marco

 ottenute?
Il metodo più standard che conosco è quello di dichiarare gli EXPORTS in un
module file (.MOD) e linkarlo al progetto.
--
Efran Cobisi, sercom S.r.l.
eco...@sercomsrl.in
 (ANTI-SPAM: replace .in with .it)


Volevo dire in un module definition file (.DEF), non un .MOD!
...

 Volevo dire in un module definition file (.DEF), non un .MOD!
Tra l'altro il file DEF č l'unico modo per non avere le funzioni esportate
con i nomi decorati (ad es: _MyFunction@8 invece di MyFunction)
Lorenzo

Dopo avere impiegato tutto il giorno a creare una "Hello world"
con il file def come mi avete gentilmente suggertito sono riuscito ad 
ottenere qualche risultato.
Pero' a quanto pare, diversamente dalle indicazioni trovate negli help,
devo premettere alle funzioni ke intendo esportare:
extern "C"
Inoltre, ancora pare, ke sia possibile esportare solo funzioni, 
niente classi e/o attibuti.
Ottengo poi le funzioni esportate, ma diversamente da quanto Lorenzo (a 
proposito grazie per la risposta) afferma sono decorati.
Se puo' essere utile sto usando il compilatore bcc32 da linea di comando
e editanto tutti i sorgenti a mano.
Ora devo farmi una ragione di questi comportamenti e proseguire nello 
sviluppo tenendo conto di questi limiti oppure sto sbagliando qualcosa e ci 
sono soluzioni a tutto cio'? Il mio principale obiettivo e' scrivere codice 
quanto più indipendente possibile dal particolare ambiente di sviluppo in 
modo da agevolare un successivo porting su altre piattaforme.

 con i nomi decorati (ad es: _MyFunction@8 invece di MyFunction)
Non è per nulla corretto, consiglio di leggere attentamente MSDN alla voce
export "C"...
Vd. mio prossimo post nell'ordine dell'albero..


 modo da agevolare un successivo porting su altre piattaforme.
Non ritiene che scrivere codice C++ per piattaforme win32 sia un po' contro
gli obiettivi prefissati?
Distinti Saluti


 contro gli obiettivi prefissati?
SI, fino ad ora ho utilizzato solo librerie standard del c/c++, purtroppo 
la struttura del progetto non puo' prescindere da un run-time linking di 
alcuni moduli, per questo su win32 sto cercando di usare le dll, ke per 
quanto a mia conoscenza (ricordo che sono un newby) sono l'unica 
possibilità, da quanto letto, ma non ancora sperimentato in ambiente unix 
si usano gli shared objects. Dagli esempi trovati dovrei riuscire a far 
coesistere le due modalita (dll e so) con qualke #ifdef
Spero di non essere del tutto fuori pista.
Sempre per gli stessi motivi cerco di evitare l'uso di __declspec(...)
e lavoro quasi esclusivamente con il compilatore free a linea di comando.
Grazie dell'attenzione e dell'aiuto prezioso.
Marco

 proposito grazie per la risposta) afferma sono decorati.
Sei sicuro di aver usato i file "def"? Non ho mai usato i compilatori
Borland, ma penso che per questo genere di problematiche siano assimilabili
a quelli MS.
Un estratto da una mia DLL è così:
// --- LozUtils.h ---
#ifdef __cpluplus
extern "C" {
#endif
BOOL  __stdcall LozCreateShortcut(PCSTR szTarget, PCSTR szLnkFile);
#ifdef __cplusplus
}
#endif
// --- LozUtils.c ---
#include <windows.h>
#include <shlobj.h>
#include "lozutils.h"
int WINAPI DllMain (HINSTANCE hInstance, DWORD fdwReason, PVOID pvReserved)
{
    return TRUE;
}
BOOL __stdcall LozCreateShortcut(PCSTR szTarget, PCSTR szLnkFile)
{
    return TRUE;
}
E questo è il file lozutils.def:
EXPORTS
    LozCreateShortcut   @ 1
Prova a seguire questa traccia con la tua DLL.
Ciao,
Lorenzo

interpretare le decorazioni C++ e farti vedere la struttura delle classi...
Il codice C++, difatti, e' esportabilissimo.
Le DLL si possono costruire con un particolare compilatore e metterci
dentro tutto quello che vuoi.  Il problema e' che la decorazione dei
nomi sara' propria di quel compilatore e la DLL sara' utilizzabile
solo con programmi scritti con quel compilatore.

 solo con programmi scritti con quel compilatore.
Grazie per l'informazione! Hai per caso qualche esempio d'uso o qualche
dritta per VisualC++ ?
Lorenzo

Signori, fatemi il piacere: le decorazioni delle funzioni C++ sono standard
per la compilazione C++...
E questo magnifico tool Dependency Walker utilizza ben *una* api per
eliminare la decorazione da tali funzioni:
    UnDecorateSymbolName di imagehlp
Non diciamo fesserie per piacere...
--
Efran Cobisi, sercom S.r.l.
eco...@sercomsrl.in
 (ANTI-SPAM: replace .in with .it)
"Andrea Laforgia" <xx...@xxxxx.xxx> ha scritto nel messaggio
news:uesrhtg7m0784n8re...@4ax.com...


Non diciamo fesserie per piacere...
Appunto...

dritta per VisualC++ ?
io ho dovuto affrontare il problema di scrivere una dll tramite il
vc++ e il borland c++, non sono riuscito a giungere a un compresso
tra i due compilatori (lo stesso codice, senza dover cambiare nulla).
il risultato erano sempre 2 dll con nomi differenti delle funzioni.
per il visual c++ la soluzione é creare un file .def dove memorizzare
i nomi delle funzioni da esportare
col borland c++ risolvevo semplicemente inserendo un
int _declspec(dllexport) __stdcall  funzione(......)
unico guaio (pensavo che finisse li!) é lo stack..
eseguendo il debugging delle procedure di chiamata alle
dll il risultato é che i due compilatori non la pensavano allo
stesso modo su come gestire lo stack e la funzione __checkesp(esp)
del vc++ produceva un gpf
cod

Non diciamo fesserie per piacere...
Io veramente ho trovato questo su MSDN:
INFO: C++ Name Decoration--Why Used, Getting Decorated Names
Last reviewed: December 11, 1997
Article ID: Q126845  
[...]
Different compiler vendors have their own methods or algorithms for
decorating names. Microsoft does not publish the algorithm its
compilers use for name decoration because it may change in the future.
[...]
Ciao
Marco Barisione (ICQ 84277092)

 E' questo che rende i compilatori C++ incompatibili a livello binario.
Senta ma cosa sta dicendo?
Ribadisco: non diciamo fesserie!
Saluti


 >Signori, fatemi il piacere: le decorazioni delle funzioni C++ sono


Ribadisco: non diciamo fesserie!
Si contenga.  Ribadisco: Appunto.

compilatori C++
Niente affatto.
http://codeguru.earthweb.com/cpp/tic/tic0083.shtml#Index681

> [...]
Veramente ciò che ho indicato io dovrebbe essere + recente (è del
'97), UnDecorateSymbolName penso sia + vecchia essendo penso
disponibile su win95


dritta per VisualC++ ?
Estratto del paragrafo "C++ and Portability" da "Essential COM"[1] :
"Once the decision is made to distribute a C++ class as a DLL, one is
faced with one of the fundamental weaknesses of C++, that is, lack of
standardization at binary level.  Although ISO/ANSI C++ Draft Working
Paper attempts to codify which programs will compile and what the
semantic effects of running them will be, it makes no attempt to
standardize the binary runtime model of C++. The first time this
problem will become evident is when a client tries to link against the
FastString (NOTA: e' la classe d'esempio creata dall'autore) DLL's
import library from a C++ development environment other than the one
used to build the FastString DLL.
To allow operator and function overloading, C++ compilers typically
mangle the symbolic name of each entry point to allow many uses of the
same name (either with different argument types or in different
scopes) without breaking existing C-based linkers.  This technique is
often referred to as "name mangling". Despite the fact that the C++
Annotated Reference Manual (ARM) documented the encoding scheme used
by CFRONT, many compiler vendors have elected to invent their own
proprietary mangling scheme.  Because the FastString import library
and DLL export symbols using the mangling scheme of the compiler that
built the DLL (e.g. GNU C++) clients that are compiled using a
different compiler (e.g. Borland C+) will not be able to link
sucessfully with the import library. The classic tecnique of usign
extern "C" to disable symbolic mangling would not help in this case,
as the DLL is exporting member functions, not global functions.
One technique that could alleviate the problem is to play tricks on
the client'slinker by using Module Definition File (commonly known as
a DEF file). One feature of DEF files is that they will allow exported
symbols to be aliased to different imported symbols. Given enough time
and information about each compiler's mangling scheme, the library
vendor can produce a custom import library for each compiler. While
tedious, this allows any compiler to gain link-level compatibility
with the DLL, provided the library vendor has anticipated its use
ahead of time and has provided a proper DEF file."
L'autore poi descrive un'altra incompatibilita' tra i diversi
compilatori C++ che e' quella riguardante il trattamento delle
eccezioni :
"A C++ exception thrown from a function compiled with the Microsoft
compiler cannot be caught reliably by a client program compiled with
the Watcom compiler.".
e ne spiega anche il perche' :
"This is because the DWP does not mandate what a language feature must
look like at runtime, so it is perfectly legal for each compiler
vendor to implement a language feature in a unique and innovative
manner."
Conclude dicendo :
"The lack of a C++ binary standard limits what language features can
be used across DLL boundaries.  This means that simply exporting C++
member functions from DLLs is not enough to create vendor-independent
component substrate".
[1] Don Box, "Essential COM", Addison-Wesley 1998
    ISBN 0201634465