Newsgroup: it.comp.programmare.win32
Titolo: Ho fatto bene ad abbandonare Microsoft!!!

Ciao, il thread, per chi non lo sà
è l'ennesimo fork sulle DLL.
Ho deciso di crearne uno nuovo per sottolineare
che i tool di sviluppo Microsoft sono per il cesso!
(non è per generare un flame)
Per chi ha seguito la vicenda delle DLL, ha visto il
combattimento che ho fatto! BENE:
Ho creato un progetto DLL con un compilatore SERIO,
cioè CBuilder e in non meno di 5 min. ho convertito
la mia dll e fatta FUNZIONARE in VB senza nessun tipo
di errore (usando __stdcall che, ricordo qui, con il caro VC causava
nessun punto di ingresso nella dll sotto VB!!!)
Ovviamente adesso la mia dll non funziona in un programma fatto in VC
ma SOLTANTO perchè la libreria di importazione (.lib) non è nel formato
che a VC piace (come sempre l'interoperabilità per Microsoft non è una
parola conosciuta nel suo vocabolario!).
P.S. se qualche anima pia sa come creare una .lib compatibile con VC ne 
sarei grato. Perchè la vecchia strada l'ho abbandonata per ovvi motivi.
Ciao a tutti

 
Non fai prima a portare pure l'exe su borland, a questo punto?
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 Oppure portare il tuo progetto sul compilatore borland.
Volevo fare una libreria compatibile anche per VC

 [cut]
ehm... sono senza parole...   -___-'''
scusa, secondo te in Visual C++ 6 (che esiste da circa 7 anni ormai) non è
possibile creare una DLL, un EXE, e importare simboli nell'EXE dalla DLL?
ti dico subito che sicuramente hai sbagliato tu perché io l'ho fatto mille
volte senza problemi sia in C che in C++.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 volte senza problemi sia in C che in C++.
come non detto: leggo che il problema ora era Visual Basic, non piů Visual
C++; in tal caso sbagli a dire che "i prodotti Microsoft sono da buttare
al cesso"; anzi no, non sbagli: i prodotti Microsoft (Visual Basic) sono
effettivamente da buttare al cesso, ma quelli ex-Lattice (Visual C++) se
permetti sono oro zecchino.
non capisco come mai volevi usare Visual Basic.


 che i tool di sviluppo Microsoft sono per il cesso!
Io voto per il fatto che il cesso in programmazione sia AlterX... ;)
PS: migliaia di aziende informatiche nel mondo basano il loro lavoro sui tool 
di sviluppo M$... Quindi vedi tu... :-P
-- 
Luc

 parola conosciuta nel suo vocabolario!).
Scusa, ma i .lib sono diversi da compilatore a compilatore, am ogni
compilatore ha un tool per cui data una DLL puoi ottenere il lib (implib o
qualcosa del genere).
Comunque, malgrado io non usi prodotti Microsoft, dubito fortemente che il
problema sia loro. Consiglio un bel ripasso di questi prodotti prima di
sputarci sopra, visto che qulche decina di persone :-) li usano e non ho mai
sentito problemi tipo questi.
Ciao, Enrico

 Volevo fare una libreria compatibile anche per VC
Per fare un DLL compatibile con tutti e sottolineo tutti i tool/linguaggi è
consigliato utilizzare stdcall e extern C, usando ovviamente parametri
compatibili con il C. Non serve altro. Per importare le funzioni nei vari
tool/linguaggi e quant'altro basta leggersi il manuale :-)
Ciao, Enrico
PS: ora qualcuno avrà da ridire sul tutti. Avanti i flames.

 seguente.
E certo che brancolo nel buio!! Come dici anche tu nella frase 
successiva, per libreria standard usare stdcall e extern C, è tutto
quello che utilizzo, oltre ovviamente al C puro!!

 
Non credere tanto nella loro perfezione, perchè non lo sono!
Non ho bisogno di ripassare un bel nulla, perchè, come già detto, gli 
STESSI sorgenti compilati con CBuilder anzicchè VC con le stesse 
impostazioni (stdcall ed extern C), FUNZIONANO perfettamente in CBuilder
(ovviamente), in VB (*CON LO STESSE DECLARE*) e in VC (con caricamento 
dinamico!).
Vedi tu, ora, se sbaglio io o il compilatore nel creare la DLL *con 
queste determinate condizioni di progetto*.
Cavolo ho creato una dll con il wizard, esportata una stupida funzione
che prende un parametro, e non funziona in VB!! Ma per favore...

 
Potrei fare una lista di malfunzionamenti in VC, che forse le migliaia 
di aziende nei loro progetti, per fortuna loro, non hanno mai simulato!
Altrimenti spiegami perchè gli stessi sorgenti compilati però in un 
progetto CBuilder, anzicchè VC, funziona perfettamente in VB, CBuilder e 
VC???

 
IO VOGLIO CREARE UNA LIBRERIA CHE "FUNZIONI" IN QUALSIASI IDE,
sia esso VB, sia VC, sia CBuilder, o altro...
A quando pare, se uso VC, funziona SOLO in VC.
Se uso CBuilder, funziona in CBuilder, VB e VC (con caricamento 
dinamico, finchè Microsoft si degnerà di rendere leggibile anche la .lib 
creata da Borland).
Come vedi non sono io che sbaglio, e sembra che il CBuilder funzioni 
meglio del VC!!

 
Come mai?!?

 Microsoft...
Non è più Inprise da tempo, è tornata ad essere Borland.
-- 
Borland C++ Builder Mailing List:
http://tux.linuxtime.it/mailman/listinfo/bcb-it

 valore ordinale anzicchè il nome della funzione.
Non proprio, leggiti la parte relativa a EXPORTS e vedrai che le cose non
stanno proprio cosí.
Ciao, Enrico

 ad ora con il VC.
Comunque qui c'è il link che spiega la procedura da seguire:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_calling_dll_functions_from_visual_basic_applications.asp
 

 proprio :-( 
Ha ragione sicuramente...ma ho provato anche l'inclusione di .def e il
problema non si è risolto.

 adesso Delphi si è dato al dotNET... :D


 San Borland aiutaci tu...! :-)
Se non sbaglio la decorazione dipende dalla dimensione in byte degli 
argomenti, quindi, a meno di modificarli resta sempre la stessa.
Comunque, per il .DEF (ripeto che non l'ho mai usato, quindi..) puoi fare 
due prove, una usando il nome normale e poi quello decorato.
EXPORTS
messaggio=messaggio
poi
EXPORTS
messaggio=_messaggio@4
eventualmente, nel primo caso, se non accetta lo stesso nome gliene dai uno 
diverso 

 
Non credo che funzioni, perchè al tempo ho provato anche includendo il 
file .def! Ricordi?? qualcuno disse che si comportava come se lo ignorasse!
E poi il file .def viene utilizzato per esportare le funzioni con il 


 meglio del VC!!
solo perché legge un formato di lib in più rispetto al VC; se Microsoft ha
deciso di non leggerlo (sempre che sia vero, visto che non ho provato di
persona) avrà i suoi (forse biasimevoli) motivi; sempre un'azienda è.



Non credo si possa fare, a meno di qualche trucco strano.
La decorazione, nonostante extern "C", in __stdcall è un metodo per 
prevenire il richiamo di funzioni che devono essere per forza __cdecl, es. 
printf(), cioè quelle che hanno parametri variabili e per cui la rimozione 
dello stack deve avvenire dal chiamante.
L'unica soluzione è usare la dichiarazione, in VB, con la decorazione in 
questo modo:
Private Declare Function funzioneRipulita Lib "tuaDLL.DLL" _
        Alias _fzInDLL@x _
        ........
        ecc.
Non so se è un'idea solo della Microsoft, sembra che Borland non la utilizzi 
visto che non hai avuto problemi

 PS: eccoti un Dll Viewer 
http://www.nirsoft.net/utils/dll_export_viewer.html
gli è già stato consigliato il Dependency Walker, ma credo che non gliene
freghi niente :(
comunque caro AlterX non credere di aver realmente abbandonato Microsoft:
io ero rimasto che Microsoft possedeva un buon pezzo di Borland (mi sembra
10%), poi non so come si sia aggiornata la situazione, però visto che
adesso Delphi si è dato al dotNET... :D


 


 
Ci avevo pensato anche io di fare una cosa del genere...ma ti 




 compilazione (vedrai che anche il Builder avrà il suo bel flag settato).
Ho già provato il .def e non funziona; ho setacciato completamente le
impostazioni di progetto del VC e non ho trovato nulla;
non ho impostato nulla di particolare in CBuilder...ed ha funzionato tutto!!
Scusa...prova tu a fare una semplice DLL con il wizard di VC e poi
prova ad usarla in VB. Se riesci a farla funzionare, mi passi il 
progetto così come è, e lo provo sulla mia macchina. Più prova del
nove così!!!

 che prende un parametro, e non funziona in VB!! Ma per favore...
Appunto, ma per favore....
Ciao, Enrico


 nove così!!!
Non uso VC quindi la prova del nove non la posso fare.
In mingw ho fatto un file .def dove negli EXPORTS ho messo le funzioni con
il nome come lo voglio io: il linker mi da un warning che dice che la mia
funzione _pippo@4 è stata esportata come pippo.
Ecco cosa ho trovato da una veloce ricerca:
Microsoft's mangling of __stdcall function names is undone when the symbol
name appears in the export table of a DLL.
e ancora
As far as the linker names are concerned, Borland and Microsoft compilers
disagree on the scheme that is used to generate the linker name. For
example, the Microsoft Visual C++ compiler sometimes decorates exported
__stdcall functions, while the Borland C++ Builder expects that only
imported __cdecl functions be decorated.
infine
http://www.codeproject.com/dll/XDllPt2.asp
Key Concepts
  a.. To avoid name-mangling problems and having to Alias function names in
VB, use module definition (.DEF) files.
  b.. When using .DEF files, it is not necessary to use
__declspec(dllexport) or __declspec(dllimport).
  c.. Use __stdcall for functions that are called by VB.
  d.. DLLs implemented with .DEF files can be called by both VC++ and VB
programs (without needing to use Alias).
Mi sembra ci sia tutto.
Ciao, Enrico

 extern?!?!
Con extern hai chiesto un'altra cosa, linkage C. Per eliminare il mangling
di __stdcall usa il file .DEF oppure scopri come farlo con qualche flag di
compilazione (vedrai che anche il Builder avrà il suo bel flag settato).
Ciao, Enrico

 VC???
dipende dai sorgenti; non ho seguito le tue discussioni fino in fondo (mi
sono perso :P), ma la probabilità che la colpa sia tua è molto elevata.


 Ciao, Enrico
Grazie a tutti per l'interessamento, ma francamente dopo tutti
questi problemi, penso che userò il CBuilder quando posso...
Oltretutto ho convertito il programma in VC, servendomi della
stessa dll fatta con il cbuilder, usando le librerie dinamiche
e tutto funziona alla grande!
Ciao

 Steve.


> Non credo si possa fare, a meno di qualche trucco strano.
Module-Definition file (.DEF) incluso nel progetto. Non credo 


 che i tool di sviluppo Microsoft sono per il cesso!
Ti rispondo da persona che in passato ha avuto il medesimo problema...
Il problema non è l'ambiente che fa schifo (si potrebbe fare un 
ragionamento su alcuni bug.. ma non su tutto il sistema).. e che tu 
sbagli qualcosa.
Ora, se tu cortesemente ci vorresti far dono sia del file DEF che hai 
utilizzato per esportare il file, sia del file di intestazione della tua 
libreria (con tanto di DllMain) si potrebbe fare un ragionamento su come 
risolvere il problema.. piuttosto che su come aggirarlo (perchè ci sarà 
il giorno in cui avrai realizzato un compilato con il borland che non 
riuscirai ad utilizzare in altri sistemi..)
Saluti
Antonio

 _Messaggio@4 anzicchè Messaggio
è normale, quello è il nome decorato secondo la convenzione stdcall: un
underscore prima del nome e il nome seguito da una chiocciola col numero
di bytes da usare per i parametri.


 valore ordinale anzicchč il nome della funzione.
non č vero, riguardati meglio la documentazione.
l'ordinale accanto ai nomi dei simboli esportati puoi anche ometterlo.


 nove cosě!!!
io questa cosa non potrei fartela perché non ho Visual Basic, ma se cerchi
con Google in questo stesso NG troverai miliardi di casi di persone che
lavoravano importando in VB funzioni da una DLL fatta in VC, tutto senza
problemi.
comunque se vuoi ti posso fare una prova di importazione da VC a San
Delphi.


 riuscirai ad utilizzare in altri sistemi..)
Io non ho aggirato un bel niente!!! Ho semplicemente creato un nuovo 
progetto in CBuilder ed ha funzionato a dovere...
Per il file .del, o intestazione della libreria, basta che crei una DLL
con il wizard di VC e inserisci una funzione che prende un parametro
puntatore a char...nulla di più semplice e soprattutto di automatizzato!

Potrei fare una lista di malfunzionamenti in VC,
i malfunzionamenti esistono ovunque, da microsoft a solaris a linux,
sia in prodotti commerciali che open source.
Semplicemente sta tutto nella pazienza di un programmatore l'evitare i
problemi o prevedere le soluzioni meno drastiche in caso se ne
verifichi uno che non puo' essere sistemato.
-- 
Scritto da Gordon
E-mail: tbeqba@_EVZHBIVZV_avpu.vg

 verifichi uno che non puo' essere sistemato.
Infatti: ho usato il C++Builder!

open source: la velocità con cui i malfunzionamenti vengono risolti!!
certo. Io mica stavo difendendo i prodotti commerciali (anzi, da un
prodotto commerciale ci si dovrebbe aspettare di piu' visto che lo
paghi).


 Infatti: ho usato il C++Builder!
da come scrivi sembra che C++ Builder sia open source; oppure che
semplicemente ti sta antipatica solo Microsoft. e tra parentesi alla fine
quella lista di malfunzionamenti mica ce l'hai fatta, eh?


 quella lista di malfunzionamenti mica ce l'hai fatta, eh?
Già che il VisualC++ nella versione 4, e non penso sia cambiato qualcosa 
fino alla 6, era considerata dai massimi esperti come violatrice dei
paradigmi della OOP, la dice tutta...altro che malfunzionamenti!
Altro malfunzionamento lo hai visto ora con il mio problema, e non dire
che è politica della Microsoft (visto che non è uno standard __sdtcall) 
perchè fare tutto sto casino per far funzionare una semplice dll in un 
progetto VC e soprattutto VB non mi
sembra una bella cosa (visto che con il CBuilder non ho dovuto menarmela 
  con il .def e soprattutto non ho dovuto aprire la dll per vedere i
nomi esportati e creare gli alias appropriati in VB: alla faccia della
produttività!! se un giorno aggiungo qualche parametro (anche 
opzionale), devo rivedere tutti i nomi delle funzioni modificate!!!)

 opzionale), devo rivedere tutti i nomi delle funzioni modificate!!!)
hai ragione a lamentarti di questo macello, ma non devi lamentarti con
Microsoft, devi lamentarti solo con te visto che sto casino non mi risulta
sia mai capitato a nessun altro.


 sia mai capitato a nessun altro.
Mah... forse perchč gli altri non hanno avuto la mia stessa sfortuna?!?
o forse perchč non lo hanno denunciato come ho fatto io, ma hanno 
risolto silenziosamente come anche io ho fatto (o usando altre 
alternative)?!?
chissą...forse perchč la gente si fida ancora di Microsoft o forse 
perchč crede ancora che Microsoft faccia anche gli interessi degli 
utenti!?!?

il fatto che siano usato non vuol dire che siano buoni! Britney Spears
è una delle cantanti che vende di più ma non vuol dire che fa musica
di qualità anzi.... ;)

 utenti!?!?
Se non ti piace non hai che da non usarlo. Non sei obbligato, ma non venirti 
a lamentare di cose che non esistono.
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

 open source: la velocità con cui i malfunzionamenti vengono risolti!!
Questa è un'altra favola che non ha fondamento.
Ci sono tonnellate di progetti open source da anni fermi con nessuno che li 
porta avanti.
D'altra parte ci sono le security patch che Microsoft butta fuori che 
arrivano *prima* che qualcuno usi quella vulnerabilità. E infatti oggi 
virus, worm e quant'altro derivano per lo più da un'operazione di analisi 
delle patch create da Microsoft. È molto più semplice capire il problema da 
10K di codice piuttosto che da qualche milione.
Peccato che gli update siano in pochi a curarsi di farli.
Le patch nei prodotti commerciali (non solo Microsoft) vengono buttate fuori 
con delle priorità che dipendono dalla gravità. Se esiste un workaround 
(vedi KB sul sito) la patch viene posticipata alla SP.
Insomma le cose sono ben più complesse e liquidarle con questa semplicità è 
un'approccio superficiale.


 che riuscirai a trovarne uno che dia maggiore produttività.
ma che scherzi?? lui usa Borland C++ Builder!!! ;)
(ammecojoni!!! :D)


 il fatto che siano usato non vuol dire che siano buoni!
Dai, torna ad usare KDevelop... :-P 
-- 
Luc

 A quando pare, se uso VC, funziona SOLO in VC.
Usa il file .def
Alcuni linker hanno problemi con nomi di funzione del tipo
_nomeFunzione@16
che e' quello che viene esportato usando __declspec(dllexport)
Usando il file .def i nomi di funzione vengono esportati cun un
nome del tipo
_nomeFunzione
Questo elimina tutti i problemi.
HTH
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Peccato che gli update siano in pochi a curarsi di farli.
:-)


 Questo elimina tutti i problemi.
DevCpp elimina tutti i problemi!!
Ho compilato la libreria con mingw e oltre ad essere la metà di 
dimensione, mi crea gli alias all'interno stesso della dll...
è fantastico!! :-)

 ho nient'altro da fare" i virus erano totalmente assenti....
ROTFL :-)


 è fantastico!! :-)
addirittura meglio del BCB?!? naaa, non ci posso creeedereee...


 sorgente.
Vengono denunciati i furbi, non quelli che rispettano la licenza.
Le licenze Open Source hanno ti danno la liberta' di imparare
guardando il codice che coprono. Io sono personalmente debitore a
parecchi sorgenti Open Source (GPL e BSD in particolare) per quello
che conosco di C.
Guardare e non toccare... La visione e' gratuita, il "riciclo" del
codice no (o non sempre). Come e' giusto rispettare la licenza che
accompagna il prodotto X della ditta Y con licenza Z e' anche
sacrosanto rispettare la GPL: Open Source non e' (sempre) sinonimo
di "prendi e porta a casa".
Se qualcuno si e' "scottato" usando in maniera troppo disinvolta del
codice GPL la colpa e sua, non della GPL.


 dimensione,
Amen. Se ti trovi bene con Dev-cpp, ok. Ma il tuo problema si
risolveva anche con VC++.


 risolveva anche con VC++.
Certo che si risolveva, ma con file .def, alias e pippe varie!!!
con CBuilder e DevCpp, non uso ne .def ne alias...in più l'ultimo
è free of charge!!!

 Certo che si risolveva, ma con file .def, alias e pippe varie!!!
???
Un file di testo con scritto dentro il nome da esportare e'
una "pippa varia"? :-)


 una "pippa varia"? :-)
Gli alias per VB!!!
e cmq non vedo perchč non usare la strada piů semplice, anzicchč
farsi tanti inutili problemi!

 codice GPL la colpa e sua, non della GPL.
Daccordissimo.
