borland/Visual C++ [libs] - Programmation
Marsh Posté le 03-09-2001 à 17:16:25
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.
Marsh Posté le 04-09-2001 à 10:05:01
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?
Marsh Posté le 04-09-2001 à 14:13:35
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...
Marsh Posté le 04-09-2001 à 14:18:25
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=
Marsh Posté le 04-09-2001 à 14:44:26
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
chi po dans la merdeuuuuuuuu
---
vais me suicider..... kkn aurais une rape a gruyer ?
Marsh Posté le 05-09-2001 à 09:07:26
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...
Marsh Posté le 05-09-2001 à 10:40:14
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 !
Marsh Posté le 05-09-2001 à 10:42:56
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)
Marsh Posté le 05-09-2001 à 15:18:15
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...
Marsh Posté le 06-09-2001 à 11:22:36
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
Marsh Posté le 06-09-2001 à 14:04:17
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.
Marsh Posté le 06-09-2001 à 14:13:42
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
Marsh Posté le 06-09-2001 à 14:16:11
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...
Marsh Posté le 06-09-2001 à 14:58:24
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...
Marsh Posté le 06-09-2001 à 15:29:02
Il y a 2 formats de lib sous windows,
http://www.metagraphics.com/metawi [...] faq030.htm
Normallement le Visual sais lire le 2 formats.
Marsh Posté le 06-09-2001 à 15:52:05
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++
Marsh Posté le 07-09-2001 à 11:05:17
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...
Marsh Posté le 07-09-2001 à 13:28:44
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 )...
Je suppose qu'il n'a donc aucun moyen de modifier cette Dll qui n'est pas COM...
Marsh Posté le 07-09-2001 à 16:10:03
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)
Marsh Posté le 07-09-2001 à 16:20:51
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.
Marsh Posté le 03-09-2001 à 16:54:00
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