bug msvc

On Wed, 6 Sep 2006 19:03:38 +0200, "Sivaller" <sivaller.ni@voila.fr>:

Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0

Plus qu'un seul, AMHA. VC 6 est antédiluvien.

Je vais porter témoignage comme quoi il y a un bug sur MSVC 6.0

Ben voyons....

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 :)

--
Alain

Plus qu'un seul, AMHA. VC 6 est antédiluvien.

Certes :-)
Mais sur ce coup, VC a raison :-)



--
Alain

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 vous crois (7/10)

Sivaller wrote:

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 !!!

Est-ce un bogue ? Est-ce que Microsoft dit que ça doit marcher,
où est-ce que c'est quelque chose qu'il ne supporte pas ? Ou de
l'autre côté, est-ce que Delphi dit qu'il génère des
bibiothèques compatible VC++ ?

En règle générale, tu ne peux melanger des objets ou des
bibliothèques générées par deux produits différents que dans la
mesure où ces produits ont fait des garanties de compatabilité.
Donc, même sans aller jusqu'à une différence aussi extrème que
VC++ et Delphi, sous Solaris, je ne peux pas melanger du code
C++ compilé avec Sun CC avec celui compilé avec g++ ; je peux
melanger du C, en revanche, parce qu'il existe une API C unique
pour la plateforme, que tous les outils respectent.

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.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Alain Gaillard wrote:

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.

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. En revanche, il faudrait probablement des options
spéciales, voire passer par .COM ou quelque chose d'équivalent.)

Ce qui se fait avec C++Builder se fait parce que Borland a
créé des extensions à C++ spécialmeent pour ça.

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.)

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.

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).

Et pour ramener un peu sur le sujet du groupe, je dirais que
c'est le cas de la quasi-totalité des compilateurs : sous
Solaris, j'invoque CC, et non ld, et sous Linux g++, et non ld,
pour faire une édition de liens. Curieusement, ce n'est pas le
cas pour créer des bibliothèques statiques (sauf sous Solaris,
où Sun CC exige l'utilisation de CC, plutôt que ar, pour faire
une bibliothèque statique).

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 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.)

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 :)

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.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Est-ce un bogue ? Est-ce que Microsoft dit que ça doit marcher,

Microsoft ne dit pas que ça doit marcher.

Microsoft ne dit jamais que ça dois 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 exact.

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é :)

--
Alain

C'est un bug si (et seulement si) Microsoft dit que ça doit
marcher. (Chose qui m'étonnerait de Microsoft.)

En effet Micorsoft ne dit rien de tel.

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.

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 ;) )

Moi je me suis arraché les cheveux bien souvent avec. Comme par exemple
le fait qu'ils s'entêtent avec le format OMF au lieu de COFF comme tout
le monde sous Windows.
Cela entraîne que souvent on ne peut pas utiliser du tout une librairie
compilée sous VC++. Il y a bien un outil coff2omf, mais voilà, il ne
fonctionne pas toujours bien. Bref la collaboration VC++ Borland c'est
ni dans un sens ni dans l'autre.

Et puis la position sur le marché de Borland c'est maintenant qu'il
abandonnent Delphi et C++Builder, qu'ils essaient de vendre.

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,

Certes.

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.)

Certes toujours mais je ne pense pas que ça soit son problème en
l'occurence.

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).

Oui bref, c'est donc bien l'éditeur de lien et j'ai voulu lui dire pour
lui situer mieux son problème.

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 qu'il faut bien
donner le nom décoré

Pas nécessairement non plus. Il y a des options de compilations pour
exporter le nom sans décoration, ou pour exporter un alias.

à GetProcAddr (et dans le fichier .DEF). Et
qu'il y a probablement d'autres restrictions que je ne connais
pas.

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.

--
Alain

Alain Gaillard wrote:

[...]

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 ;) )

Tu peux le dire. J'ai compilé un programme avec Turbo-C, en
1989, et c'est la somme totale de mon expérience avec Borland.
Même en général sous Windows, mon expérience est limitée (mais
j'ai beaucoup d'expérience avec Zortech C++ sous MS-DOS:-).

[...]

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.

Comme j'ai dit, j'étais loin d'être certain. Logiquement, on s'y
attendrait. Mais logiquement, on s'attendrait au type de rétour
aussi, ce qui n'y entre en fait sur aucun compilateur que je
connais.

[...]

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.

Tout comme dlsym sous Unix. (Je dirais que c'est même pire sous
Unix : tu reçois un void* de retour. Alors, le premier
problème, c'est déjà de le convertir en pointeur à une fonction,
étant donné qu'il n'y a aucune conversion dans la norme prévue
pour ce cas.)

(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 ;)

Seulement un peu, parce que l'utilisation du chargement
dynamique est quand même assez limitée. J'ai une faiblesse pour
les solutions simples. (Donc, par exemple, chaque .so/.dll
n'exporte qu'un seul symbole, qui est le nom d'une fonction
déclarée « extern "C" ».)

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" :-)

Ben, il essaie de s'expliquer, et il s'est modéré un peu.
Personnellement, je ne crois pas du tout au bug chez Microsoft
(dans ce cas précis, s'entend). Mais je pourrais concevoir que
c'est ce qu'il va falloir qu'il dise à son chef.

Sur le fond tu as malheureusement raison.

Tu vois, il y a quand même des domaines où j'ai de
l'expérience:-). Comme celui des mauvais chefs.

(Je me démande si la situation n'est pas en train d'évoluer. Ça
fait maintenant trois ou quatre missions de suite où j'ai eu des
chefs réelement compétents. Alors que si je régarde la situation
au début de ma carrière...)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Alain Gaillard wrote:

[...]

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é :)

Tout à fait. Mais c'est peut-être une solution à son problème.
Ou un work-around, selon ton point de vue.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34