j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo:
Soient deux machines A et B toutes les deux équipées de Visual Studio 6
et de BoundsChecker
Sur les deux machines, j'exécute les mêmes lignes de commande:
"nmcl *.c /Z7"
suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien, dans
l'autre (machine B), il plante.
Je fais alors la manip suivante :
copie des fichiers .obj sur la machine B, puis "link /out:toto.exe
*.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la génération
des objets.
Je ne sais pas si on peut attacher des fichiers à des posts... je vais
tenter l'attacher deux objets : agenda.obj.machineA et agenda.obj.machineB
... Non, bon on ne peut pas. Avez vous une idée sur comment je pourrais
vous faire parvenir les deux .obj ?
Des idées sur les causes possibles de mon problème sont les bienvenues :)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Remi THOMAS
"Fred"
Bonjour à tous,
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo: Soient deux machines A et B toutes les deux équipées de Visual Studio 6 et de BoundsChecker Sur les deux machines, j'exécute les mêmes lignes de commande: "nmcl *.c /Z7" suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien, dans l'autre (machine B), il plante.
Je fais alors la manip suivante : copie des fichiers .obj sur la machine B, puis "link /out:toto.exe *.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la génération des objets. Je ne sais pas si on peut attacher des fichiers à des posts... je vais tenter l'attacher deux objets : agenda.obj.machineA et agenda.obj.machineB ... Non, bon on ne peut pas. Avez vous une idée sur comment je pourrais vous faire parvenir les deux .obj ? Des idées sur les causes possibles de mon problème sont les bienvenues :)
Bonjour, Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose. Est-ce que les deux machines on le même service pack pour visual studio? Est-ce le même processeur? Avec un vieux compilateur j'ai des soucis quand je change de machine (il refuse les .obj)
Rémi
"Fred" <fred@laposte.net>
Bonjour à tous,
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo:
Soient deux machines A et B toutes les deux équipées de Visual Studio 6 et
de BoundsChecker
Sur les deux machines, j'exécute les mêmes lignes de commande:
"nmcl *.c /Z7"
suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien, dans
l'autre (machine B), il plante.
Je fais alors la manip suivante :
copie des fichiers .obj sur la machine B, puis "link /out:toto.exe *.obj"
... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la génération
des objets.
Je ne sais pas si on peut attacher des fichiers à des posts... je vais
tenter l'attacher deux objets : agenda.obj.machineA et agenda.obj.machineB
... Non, bon on ne peut pas. Avez vous une idée sur comment je pourrais
vous faire parvenir les deux .obj ?
Des idées sur les causes possibles de mon problème sont les bienvenues :)
Bonjour,
Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose.
Est-ce que les deux machines on le même service pack pour visual studio?
Est-ce le même processeur? Avec un vieux compilateur j'ai des soucis quand
je change de machine (il refuse les .obj)
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo: Soient deux machines A et B toutes les deux équipées de Visual Studio 6 et de BoundsChecker Sur les deux machines, j'exécute les mêmes lignes de commande: "nmcl *.c /Z7" suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien, dans l'autre (machine B), il plante.
Je fais alors la manip suivante : copie des fichiers .obj sur la machine B, puis "link /out:toto.exe *.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la génération des objets. Je ne sais pas si on peut attacher des fichiers à des posts... je vais tenter l'attacher deux objets : agenda.obj.machineA et agenda.obj.machineB ... Non, bon on ne peut pas. Avez vous une idée sur comment je pourrais vous faire parvenir les deux .obj ? Des idées sur les causes possibles de mon problème sont les bienvenues :)
Bonjour, Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose. Est-ce que les deux machines on le même service pack pour visual studio? Est-ce le même processeur? Avec un vieux compilateur j'ai des soucis quand je change de machine (il refuse les .obj)
Rémi
Fred
Remi THOMAS wrote:
"Fred"
Bonjour à tous,
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo: Soient deux machines A et B toutes les deux équipées de Visual Studio 6 et de BoundsChecker Sur les deux machines, j'exécute les mêmes lignes de commande: "nmcl *.c /Z7" suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien, dans l'autre (machine B), il plante.
Je fais alors la manip suivante : copie des fichiers .obj sur la machine B, puis "link /out:toto.exe *.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la génération des objets. Je ne sais pas si on peut attacher des fichiers à des posts... je vais tenter l'attacher deux objets : agenda.obj.machineA et agenda.obj.machineB ... Non, bon on ne peut pas. Avez vous une idée sur comment je pourrais vous faire parvenir les deux .obj ? Des idées sur les causes possibles de mon problème sont les bienvenues :)
Bonjour, Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose.
Ah. Parcequ'on voit bien (avec un éditeur de texte (style Ultra-Edit)) que les objs sont différents sur un certain nombre de points. Comme par exemple les options de compilation. On voit des /defaultlib: dans celui qui plante et des -defaultlib dans celui qui fonctionne. On voit également un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.9782.06 dans celui qui marche et un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 6 dans celui qui ne marche pas.... Plein de petites différences qui déjà me paraissent anormales.
Au fait, chose que je n'avait pas précisé, la compilation marche impeccablement bien sur les machines (et les objets générés sont identiques sur les deux machines) si je compile avec le compilateur Visual ("cl"). Le problème n'apparaît que lorsque j'utilise le compilateur BoundsChecker ("nmcl", qui pourtant est à la même version sur les deux machines)
Est-ce que les deux machines on le même service pack pour visual studio?
Il me semble que oui. Service Pack 6... y'a-t-il un moyen de le vérifier? Le "à propos" ne dit absolument rien sur la version de service pack installé... :(
Est-ce le même processeur? Avec un vieux compilateur j'ai des soucis quand je change de machine (il refuse les .obj)
Pour la machine A (celle qui marche) Non, ce n'est pas le même processeur. PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 9, GenuineIntel PROCESSOR_LEVEL PROCESSOR_REVISION09
Pour la machine B PROCESSOR_ARCHITECTURE="x86" PROCESSOR_IDENTIFIER="x86 Family 15 Model 2 Stepping 7, GenuineIntel" PROCESSOR_LEVEL="15" PROCESSOR_REVISION="0207"
Merci encore.
Fred
Remi THOMAS wrote:
"Fred" <fred@laposte.net>
Bonjour à tous,
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo:
Soient deux machines A et B toutes les deux équipées de Visual Studio
6 et de BoundsChecker
Sur les deux machines, j'exécute les mêmes lignes de commande:
"nmcl *.c /Z7"
suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien,
dans l'autre (machine B), il plante.
Je fais alors la manip suivante :
copie des fichiers .obj sur la machine B, puis "link /out:toto.exe
*.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la
génération des objets.
Je ne sais pas si on peut attacher des fichiers à des posts... je vais
tenter l'attacher deux objets : agenda.obj.machineA et
agenda.obj.machineB
... Non, bon on ne peut pas. Avez vous une idée sur comment je
pourrais vous faire parvenir les deux .obj ?
Des idées sur les causes possibles de mon problème sont les bienvenues :)
Bonjour,
Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose.
Ah. Parcequ'on voit bien (avec un éditeur de texte (style Ultra-Edit))
que les objs sont différents sur un certain nombre de points. Comme par
exemple les options de compilation. On voit des /defaultlib: dans celui
qui plante et des -defaultlib dans celui qui fonctionne. On voit
également un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
12.00.9782.06 dans celui qui marche et un Microsoft (R) 32-bit C/C++
Optimizing Compiler Version 6 dans celui qui ne marche pas....
Plein de petites différences qui déjà me paraissent anormales.
Au fait, chose que je n'avait pas précisé, la compilation marche
impeccablement bien sur les machines (et les objets générés sont
identiques sur les deux machines) si je compile avec le compilateur
Visual ("cl"). Le problème n'apparaît que lorsque j'utilise le
compilateur BoundsChecker ("nmcl", qui pourtant est à la même version
sur les deux machines)
Est-ce que les deux machines on le même service pack pour visual studio?
Il me semble que oui. Service Pack 6... y'a-t-il un moyen de le
vérifier? Le "à propos" ne dit absolument rien sur la version de service
pack installé... :(
Est-ce le même processeur? Avec un vieux compilateur j'ai des soucis
quand je change de machine (il refuse les .obj)
Pour la machine A (celle qui marche)
Non, ce n'est pas le même processeur.
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 9, GenuineIntel
PROCESSOR_LEVEL
PROCESSOR_REVISION09
Pour la machine B
PROCESSOR_ARCHITECTURE="x86"
PROCESSOR_IDENTIFIER="x86 Family 15 Model 2 Stepping 7, GenuineIntel"
PROCESSOR_LEVEL="15"
PROCESSOR_REVISION="0207"
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo: Soient deux machines A et B toutes les deux équipées de Visual Studio 6 et de BoundsChecker Sur les deux machines, j'exécute les mêmes lignes de commande: "nmcl *.c /Z7" suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien, dans l'autre (machine B), il plante.
Je fais alors la manip suivante : copie des fichiers .obj sur la machine B, puis "link /out:toto.exe *.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la génération des objets. Je ne sais pas si on peut attacher des fichiers à des posts... je vais tenter l'attacher deux objets : agenda.obj.machineA et agenda.obj.machineB ... Non, bon on ne peut pas. Avez vous une idée sur comment je pourrais vous faire parvenir les deux .obj ? Des idées sur les causes possibles de mon problème sont les bienvenues :)
Bonjour, Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose.
Ah. Parcequ'on voit bien (avec un éditeur de texte (style Ultra-Edit)) que les objs sont différents sur un certain nombre de points. Comme par exemple les options de compilation. On voit des /defaultlib: dans celui qui plante et des -defaultlib dans celui qui fonctionne. On voit également un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.9782.06 dans celui qui marche et un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 6 dans celui qui ne marche pas.... Plein de petites différences qui déjà me paraissent anormales.
Au fait, chose que je n'avait pas précisé, la compilation marche impeccablement bien sur les machines (et les objets générés sont identiques sur les deux machines) si je compile avec le compilateur Visual ("cl"). Le problème n'apparaît que lorsque j'utilise le compilateur BoundsChecker ("nmcl", qui pourtant est à la même version sur les deux machines)
Est-ce que les deux machines on le même service pack pour visual studio?
Il me semble que oui. Service Pack 6... y'a-t-il un moyen de le vérifier? Le "à propos" ne dit absolument rien sur la version de service pack installé... :(
Est-ce le même processeur? Avec un vieux compilateur j'ai des soucis quand je change de machine (il refuse les .obj)
Pour la machine A (celle qui marche) Non, ce n'est pas le même processeur. PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 9, GenuineIntel PROCESSOR_LEVEL PROCESSOR_REVISION09
Pour la machine B PROCESSOR_ARCHITECTURE="x86" PROCESSOR_IDENTIFIER="x86 Family 15 Model 2 Stepping 7, GenuineIntel" PROCESSOR_LEVEL="15" PROCESSOR_REVISION="0207"
Merci encore.
Fred
Fred
Fred wrote:
Remi THOMAS wrote:
"Fred"
Bonjour à tous,
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo: Soient deux machines A et B toutes les deux équipées de Visual Studio 6 et de BoundsChecker Sur les deux machines, j'exécute les mêmes lignes de commande: "nmcl *.c /Z7" suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien, dans l'autre (machine B), il plante.
Je fais alors la manip suivante : copie des fichiers .obj sur la machine B, puis "link /out:toto.exe *.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la génération des objets. Je ne sais pas si on peut attacher des fichiers à des posts... je vais tenter l'attacher deux objets : agenda.obj.machineA et agenda.obj.machineB ... Non, bon on ne peut pas. Avez vous une idée sur comment je pourrais vous faire parvenir les deux .obj ? Des idées sur les causes possibles de mon problème sont les bienvenues :)
Bonjour, Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose.
Ah. Parcequ'on voit bien (avec un éditeur de texte (style Ultra-Edit)) que les objs sont différents sur un certain nombre de points. Comme par exemple les options de compilation. On voit des /defaultlib: dans celui qui plante et des -defaultlib dans celui qui fonctionne. On voit également un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.9782.06 dans celui qui marche et un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 6 dans celui qui ne marche pas.... Plein de petites différences qui déjà me paraissent anormales.
Au fait, chose que je n'avait pas précisé, la compilation marche impeccablement bien sur les machines (et les objets générés sont identiques sur les deux machines) si je compile avec le compilateur Visual ("cl"). Le problème n'apparaît que lorsque j'utilise le compilateur BoundsChecker ("nmcl", qui pourtant est à la même version sur les deux machines)
Est-ce que les deux machines on le même service pack pour visual studio?
Il me semble que oui. Service Pack 6... y'a-t-il un moyen de le vérifier? Le "à propos" ne dit absolument rien sur la version de service pack installé... :(
Euh... je voulais parler du service pack 5... Mais en fait, j'ai un gros doute. La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2" La version du même fichier sur la machine B est "6.00.8168.0" Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un aurait il une idée des services packs auquels correspondent les versions citées ci-dessus?
Merci
Fred
Fred wrote:
Remi THOMAS wrote:
"Fred" <fred@laposte.net>
Bonjour à tous,
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo:
Soient deux machines A et B toutes les deux équipées de Visual Studio
6 et de BoundsChecker
Sur les deux machines, j'exécute les mêmes lignes de commande:
"nmcl *.c /Z7"
suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien,
dans l'autre (machine B), il plante.
Je fais alors la manip suivante :
copie des fichiers .obj sur la machine B, puis "link /out:toto.exe
*.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la
génération des objets.
Je ne sais pas si on peut attacher des fichiers à des posts... je
vais tenter l'attacher deux objets : agenda.obj.machineA et
agenda.obj.machineB
... Non, bon on ne peut pas. Avez vous une idée sur comment je
pourrais vous faire parvenir les deux .obj ?
Des idées sur les causes possibles de mon problème sont les
bienvenues :)
Bonjour,
Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose.
Ah. Parcequ'on voit bien (avec un éditeur de texte (style Ultra-Edit))
que les objs sont différents sur un certain nombre de points. Comme par
exemple les options de compilation. On voit des /defaultlib: dans celui
qui plante et des -defaultlib dans celui qui fonctionne. On voit
également un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
12.00.9782.06 dans celui qui marche et un Microsoft (R) 32-bit C/C++
Optimizing Compiler Version 6 dans celui qui ne marche pas....
Plein de petites différences qui déjà me paraissent anormales.
Au fait, chose que je n'avait pas précisé, la compilation marche
impeccablement bien sur les machines (et les objets générés sont
identiques sur les deux machines) si je compile avec le compilateur
Visual ("cl"). Le problème n'apparaît que lorsque j'utilise le
compilateur BoundsChecker ("nmcl", qui pourtant est à la même version
sur les deux machines)
Est-ce que les deux machines on le même service pack pour visual studio?
Il me semble que oui. Service Pack 6... y'a-t-il un moyen de le
vérifier? Le "à propos" ne dit absolument rien sur la version de service
pack installé... :(
Euh... je voulais parler du service pack 5...
Mais en fait, j'ai un gros doute.
La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2"
La version du même fichier sur la machine B est "6.00.8168.0"
Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un
aurait il une idée des services packs auquels correspondent les versions
citées ci-dessus?
j'ai un problème qui me pose, en ce moment, vraiment quelques soucis.
Voici le topo: Soient deux machines A et B toutes les deux équipées de Visual Studio 6 et de BoundsChecker Sur les deux machines, j'exécute les mêmes lignes de commande: "nmcl *.c /Z7" suivi de "link /out:toto.exe *.obj"
Dans un cas (machine A), l'exécutable généré fonctionne très bien, dans l'autre (machine B), il plante.
Je fais alors la manip suivante : copie des fichiers .obj sur la machine B, puis "link /out:toto.exe *.obj" ... et là, l'exécutable généré fonctionne très bien.
La différence entre les deux compilation provient donc de la génération des objets. Je ne sais pas si on peut attacher des fichiers à des posts... je vais tenter l'attacher deux objets : agenda.obj.machineA et agenda.obj.machineB ... Non, bon on ne peut pas. Avez vous une idée sur comment je pourrais vous faire parvenir les deux .obj ? Des idées sur les causes possibles de mon problème sont les bienvenues :)
Bonjour, Ce n'est pas peine de donner les .obj, on peut pas en faire grand chose.
Ah. Parcequ'on voit bien (avec un éditeur de texte (style Ultra-Edit)) que les objs sont différents sur un certain nombre de points. Comme par exemple les options de compilation. On voit des /defaultlib: dans celui qui plante et des -defaultlib dans celui qui fonctionne. On voit également un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.9782.06 dans celui qui marche et un Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 6 dans celui qui ne marche pas.... Plein de petites différences qui déjà me paraissent anormales.
Au fait, chose que je n'avait pas précisé, la compilation marche impeccablement bien sur les machines (et les objets générés sont identiques sur les deux machines) si je compile avec le compilateur Visual ("cl"). Le problème n'apparaît que lorsque j'utilise le compilateur BoundsChecker ("nmcl", qui pourtant est à la même version sur les deux machines)
Est-ce que les deux machines on le même service pack pour visual studio?
Il me semble que oui. Service Pack 6... y'a-t-il un moyen de le vérifier? Le "à propos" ne dit absolument rien sur la version de service pack installé... :(
Euh... je voulais parler du service pack 5... Mais en fait, j'ai un gros doute. La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2" La version du même fichier sur la machine B est "6.00.8168.0" Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un aurait il une idée des services packs auquels correspondent les versions citées ci-dessus?
Merci
Fred
Vincent Burel
"Fred" wrote in message news:4506d1f1$0$26045$
Fred wrote: Euh... je voulais parler du service pack 5... Mais en fait, j'ai un gros doute. La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2" La version du même fichier sur la machine B est "6.00.8168.0" Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un aurait il une idée des services packs auquels correspondent les versions citées ci-dessus?
je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me permet pas d'installer processor pack (vcpp) qui permet de faire de l'ASM SSE entre autre.
VB
"Fred" <fred@laposte.net> wrote in message
news:4506d1f1$0$26045$626a54ce@news.free.fr...
Fred wrote:
Euh... je voulais parler du service pack 5...
Mais en fait, j'ai un gros doute.
La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2"
La version du même fichier sur la machine B est "6.00.8168.0"
Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un
aurait il une idée des services packs auquels correspondent les versions
citées ci-dessus?
je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me
permet pas d'installer processor pack (vcpp) qui permet de faire de l'ASM
SSE entre autre.
Fred wrote: Euh... je voulais parler du service pack 5... Mais en fait, j'ai un gros doute. La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2" La version du même fichier sur la machine B est "6.00.8168.0" Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un aurait il une idée des services packs auquels correspondent les versions citées ci-dessus?
je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me permet pas d'installer processor pack (vcpp) qui permet de faire de l'ASM SSE entre autre.
VB
Fred
Vincent Burel wrote:
"Fred" wrote in message news:4506d1f1$0$26045$
Fred wrote: Euh... je voulais parler du service pack 5... Mais en fait, j'ai un gros doute. La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2" La version du même fichier sur la machine B est "6.00.8168.0" Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un aurait il une idée des services packs auquels correspondent les versions citées ci-dessus?
je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me permet pas d'installer processor pack (vcpp) qui permet de faire de l'ASM SSE entre autre.
Il existe le SP6 pour Visual Studio 6 ? Et sinon, ça donne quoi la version de votre exécutable "msdev.exe"?"
Fred
Vincent Burel wrote:
"Fred" <fred@laposte.net> wrote in message
news:4506d1f1$0$26045$626a54ce@news.free.fr...
Fred wrote:
Euh... je voulais parler du service pack 5...
Mais en fait, j'ai un gros doute.
La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2"
La version du même fichier sur la machine B est "6.00.8168.0"
Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un
aurait il une idée des services packs auquels correspondent les versions
citées ci-dessus?
je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me
permet pas d'installer processor pack (vcpp) qui permet de faire de l'ASM
SSE entre autre.
Il existe le SP6 pour Visual Studio 6 ?
Et sinon, ça donne quoi la version de votre exécutable "msdev.exe"?"
Fred wrote: Euh... je voulais parler du service pack 5... Mais en fait, j'ai un gros doute. La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2" La version du même fichier sur la machine B est "6.00.8168.0" Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un aurait il une idée des services packs auquels correspondent les versions citées ci-dessus?
je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me permet pas d'installer processor pack (vcpp) qui permet de faire de l'ASM SSE entre autre.
Il existe le SP6 pour Visual Studio 6 ? Et sinon, ça donne quoi la version de votre exécutable "msdev.exe"?"
Fred
Vincent Burel
"Fred" wrote in message news:4506d649$0$2775$
Vincent Burel wrote: > "Fred" wrote in message > news:4506d1f1$0$26045$ >> Fred wrote: >> Euh... je voulais parler du service pack 5... >> Mais en fait, j'ai un gros doute. >> La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2" >> La version du même fichier sur la machine B est "6.00.8168.0" >> Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un >> aurait il une idée des services packs auquels correspondent les
versions
>> citées ci-dessus? > > je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me > permet pas d'installer processor pack (vcpp) qui permet de faire de
l'ASM
> SSE entre autre.
Il existe le SP6 pour Visual Studio 6 ? Et sinon, ça donne quoi la version de votre exécutable "msdev.exe"?"
oui y'a un SP6, mais je crois pas que je l'installe ... la version de mon MSDEV.EXE est 6.0.9782.1
VB
"Fred" <fred@laposte.net> wrote in message
news:4506d649$0$2775$626a54ce@news.free.fr...
Vincent Burel wrote:
> "Fred" <fred@laposte.net> wrote in message
> news:4506d1f1$0$26045$626a54ce@news.free.fr...
>> Fred wrote:
>> Euh... je voulais parler du service pack 5...
>> Mais en fait, j'ai un gros doute.
>> La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2"
>> La version du même fichier sur la machine B est "6.00.8168.0"
>> Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un
>> aurait il une idée des services packs auquels correspondent les
versions
>> citées ci-dessus?
>
> je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me
> permet pas d'installer processor pack (vcpp) qui permet de faire de
l'ASM
> SSE entre autre.
Il existe le SP6 pour Visual Studio 6 ?
Et sinon, ça donne quoi la version de votre exécutable "msdev.exe"?"
oui y'a un SP6, mais je crois pas que je l'installe ... la version de mon
MSDEV.EXE est 6.0.9782.1
Vincent Burel wrote: > "Fred" wrote in message > news:4506d1f1$0$26045$ >> Fred wrote: >> Euh... je voulais parler du service pack 5... >> Mais en fait, j'ai un gros doute. >> La version de fichier "msdev.exe" sur la machine A est "6.00.9782.2" >> La version du même fichier sur la machine B est "6.00.8168.0" >> Il semblerait donc qu'elles ne soient pas au même niveau. Quelqu'un >> aurait il une idée des services packs auquels correspondent les
versions
>> citées ci-dessus? > > je sais pas, mais je sais que chez mois c'est SP5 parce que le SP6 ne me > permet pas d'installer processor pack (vcpp) qui permet de faire de
l'ASM
> SSE entre autre.
Il existe le SP6 pour Visual Studio 6 ? Et sinon, ça donne quoi la version de votre exécutable "msdev.exe"?"
oui y'a un SP6, mais je crois pas que je l'installe ... la version de mon MSDEV.EXE est 6.0.9782.1
