Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en delphi !!!
J'utilise la commande lib.exe pour produire un .lib depuis un .def ;
La preuve est ici = http://sivallerstatic.no-ip.org/test.zip
Le compilo me produit l'erreur :
test.obj : error LNK2001: unresolved external symbol "unsigned char
__stdcall retourne5(void)" (?retourne5@@YGEXZ)
Debug/test.exe : fatal error LNK1120: 1 unresolved externals
On peux toujours utiliser Loadlibrary mais c'est bas niveau ;
Je suis gentil : le compilo MSVC bug rarement de ce faites que je n'ai pas
ENCORE rencontrer d'exception lorsque je compile mes projets comme (X86WD,XC
etc.)
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en delphi !!!
J'utilise la commande lib.exe pour produire un .lib depuis un .def ;
La preuve est ici = http://sivallerstatic.no-ip.org/test.zip
Le compilo me produit l'erreur :
test.obj : error LNK2001: unresolved external symbol "unsigned char
__stdcall retourne5(void)" (?retourne5@@YGEXZ)
Debug/test.exe : fatal error LNK1120: 1 unresolved externals
On peux toujours utiliser Loadlibrary mais c'est bas niveau ;
Je suis gentil : le compilo MSVC bug rarement de ce faites que je n'ai pas
ENCORE rencontrer d'exception lorsque je compile mes projets comme (X86WD,XC
etc.)
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en delphi !!!
J'utilise la commande lib.exe pour produire un .lib depuis un .def ;
La preuve est ici = http://sivallerstatic.no-ip.org/test.zip
Le compilo me produit l'erreur :
test.obj : error LNK2001: unresolved external symbol "unsigned char
__stdcall retourne5(void)" (?retourne5@@YGEXZ)
Debug/test.exe : fatal error LNK1120: 1 unresolved externals
On peux toujours utiliser Loadlibrary mais c'est bas niveau ;
Je suis gentil : le compilo MSVC bug rarement de ce faites que je n'ai pas
ENCORE rencontrer d'exception lorsque je compile mes projets comme (X86WD,XC
etc.)
Plus qu'un seul, AMHA. VC 6 est antédiluvien.
Plus qu'un seul, AMHA. VC 6 est antédiluvien.
Plus qu'un seul, AMHA. VC 6 est antédiluvien.
Je te l'ai dit dans un autre post ça n'est pas possible.
Ce qui se fait avec C++Builder se fait parce que Borland a créé des
extensions à C++ spécialmeent pour ça.
Ces extensions n'existent pas dans VC et c'est normal, elle n'auraient
rien à y faire.
Je te l'ai dit dans un autre post ça n'est pas possible.
Ce qui se fait avec C++Builder se fait parce que Borland a créé des
extensions à C++ spécialmeent pour ça.
Ces extensions n'existent pas dans VC et c'est normal, elle n'auraient
rien à y faire.
Je te l'ai dit dans un autre post ça n'est pas possible.
Ce qui se fait avec C++Builder se fait parce que Borland a créé des
extensions à C++ spécialmeent pour ça.
Ces extensions n'existent pas dans VC et c'est normal, elle n'auraient
rien à y faire.
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en delphi !!!
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en delphi !!!
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en delphi !!!
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en
delphi !!!
Je te l'ai dit dans un autre post ça n'est pas possible.
Ce qui se fait avec C++Builder se fait parce que Borland a
créé des extensions à C++ spécialmeent pour ça.
Ces extensions n'existent pas dans VC et c'est normal, elle
n'auraient rien à y faire.J'utilise la commande lib.exe pour produire un .lib depuis un .def ;
La preuve est ici = http://sivallerstatic.no-ip.org/test.zip
Le compilo me produit l'erreur :
test.obj : error LNK2001: unresolved external symbol "unsigned char
__stdcall retourne5(void)" (?retourne5@@YGEXZ)
Debug/test.exe : fatal error LNK1120: 1 unresolved externals
Ce n'est pas le compilo, mais l'éditeur de lien qui t'envoie paître.
On peux toujours utiliser Loadlibrary mais c'est bas niveau ;
Sauf qu'à cause des conventions d'appel Pascal (i.e Delphi) ça
ne marchera directement sauf à utiliser explicitement une
autre convention d'appel que celle de C côté VC. Et si tu
essaies d'instancier une classe Delphi, ça ne marche pas du
tout, en aucun cas.
Je suis gentil : le compilo MSVC bug rarement de ce faites
que je n'ai pas ENCORE rencontrer d'exception lorsque je
compile mes projets comme (X86WD,XC etc.)
Je suis gentil: tu es surmené et tu devrais te reposer un peu
les méninges. Tu y verras plus clair après une bonne sieste :)
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en
delphi !!!
Je te l'ai dit dans un autre post ça n'est pas possible.
Ce qui se fait avec C++Builder se fait parce que Borland a
créé des extensions à C++ spécialmeent pour ça.
Ces extensions n'existent pas dans VC et c'est normal, elle
n'auraient rien à y faire.
J'utilise la commande lib.exe pour produire un .lib depuis un .def ;
La preuve est ici = http://sivallerstatic.no-ip.org/test.zip
Le compilo me produit l'erreur :
test.obj : error LNK2001: unresolved external symbol "unsigned char
__stdcall retourne5(void)" (?retourne5@@YGEXZ)
Debug/test.exe : fatal error LNK1120: 1 unresolved externals
Ce n'est pas le compilo, mais l'éditeur de lien qui t'envoie paître.
On peux toujours utiliser Loadlibrary mais c'est bas niveau ;
Sauf qu'à cause des conventions d'appel Pascal (i.e Delphi) ça
ne marchera directement sauf à utiliser explicitement une
autre convention d'appel que celle de C côté VC. Et si tu
essaies d'instancier une classe Delphi, ça ne marche pas du
tout, en aucun cas.
Je suis gentil : le compilo MSVC bug rarement de ce faites
que je n'ai pas ENCORE rencontrer d'exception lorsque je
compile mes projets comme (X86WD,XC etc.)
Je suis gentil: tu es surmené et tu devrais te reposer un peu
les méninges. Tu y verras plus clair après une bonne sieste :)
Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0
Impossible de réutiliser sur MSVC une librairie écrit en
delphi !!!
Je te l'ai dit dans un autre post ça n'est pas possible.
Ce qui se fait avec C++Builder se fait parce que Borland a
créé des extensions à C++ spécialmeent pour ça.
Ces extensions n'existent pas dans VC et c'est normal, elle
n'auraient rien à y faire.J'utilise la commande lib.exe pour produire un .lib depuis un .def ;
La preuve est ici = http://sivallerstatic.no-ip.org/test.zip
Le compilo me produit l'erreur :
test.obj : error LNK2001: unresolved external symbol "unsigned char
__stdcall retourne5(void)" (?retourne5@@YGEXZ)
Debug/test.exe : fatal error LNK1120: 1 unresolved externals
Ce n'est pas le compilo, mais l'éditeur de lien qui t'envoie paître.
On peux toujours utiliser Loadlibrary mais c'est bas niveau ;
Sauf qu'à cause des conventions d'appel Pascal (i.e Delphi) ça
ne marchera directement sauf à utiliser explicitement une
autre convention d'appel que celle de C côté VC. Et si tu
essaies d'instancier une classe Delphi, ça ne marche pas du
tout, en aucun cas.
Je suis gentil : le compilo MSVC bug rarement de ce faites
que je n'ai pas ENCORE rencontrer d'exception lorsque je
compile mes projets comme (X86WD,XC etc.)
Je suis gentil: tu es surmené et tu devrais te reposer un peu
les méninges. Tu y verras plus clair après une bonne sieste :)
Est-ce un bogue ? Est-ce que Microsoft dit que ça doit marcher,
Dans le cas de Windows, la situation est un peu plus compliquée,
je crois, parce que (si je ne me trompe pas), l'API système
n'est pas du C pur, mais utilise des extensions Microsoft (type
d'appel, etc.), et parce qu'il existe d'autres API définies par
Microsoft, mais largement supportées par d'autres outils, genre
.COM (et plus récemment .NET). Ça m'étonnerait, par exemple, de
ne pas pouvoir générer un .COM avec Delphi, et de ne pas pouvoir
l'utiliser depuis un programme C++ compilé avec VC++. (Mais
attention : je connais en fait très, très peu de .COM, à part
qu'il existe. Ne te fie donc pas trop à mes dires.)
Est-ce un bogue ? Est-ce que Microsoft dit que ça doit marcher,
Dans le cas de Windows, la situation est un peu plus compliquée,
je crois, parce que (si je ne me trompe pas), l'API système
n'est pas du C pur, mais utilise des extensions Microsoft (type
d'appel, etc.), et parce qu'il existe d'autres API définies par
Microsoft, mais largement supportées par d'autres outils, genre
.COM (et plus récemment .NET). Ça m'étonnerait, par exemple, de
ne pas pouvoir générer un .COM avec Delphi, et de ne pas pouvoir
l'utiliser depuis un programme C++ compilé avec VC++. (Mais
attention : je connais en fait très, très peu de .COM, à part
qu'il existe. Ne te fie donc pas trop à mes dires.)
Est-ce un bogue ? Est-ce que Microsoft dit que ça doit marcher,
Dans le cas de Windows, la situation est un peu plus compliquée,
je crois, parce que (si je ne me trompe pas), l'API système
n'est pas du C pur, mais utilise des extensions Microsoft (type
d'appel, etc.), et parce qu'il existe d'autres API définies par
Microsoft, mais largement supportées par d'autres outils, genre
.COM (et plus récemment .NET). Ça m'étonnerait, par exemple, de
ne pas pouvoir générer un .COM avec Delphi, et de ne pas pouvoir
l'utiliser depuis un programme C++ compilé avec VC++. (Mais
attention : je connais en fait très, très peu de .COM, à part
qu'il existe. Ne te fie donc pas trop à mes dires.)
C'est un bug si (et seulement si) Microsoft dit que ça doit
marcher. (Chose qui m'étonnerait de Microsoft.)
De même, si
Borland dit que la bibliothèque qu'il génère peut servir dans un
programme compilé avec VC++, il y a un bug chez Borland. (En
fait, étant donné la position sur le marché des deux, ça
m'étonnerait un peu de la part de Borland qu'on puisse pas le
faire.
Même sans les extensions : il n'y a pas de API neutre pour le
C++ sous Windows. C-à-d que chaque compilateur a sa propre
organisation de vtable, etc.; ensuite, chaque compilateur
utilise une décoration différente,
pour que le programme échoue
lors de l'édition de liens, plutôt qu'à l'exécution. (C'est qui
expliquera le fait que l'éditeur de liens ne trouve pas le
symbole -- il le cherche avec une décoration à la VC++, or
qu'il est défini avec une décoration à la Borland.)
C'est un point de vue. Quand je fais une édition de liens sous
Windows, c'est bien la commande cl (et non link) dont je me
sers. Du coup, même si la source réele du message d'erreur est
l'éditeur de liens, pour l'utilisateur, c'est bien un message
d'erreur de cl (qui est communement appelé le compilateur, même
si techniquement, on ferait mieux de parler d'un pilote de
compilation).
Je crois (mais je suis loin d'être certain) que la convention
d'appel est reflechie dans la décoration.
Et qu'il faut bien
donner le nom décoré
à GetProcAddr (et dans le fichier .DEF). Et
qu'il y a probablement d'autres restrictions que je ne connais
pas.
(Mais que je ne vais pas tarder à connaître, parce que
parmi les choses en tête de ma liste TODO, c'est porter ma
bibliothèque de gestion UTF-8 à Windows/VC++, et elle utilise le
chargement dynamique.)
Pour être honnête, je me doute un peu du scénario : son chef
lui a donné la bibliothèque Delphi, et lui a dit qu'il y a une
démo devant un client important vendredi, et qu'il faut que ça
marche, parce qu'on a déjà signé le contrat pour le livrer. (Je
l'ai malheureusement trop souvent vu, qu'on signe un contrat
pour réaliser quelque chose de nouveau sans jamais avoir
consulter les techniciens pour savoir si c'était même possible.
Ensuite, évidemment, c'est la faute des techniciens si ça ne
marche pas. Même si ce qu'on a vendu implique la transmission
des données à deux fois la vitesse de la lumière.)
C'est un bug si (et seulement si) Microsoft dit que ça doit
marcher. (Chose qui m'étonnerait de Microsoft.)
De même, si
Borland dit que la bibliothèque qu'il génère peut servir dans un
programme compilé avec VC++, il y a un bug chez Borland. (En
fait, étant donné la position sur le marché des deux, ça
m'étonnerait un peu de la part de Borland qu'on puisse pas le
faire.
Même sans les extensions : il n'y a pas de API neutre pour le
C++ sous Windows. C-à-d que chaque compilateur a sa propre
organisation de vtable, etc.; ensuite, chaque compilateur
utilise une décoration différente,
pour que le programme échoue
lors de l'édition de liens, plutôt qu'à l'exécution. (C'est qui
expliquera le fait que l'éditeur de liens ne trouve pas le
symbole -- il le cherche avec une décoration à la VC++, or
qu'il est défini avec une décoration à la Borland.)
C'est un point de vue. Quand je fais une édition de liens sous
Windows, c'est bien la commande cl (et non link) dont je me
sers. Du coup, même si la source réele du message d'erreur est
l'éditeur de liens, pour l'utilisateur, c'est bien un message
d'erreur de cl (qui est communement appelé le compilateur, même
si techniquement, on ferait mieux de parler d'un pilote de
compilation).
Je crois (mais je suis loin d'être certain) que la convention
d'appel est reflechie dans la décoration.
Et qu'il faut bien
donner le nom décoré
à GetProcAddr (et dans le fichier .DEF). Et
qu'il y a probablement d'autres restrictions que je ne connais
pas.
(Mais que je ne vais pas tarder à connaître, parce que
parmi les choses en tête de ma liste TODO, c'est porter ma
bibliothèque de gestion UTF-8 à Windows/VC++, et elle utilise le
chargement dynamique.)
Pour être honnête, je me doute un peu du scénario : son chef
lui a donné la bibliothèque Delphi, et lui a dit qu'il y a une
démo devant un client important vendredi, et qu'il faut que ça
marche, parce qu'on a déjà signé le contrat pour le livrer. (Je
l'ai malheureusement trop souvent vu, qu'on signe un contrat
pour réaliser quelque chose de nouveau sans jamais avoir
consulter les techniciens pour savoir si c'était même possible.
Ensuite, évidemment, c'est la faute des techniciens si ça ne
marche pas. Même si ce qu'on a vendu implique la transmission
des données à deux fois la vitesse de la lumière.)
C'est un bug si (et seulement si) Microsoft dit que ça doit
marcher. (Chose qui m'étonnerait de Microsoft.)
De même, si
Borland dit que la bibliothèque qu'il génère peut servir dans un
programme compilé avec VC++, il y a un bug chez Borland. (En
fait, étant donné la position sur le marché des deux, ça
m'étonnerait un peu de la part de Borland qu'on puisse pas le
faire.
Même sans les extensions : il n'y a pas de API neutre pour le
C++ sous Windows. C-à-d que chaque compilateur a sa propre
organisation de vtable, etc.; ensuite, chaque compilateur
utilise une décoration différente,
pour que le programme échoue
lors de l'édition de liens, plutôt qu'à l'exécution. (C'est qui
expliquera le fait que l'éditeur de liens ne trouve pas le
symbole -- il le cherche avec une décoration à la VC++, or
qu'il est défini avec une décoration à la Borland.)
C'est un point de vue. Quand je fais une édition de liens sous
Windows, c'est bien la commande cl (et non link) dont je me
sers. Du coup, même si la source réele du message d'erreur est
l'éditeur de liens, pour l'utilisateur, c'est bien un message
d'erreur de cl (qui est communement appelé le compilateur, même
si techniquement, on ferait mieux de parler d'un pilote de
compilation).
Je crois (mais je suis loin d'être certain) que la convention
d'appel est reflechie dans la décoration.
Et qu'il faut bien
donner le nom décoré
à GetProcAddr (et dans le fichier .DEF). Et
qu'il y a probablement d'autres restrictions que je ne connais
pas.
(Mais que je ne vais pas tarder à connaître, parce que
parmi les choses en tête de ma liste TODO, c'est porter ma
bibliothèque de gestion UTF-8 à Windows/VC++, et elle utilise le
chargement dynamique.)
Pour être honnête, je me doute un peu du scénario : son chef
lui a donné la bibliothèque Delphi, et lui a dit qu'il y a une
démo devant un client important vendredi, et qu'il faut que ça
marche, parce qu'on a déjà signé le contrat pour le livrer. (Je
l'ai malheureusement trop souvent vu, qu'on signe un contrat
pour réaliser quelque chose de nouveau sans jamais avoir
consulter les techniciens pour savoir si c'était même possible.
Ensuite, évidemment, c'est la faute des techniciens si ça ne
marche pas. Même si ce qu'on a vendu implique la transmission
des données à deux fois la vitesse de la lumière.)
Et bien tu connais mal Borland et les problèmes qui vont avec
les produits Borland et sur lesquels j'ai tiré un trait depuis
longtemps. (Allez je la lache la phrase: "tu manques un peu
d'expérience dans le domaine ;) )
Je crois (mais je suis loin d'être certain) que la
convention d'appel est reflechie dans la décoration.
Pas nécessairement. Tu dois confondre avec le nombre de
paramètres passés. Ce n'est pas la même chose.
Et ce que tu donnes à GetProcAddr n'est pas "interprété" par
l'API Windows si je puis dire. Si la convention d'appel n'est
pas bonne -> crash.
(Mais que je ne vais pas tarder à connaître, parce que
parmi les choses en tête de ma liste TODO, c'est porter ma
bibliothèque de gestion UTF-8 à Windows/VC++, et elle utilise le
chargement dynamique.)
Ca te donnera un peu d'expérience dans le domaine ;)
Pour être honnête, je me doute un peu du scénario : son chef
lui a donné la bibliothèque Delphi, et lui a dit qu'il y a
une démo devant un client important vendredi, et qu'il faut
que ça marche, parce qu'on a déjà signé le contrat pour le
livrer. (Je l'ai malheureusement trop souvent vu, qu'on
signe un contrat pour réaliser quelque chose de nouveau sans
jamais avoir consulter les techniciens pour savoir si
c'était même possible. Ensuite, évidemment, c'est la faute
des techniciens si ça ne marche pas. Même si ce qu'on a
vendu implique la transmission des données à deux fois la
vitesse de la lumière.)
Tu es bien indulgent ce matin, toi qui disais hier "le
problème est entre l'écran et la chaise" :-)
Sur le fond tu as malheureusement raison.
Et bien tu connais mal Borland et les problèmes qui vont avec
les produits Borland et sur lesquels j'ai tiré un trait depuis
longtemps. (Allez je la lache la phrase: "tu manques un peu
d'expérience dans le domaine ;) )
Je crois (mais je suis loin d'être certain) que la
convention d'appel est reflechie dans la décoration.
Pas nécessairement. Tu dois confondre avec le nombre de
paramètres passés. Ce n'est pas la même chose.
Et ce que tu donnes à GetProcAddr n'est pas "interprété" par
l'API Windows si je puis dire. Si la convention d'appel n'est
pas bonne -> crash.
(Mais que je ne vais pas tarder à connaître, parce que
parmi les choses en tête de ma liste TODO, c'est porter ma
bibliothèque de gestion UTF-8 à Windows/VC++, et elle utilise le
chargement dynamique.)
Ca te donnera un peu d'expérience dans le domaine ;)
Pour être honnête, je me doute un peu du scénario : son chef
lui a donné la bibliothèque Delphi, et lui a dit qu'il y a
une démo devant un client important vendredi, et qu'il faut
que ça marche, parce qu'on a déjà signé le contrat pour le
livrer. (Je l'ai malheureusement trop souvent vu, qu'on
signe un contrat pour réaliser quelque chose de nouveau sans
jamais avoir consulter les techniciens pour savoir si
c'était même possible. Ensuite, évidemment, c'est la faute
des techniciens si ça ne marche pas. Même si ce qu'on a
vendu implique la transmission des données à deux fois la
vitesse de la lumière.)
Tu es bien indulgent ce matin, toi qui disais hier "le
problème est entre l'écran et la chaise" :-)
Sur le fond tu as malheureusement raison.
Et bien tu connais mal Borland et les problèmes qui vont avec
les produits Borland et sur lesquels j'ai tiré un trait depuis
longtemps. (Allez je la lache la phrase: "tu manques un peu
d'expérience dans le domaine ;) )
Je crois (mais je suis loin d'être certain) que la
convention d'appel est reflechie dans la décoration.
Pas nécessairement. Tu dois confondre avec le nombre de
paramètres passés. Ce n'est pas la même chose.
Et ce que tu donnes à GetProcAddr n'est pas "interprété" par
l'API Windows si je puis dire. Si la convention d'appel n'est
pas bonne -> crash.
(Mais que je ne vais pas tarder à connaître, parce que
parmi les choses en tête de ma liste TODO, c'est porter ma
bibliothèque de gestion UTF-8 à Windows/VC++, et elle utilise le
chargement dynamique.)
Ca te donnera un peu d'expérience dans le domaine ;)
Pour être honnête, je me doute un peu du scénario : son chef
lui a donné la bibliothèque Delphi, et lui a dit qu'il y a
une démo devant un client important vendredi, et qu'il faut
que ça marche, parce qu'on a déjà signé le contrat pour le
livrer. (Je l'ai malheureusement trop souvent vu, qu'on
signe un contrat pour réaliser quelque chose de nouveau sans
jamais avoir consulter les techniciens pour savoir si
c'était même possible. Ensuite, évidemment, c'est la faute
des techniciens si ça ne marche pas. Même si ce qu'on a
vendu implique la transmission des données à deux fois la
vitesse de la lumière.)
Tu es bien indulgent ce matin, toi qui disais hier "le
problème est entre l'écran et la chaise" :-)
Sur le fond tu as malheureusement raison.
Si son code Delphi était du COM, (ce qui est envisageable), il
pourrait s'en servir sous VC++. mais en revanche pas en
faisant une édition de liens sous VC++ bien évidemment, mais
en initilisant comme il se doit (API Windows) depuis son code
C++, des composants COM correcement enregistrés sur le
système. Bref, c'est tout autre chose que le problème qu'il a
exposé :)
Si son code Delphi était du COM, (ce qui est envisageable), il
pourrait s'en servir sous VC++. mais en revanche pas en
faisant une édition de liens sous VC++ bien évidemment, mais
en initilisant comme il se doit (API Windows) depuis son code
C++, des composants COM correcement enregistrés sur le
système. Bref, c'est tout autre chose que le problème qu'il a
exposé :)
Si son code Delphi était du COM, (ce qui est envisageable), il
pourrait s'en servir sous VC++. mais en revanche pas en
faisant une édition de liens sous VC++ bien évidemment, mais
en initilisant comme il se doit (API Windows) depuis son code
C++, des composants COM correcement enregistrés sur le
système. Bref, c'est tout autre chose que le problème qu'il a
exposé :)