Discussion :

[seiryujay]

Bonjour,

D'avance désolé si cette question vous semble idiote ou déjà vue 42.357 fois, mais j'ai beau faire le tour des posts sur le sujet, je ne trouve pas vraiment la réponse adéquate.

Je développe en Java (non, non, je ne me suis pas trompé de forum, je vous assure), et je dois utiliser une dll qu'on me fournit. Pour faire ça, le principe est de créer une dll interface qui fera le lien entre la dll fournie et mon programme Java.
J'ai développé cette dll sous Windows XP et j'ai quelques soucis lors de son utilisation sous Windows 2000.

Pour y remédier :
- j'ai essayé de compiler ma dll en mode "Use MFC in a static library" plutôt qu'en mode "Use MFC in a shared library" => pas d'améliorations.
- j'ai essayé de modifier les paramètres de génération, et donc de passer de Multithreaded à toutes les autres options, mais à ce moment-là j'ai des erreurs de compil... (et je n'ai pas vraiment cherchés à les résoudre, ne sachant pas si ça ferait marcher ma dll et m'étant déjà suffisamment arraché les cheveux là-dessus)
- j'ai regardé les dépendances de ma dll via l'utilitaire fourni avec Visual Studio. J'obtiens cette liste :
c:\windows\system32\ADVAPI32.DLL
c:\windows\system32\COMCTL32.DLL
c:\windows\system32\COMDLG32.DLL
c:\windows\system32\GDI32.DLL
c:\windows\system32\KERNEL32.DLL
c:\windows\system32\MSVCRT.DLL
c:\windows\system32\NTDLL.DLL
c:\windows\system32\OLE32.DLL
c:\windows\system32\OLEAUT32.DLL
c:\windows\system32\OLEDLG.DLL
c:\windows\system32\OLEPRO32.DLL
c:\windows\system32\RPCRT4.DLL
c:\windows\system32\SHELL32.DLL
c:\windows\system32\SHLWAPI.DLL
c:\windows\system32\USER32.DLL
c:\windows\system32\WINSPOOL.DRV

- j'ai récupéré le vcredist_x86.exe dont on parle dans la FAQ mais je ne l'ai pas encore installé car je ne pense pas que ça puisse m'aider étant donné les dépendances trouvées.

Or comme sous Windows 2000 les fichiers sont placés sous c:\winnt\system32 et que les versions des fichiers dépendants ne sont pas les mêmes, je me demandais si mon problème pouvait venir de là ou pas. Qu'est-ce que vous en pensez?

Si ça vient de là, comment puis-je ajouter ces dll à la dll que je crée? (je n'ai pas trouvé l'utilitaire vcredist)?
Suis-je obligé de remplacer les fichiers existants sur le PC cible par les fichiers que j'ai sur mon PC?
Est-ce que ça ne risque pas de "déstabiliser" le poste cible?

Dois-je recompiler ma dll sous un poste possédant Windows 2000? Auquel cas, la dll sera-t-elle toujours dépendante du système? (fonctionnera-t-elle sous 2000 et plus sous XP)

Je débute vraiment dans la création et l'utilisation de dll, alors n'importe quel indication me sera précieuse.

Merci d'avance.

[farscape]

salut,
Tu as omis de dire quel était le problème rencontré précisément sous windows 2000...

[seiryujay]

Effectivement.

Ben en fait, j'ai un crash de mon appli Java et il me dit ceci :
"javaw.exe a généré des erreurs et sera fermé par Windows. Vous devrez redémarrez le programme.

Un journal des erreurs est en cours de création."

Par contre, j'ai trouvé aucune trace de rapport d'erreur. J'ai même cherché dans l'observateur d'événements, mais peanuts...

[farscape]

au final il y a t-il un contexte d'environnement où cette dll fonctionne correctement ?

[seiryujay]

au final il y a t-il un contexte d'environnement où cette dll fonctionne correctement ?

Oui quand même
Sous n'importe quel poste où Windows XP est le système d'exploitation.
C'est pour ça que je me demande si la dll que j'ai générée est dépendante du système d'exploitation...

[farscape]

alors il est possible que cela vienne de la version des dll systémes.
je tenterai une mise à jour des dll avec vcredist_x86.exe dans le cas de visual 6.
pour visual 2005 c'est : http://www.developpez.net/forums/sho...72#post1047972

[seiryujay]

alors il est possible que cela vienne de la version des dll systémes.
je tenterai une mise à jour des dll avec vcredist_x86.exe dans le cas de visual 6.
pour visual 2005 c'est : http://www.developpez.net/forums/sho...72#post1047972

Ok, je vais tenter.
Par contre, 2 questions :

1) cet exe met à jour les dll système ou juste les dll MFC et relatives à Visual Studio? (style mfc42.dll, etc)

2) j'ai récupéré la version dispo sur le lien que tu as mis (et que j'avais trouvé dans d'autres posts), mais en fait je développe sous Visual Studio 6. Ca ira quand même ou y'a une version particulière de vcredist_x86.exe à récupérer quelque part?

[farscape]

1) relatives a visual studio mfc42 mais aussi Oleaut32.dll etc ...
2) si tu disposes du service pack6 de vc6 en francais il est dedans.
sinon telecharge le sur MSDN ...

[seiryujay]

1) Ok, donc il faut que je mette tout ça à jour, étant donné que OLEAUT32 fait partie de la liste des dépendances et que sa version n'est pas la même sur les 2 systèmes.

2) Téléchargement du SP6 en cours...
Je te préviens dès que j'ai testé.

[seiryujay]

Euh, c'est bon, j'ai récupéré le SP6.
J'ai trouvé vcredist.exe.
Par contre, quand je le lance sur mon PC XP ou sur le PC cible il ne se passe rien.
J'ai essayé de lancer vcredist_v86, et lui il se lance. Mais je n'ai pas été au bout de l'install parce que c'est censé être pour VS 2005...
Je tente de l'installer? Sur le PC cible ou le PC XP?

[farscape]

non il faut la version pour vc6.
je l'ai mis sur mon domaine.
http://farscape.developpez.com/Samples/VcRedistVC6FR/

[seiryujay]

Merci, c'est une version plus récente que celle su SP6.
Par contre, le résultat est le même : rien ne se passe au lancement de l'exe.
C'est bizarre...

[farscape]

hum bizarre,
essaye de faire dans une boite de commande msdos:
vcredist /C
choisi un répertoire de distrib (pas c:\windows)
puis lance 50comupd.exe

[seiryujay]

Ok, l'install a fonctionné.
Malheureusement quand je lance 50comupd.exe, il me dit que j'ai déjà la dernière version des fichiers sur le PC cible.
C'est bizarre puisque j'ai vu que ce n'était pas les mêmes versions entre mon PC XP et le PC cible 2000...

Mais bon, a priori ça ne viendrait pas de la version des fichiers...
Une autre idée?

[farscape]

essaye d'executer ton programme a partir de l'emplacement ou tu as decompacter les fichiers.(place ta dll au meme endroit)
comme ça on est sur que c'est bien ces fichiers qui vont être executés...

[seiryujay]

Bon, j'ai déplacé mon appli dans le répertoire d'extraction.
Ma dll se trouvant dans un dossier "lib" du répertoire d'installation, j'ai essayé :
1) de copier les dll extraites par 50comupd dans le dossier lib
2) de modifier mon appli pour qu'elle aille chercher ma dll interface directement à la racine du rep d'install

Résultat : peanuts.
C'est la même chose.

Par contre, quelque chose qui va sûrement vous intéresser, c'est qu'en fait le premier appel à la dll se passe bien... Mon appli arrive à récupérer les infos que je demande à la dll. C'est après que ça se gate.

Lors du deuxième appel, j'ai le crash sous 2000 alors que sous XP tout se passe bien.

Et même encore plus bizarre, lors du premier appel à la dll, mon appli génére une fenêtre contenant une arborescence. Si je double-clique sur un des noeuds, j'appelle une deuxième fois la dll pour récupérer les données correspondant à ce noeud. => crash.
Mais là où c'est vraiment bizarre, c'est que si je ne fais pas le double-clique sur un noeud et qu'à la place je ferme la fenêtre, ça crashe aussi!

Je ne comprends vraiment pas ce qu'il se passe...

[farscape]

bon ,
ta dll est bien en "Use MFC in a shared library" ?

[seiryujay]

bon ,
ta dll est bien en "Use MFC in a shared library" ?

Plus maintenant, je l'ai changé pour le test, et je me suis dit que c'était aussi bien si je l'avais en static.
Mais je vais tester la même chose en shared...

[seiryujay]

Même résultat...

[farscape]

autre point,
puisque tu sais a peu pres ou ça plante au deuxieme appel,
tu dois savoir je suppose le nom de la fonction appellée dans ta dll ?
tu peux donc mettre des messages pour avancer pas a pas dans l'execution de la fonction dans la dll ?
genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 MessageBox(NULL,"Etape1","debug",0);

etc..
aprés tu procédes par dichotomie pour les messages pour approcher au plus prés de l'endroit qui provoque l'erreur.
sinon l'ideal serait de mettre le compilo sur 2000 et d'executer la dll en debug trace pour cibler le probleme...