[libs] borland/Visual C++

Recherche :

Dernière réponse

Sujet : [libs] borland/Visual C++

BENB

robUx4 a écrit a écrit :

Bon, alors si tu veux jouer sur les mots, explique moi l'interet de ta première réponse...

Pour son problème s'il a les sources et qu'il veut mettre des objets dans sa DLL (du C, ca passe sans problème) alors il a la solution COM de Microsoft.

S'il n'a pas les sources, je pense qu'il a pas d'autre choix que d'utiliser le compilateur qui a fait le .lib/.dll. En tout cas si cette DLL file des objets, parce que si c'est du C (en tout cas un langage pas objet) il peut faire le LoadLibrary/GetProcAddress à la main. (mais à priori ca marche pas)

L'interet d'une discution c'est que l'on recoit des infos au fur et a mesure... dans ma premiere reponse je ne savait pas qu'il n'avait pas les sources, mais la suite de la discution me laisse supposer qu'il n'en dispose pas...
Et on revient sur le point initial, si la Dll a ete compilee par C++ Builder comme du C++ il y a un probleme de decorations meme si ce ne sont que des fonctions C...
point final.

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

BENB

robUx4

Bon, alors si tu veux jouer sur les mots, explique moi l'interet de ta première réponse...

Pour son problème s'il a les sources et qu'il veut mettre des objets dans sa DLL (du C, ca passe sans problème) alors il a la solution COM de Microsoft.

S'il n'a pas les sources, je pense qu'il a pas d'autre choix que d'utiliser le compilateur qui a fait le .lib/.dll. En tout cas si cette DLL file des objets, parce que si c'est du C (en tout cas un langage pas objet) il peut faire le LoadLibrary/GetProcAddress à la main. (mais à priori ca marche pas)

BENB

robUx4 a écrit a écrit :

Donc n'importe quel compilo peut générer un objet COM dans une DLL et ca sera exloitable par n'importe quel autre compilo, non ? C'est bien ce qu'il cherche à faire...

Je te laisse l'entiere responsabilite de tes dires...
Quand un phrase commence par n'importe....

Quand a ce qu'il cherche a faire je ne pense pas que ce soit cela.
Je pense plutot qu'on lui a file une Dll, le Lib et les .h qui vont bien, et maintenent demerde toi coco (ou cocotte :D)...
Je suppose qu'il n'a donc aucun moyen de modifier cette Dll qui n'est pas COM...

robUx4

BENB a écrit a écrit :

Desolee d'insiter, deux compilo C++ sont forcement incompatbile entre eux, meme si il produisent des binaires pour la meme plateforme. Si vous voulez de la compatibilite il faut passer par du C.
Apres il y a peu-etre differents formats de libs... (etonnant mais bon...)

Pour COM, un objet COM (ou Corba) suit les regles de nommage et d'appel de COM (ou Corba) et non du C++. Ces objets (COM) ne sont pas ecrits dans la base, c'est leur ID unique qui l'est... avec la position de la DLL sur le disque...

Donc n'importe quel compilo peut générer un objet COM dans une DLL et ca sera exloitable par n'importe quel autre compilo, non ? C'est bien ce qu'il cherche à faire...

koulip31

a pas l'air ... visual me chie un cake avec cette lib Borland ....

et comme c'est une lib bloups ..... pour chopper les sources je peux tj courrir et la trouver compilé sous visual aussi je peux me toucher...

pfff ... saloperie vas WC++ :gun:

seblamb

Il y a 2 formats de lib sous windows,

http://www.metagraphics.com/metawi [...] faq030.htm

Normallement le Visual sais lire le 2 formats.

BENB

robUx4 a écrit a écrit :

Nan ! Avec COM tu mets des objets dans une DLL, tu les déclares à Windows (qui va les écrire dans la base de registre) et ensuite tu peux les utiliser dans n'importe quelle appli ! C'est du code objet dans une DLL qui peut être partagé entre tous les langages qui permettent de faire du COM (c++, VB, java, etc).

Peut-être que Corba fait de même mais c'est bcp moins courrant sous Windows...

DCOM est une copie de Corba... en qq sortes...

Desolee d'insiter, deux compilo C++ sont forcement incompatbile entre eux, meme si il produisent des binaires pour la meme plateforme. Si vous voulez de la compatibilite il faut passer par du C.
Apres il y a peu-etre differents formats de libs... (etonnant mais bon...)

Pour COM, un objet COM (ou Corba) suit les regles de nommage et d'appel de COM (ou Corba) et non du C++. Ces objets (COM) ne sont pas ecrits dans la base, c'est leur ID unique qui l'est... avec la position de la DLL sur le disque...

robUx4

BENB a écrit a écrit :

De plus le probleme ne viens pas de l'OS ni de la Dll, mais bien du langage, deux compilos C++ ne sont pas compatibles entre eux. Meme si il avait eu une lib statique .lib, il aurrait eu le meme probleme...

Nan ! Avec COM tu mets des objets dans une DLL, tu les déclares à Windows (qui va les écrire dans la base de registre) et ensuite tu peux les utiliser dans n'importe quelle appli ! C'est du code objet dans une DLL qui peut être partagé entre tous les langages qui permettent de faire du COM (c++, VB, java, etc).

Peut-être que Corba fait de même mais c'est bcp moins courrant sous Windows...

robUx4

seblamb a écrit a écrit :

Il y a deux formats de lib dans windows. Borland fournis un utilitaire qui permet de convertir les lib microsoft en lib Borland. C'est COFF2OEM.EXE
Je ne sais pas si ça marche dans le sens inverse.

Non Microsoft est fermé au monde extérieur ;)

seblamb

Il y a deux formats de lib dans windows. Borland fournis un utilitaire qui permet de convertir les lib microsoft en lib Borland. C'est COFF2OEM.EXE
Je ne sais pas si ça marche dans le sens inverse.

koulip31

pourtant ct borland C++

donc jais une lid en C++ et une dll en C++

pourtant le hic visual lui nent veux pas
comment utiliser soit ma dll soit ma lib ...; je men fout je veux utiliser les fonction ki as dedans .....

un trucc ca doit etre possible!!!!!
sinon ce serrait trop zarb
2compilot sous win incompatibles entre eux :(

BENB

robUx4 a écrit a écrit :

Je précise quand même que sous Windows pour partager des objets il y a COM/DCOM... (qui sont en général dans des DLL)

Et corba... qui lui n'est pas propre a Windows...
...
De plus le probleme ne viens pas de l'OS ni de la Dll, mais bien du langage, deux compilos C++ ne sont pas compatibles entre eux. Meme si il avait eu une lib statique .lib, il aurrait eu le meme probleme...

robUx4

Je précise quand même que sous Windows pour partager des objets il y a COM/DCOM... (qui sont en général dans des DLL)

robUx4

C clair. Les DLL c'est fait pour le C, pas le C++.
C'est là qu'on voit que Windows date un peu (système pas objet)...

Vivement les générations d'OS en objet !

BENB	Si c'est cas desespere tuy peut esayer de chercher les noms decores dans la Dll avec dependency Walker, puis de les reporter dans GetProcAdress... Mais le plus simple serait de compiler la Dll autrement...

koulip31

mci cest bien ce que je pensait mais me demmandais si je pouvais pas tapper en brut dans la dll (sens fout du compilo elle) comme mon .lib lui me chie des cakes :o

:cry: :cry: chi po dans la merdeuuuuuuuu :cry: :cry:

---
vais me suicider..... kkn aurais une rape a gruyer ? :cry:

BENB	Je me permet de te donner ce liens vers une discution interessante, et pas tres eloignee de ton propos... http://forum.hardware.fr/sqlforum/ [...] &owntopic=

BENB

Ton idee me parait difficile a realiser...

Qu'exportes/importes tu dans ta Dll...

Si le compilo n'est pas le meme n'espere pas recuperer les fonctions C++, c'est a dire celles qui ne sont pas declaree en extern 'C', STDCALL ou ce genre de chose, ainsi que les membres de classes...

Les compilo C++ ajoutent des decorations pour memoriser les types des parametres ou le nom de l'objet auquel appartiens la methode. Or ces decorations ne sont pas normalisees. Donc Borland et Microsoft ne peuvent pas utiliser les memes...

Ceci dit ton idee est valable si tu utilise le meme compilo de chaque cote.
Ou si tu utilise des interfaces C strictement, non objet
Ou si tu utilise une interface COM/DCOM/Corba donc objet...

koulip31

:bounce:

koulip31

oki comme mon .lib foire vais utliliser la seconde

mais comment ca marche la fonction GetProcAddress()
car dans le msdn il montre un exemple utilisant cette fonction et ca men dit pas grand chose

pDllGetVersion = (DLLGETVERSIONPROC)GetProcAddress(hinstDll,TEXT("DllGetVersion" ));

pDllGetVersion : variable ou stocker le nr° de vertion ou son pointeur (son pointeur serrait plus logique).

(DLLGETVERSIONPROC) : ????? a koi ca sert ????

hinstDll : pointeur retourné par loadlibrary

TEXT("DllGetVersion" ) : ca je pense que c'est pour aller chercher la vertion de la dll.

donc moi si je veux utiliser la fonction toto qui se trouve dans ma_dll.dll je fait comment?

pointeur_toto = GetProcAddress(pointeur_ma_dll,TEXT("toto" ));

et apres?

youdontcare

soit tu linkes avec un .lib, soit tu fais un loadlibrary() et tu choppes les procs avec GetProcAddress(). mais pas les deux à la fois ... et si ton .lib foire utilise la deuxième solution.

koulip31

voila mon pb

jai une dll et le .lib corespondant
le tout a ete copmile sous borland C++ builder

le hic moi chi sou VC++
quand je link le .lib a mon prog
et je compile il me dit que le fichier est illisible ou corompu

pour la dll je fait un:
loadlibrary("ma_dll.dll" );

le link dans option de linkage:
ma_dll.lib

il y il un truc pour corriger ca?
si oui HELPPPPPP ce'est URGENT