Newsgroup: it.comp.lang.visual-basic
Titolo: [VB express 2008] debug passo passo delle chiamate a DLL esterna ed INTERNALS.H

Dunque, premesso che visual studio express 2008 è davvero 
poderoso,
stavo pasticciando con le convenzioni di chiamata per 
interfacciare una DLL in C++ UNMANAGED con un programma VB.
Dopo avere spulciato con le vadie __declspec (dllexport) e 
dllimport, e le varie CallConvention.CDECL, insomma, delle 
dichiarazioni che sono più corpose delle funzioni stesse, 
pare che finalmente i due ambienti si parlino. Mi passa 
persino delle stringhe che la controparte C++ vede come un 
onesto char * senza che manco ho dovuto occuparmi io di 
conversioni DA/AD unicode o altri aspetti del genere.
Non mi aspettavo di riuscire a debuggare passo passo, 
partivo pessimista. Invece, tenendo persino aperti entrambi 
gli ambienti, il debug riesce a partire, e, pazzesco, DA 
AMBO gli ambienti.
Da VB, che per ora è un client, la dichiarazione stessa 
della DLL ha QUASI concluso i problemi. Da ambiente C++ 
invece mi chiedeva, banalmente, di dirgli quale ATTACHED 
process lanciare, perché la DLL da sola è un servizio non 
eseguibile. Ma dato cehe VB compila sempre, ho solo dovuto 
trovare l'eseguibile annidato nelle varie subsubsubdirectory.
Vabbè, per farla breve. Da ambiente VB, fintantoché metto 
dei breakpoint LONTANI (anche una sola istruzione ma 
staccati) dalle chiamate alla DLL, funziona tutto regolarmente.
Una volta, per caso, ho provato a premere il PASSO PASSO 
nell'istruzione stessa della chiamata out-process. Mi 
aspettavo che la eseguisse comunque in un solo colpo. Invece 
è successa una cosa strana. L'ambiente ha tentato di 
tracciare dentro la DLL, ma mi ha chiesto di indicargli un 
non meglio precisato file INTERNALS.H, che pare uno header, 
ma non so dove dovrebbe essere né chi dovrebbe produrlo.
Dall'estensione del file parrebbe uno header stile C (manco 
C++), ma non coincide con alcunché di dichiarato nella mia 
DLL (che un suo header pure lo ha, ma ha un nome del tutto 
diverso).
Cosa significa questo comportamento ?
Cioè, ammesso di capire chi lo deve produrre e 
indicarglielo, cosa succederebbe col passo passo ?
L'ambiente VB tenterebbe di lanciare l'ambiente di debug C++ 
di alto livello e gli passerebbe il controllo ? 
(fantascienza ...) Oppure ... L'ambiente VB mi aprirebbe uan 
sorta di finestra di debug di basso livello, diciamo stile 
assembly coi registri, la memoria, lo stack etc etc ?
Qualcuno del NG ha per caso tentato di debuggare passo passo 
tracciando le procedure dentro una DLL ?
Preciso che sto facendo per il momento solo release di debug 
con complete info di debug ambo parti. Non so però quali 
info e come i due ambienti di debug dovrebbero passarsi tali 
info.
Capisco che potrebbe anche essere una lacuna sul fronte C++, 
che magari non produce, per le opzioni che ho impostate, 
qualche file necessario al debug cross-process (che so, 
qualche type-lib o altro ... boh).
E' la prima volta che tento un debug passo passo in una 
chiamata DLL, e neppure mi aspettavo che emergesse tale 
problema.
Se qualcuno ne sa qualcosa, lo ringrazio delle info.
NEl frattempo vado a farmi del male con delle callback e 
cercando di vedere se riesco a allocare memoria altrove e 
passarla dentro e fuori.
ciao
Soviet

 ma non so dove dovrebbe essere n� chi dovrebbe produrlo.
Il mio mononeurone dice che potrebbe essere roba che
gli serve per i messaggi di debug, e che potrebbe essere
referenziato all'interno della DLL stessa.
Che, tra parentesi �... che roba � ?
Vabe', premesso che:
1) non ho capito un apascio (cit.) di quanto stai cercando di fare :-D
2) non mi assumo alcuna responsabilit� per quello che sto per scrivere
3) se non sei d'accordo col punto 2 puoi anche chiudere il post
4) se ti esplode il computer ricordati i punti 2 e 3... :-P
...dicevo, hai provato a guglare ? Io ho visto questo:
http://www.ce.uniroma2.it/~martone/libmmvbr/internals_8h-source.html
Magari serve a qualcosa, magari no. E ricorda la premessa :-)
Bye, G.

On 21 Ago, 13:06, Soviet_Mario <Sov...@MIR.CCCP> wrote:
...
io credo che il file internals.h abbia le firme delle "robe" che usi
nella dll in c++
gli servono al debug di Vstudio per sapere che cavolo c'è in quella
dll.
Almeno parrebbe a vedere ciò che fanno da altre parti!
seguendo il link di paperino
http://www.ce.uniroma2.it/~martone/libmmvbr/internals_8h.html#_details
và che roba!
....Ma perchè con questo caldo vi fate tutte queste seghe
menatali???!!!...sigh! :o)

 definizione, perch� ricorda una cosa reale
Lo so :-P
Anche se ad esser buoni il mio potrebbe essere al massimo
un cicloneurone ;-)
Bye, G.