[C/C++] Les utilisateurs de VisualC++ et les dépendances

Le côté programmation du développement d'un jeu vidéo.

Les utilisateurs de VisualC++ et les dépendances

Messagepar tof » 25 Juil 2009, 14:27

Suite aux Novendiales, j'ai pu constater avec agacement que les développeurs sous Windows n'ont pas l'habitude d'indiquer les dépendances nécessaires pour lancer leurs applications, alors que les développeurs ayant eu l'habitude de distribuer leurs applications sous forme de code-source, ils indiquent toujours que telles ou telles libs seront nécessaires pour compiler (faut dire, vu qu'ils utilisent scons ou les autotools pour compiler leurs projets, ils sont obligés de tenir à jour la liste des dépendances).

Si cela ne pose pas de problème dans le cas de DirectX ou .Net, pour lesquels Windows indiquent clairement qu'ils doivent être installés/mis-à-jour, c'est beaucoup plus problèmatique avec le runtime de VC++ 2008. En effet, quand on lance un exécutable compilé avec cette version sans avoir le runtime, on obtient un bête message "Cette application n'a pu être démarré parce que la configuration est incorrecte. Réinstaller l'application pourrait résoudre le problème." En gros, Windows nous dit qu'il y a un soucis, mais il ne sait pas quoi.

Image

Et pourtant, Windows connaît bien la cause du problème! Il faut pour cela aller chercher l'Event Viewer (qui est disponible mais planqué sous XP, alors que sur les versions Server de Windows il est facilement accessible) dans le Control Panel, puis les Outils d'Administration. Et là miracle, on remarque qu'il y a des erreurs!

Image

Et quand on clic, on nous indique enfin qu'une dépendance n'est pas satisfaite:

Image

Il s'agit là du runtime de VisualC++ 2008. Etrangement, pour les versions précédentes, on obtenait directement un message spécifiant qu'il fallait installer une dll (style MSVCR71.dll pour VC++ 7.1), mais là il faut aller farfouiller pour trouver un outil qu'on ne sait pas forcément présent sur les versions personnels de Windows.

Pour résoudre ce problème, l'utilisateur n'a alors plus qu'à installer le runtime. Ou alternativement, si le développeur veut simplifier la vie de l'utilisateur (rappelons que c'est la politique habituelle sous Windows), il suffit de fournir un répertoire nommé Microsoft.VS90.CRT contenant les 3 dll du runtime et un fichier manifest, à placer à côté de l'exécutable.

Image


Pour conclure ce long message en forme de critique (qui n'est pas un troll, cela m'a vraiment posé des problèmes parce que je ne comprenais pas pourquoi j'avais des erreurs en voulant lancé certains projets des Novendiales), j'ai quelques questions:

1/ Messieurs les développeurs sous Windows, s'il-vous-plaît, pensez à inclure le runtime, ou à défaut à indiquer la dépendance (ok, pas une question :))

2/ Pourquoi par défaut VC++ ne fournit-il pas la possibilité de compiler soit pour le dév (compilation classique, où le développeur a déjà toutes les dll sur sa machine), soit pour une release (en incluant alors le runtime)? Les gens utilisant Scons ou les Autotools passent leur temps à jongler entre les diffèrentes targets de compilation pour simplifier la vie des utilisateurs, donc pourquoi ne pas faire de même sous Windows?

3/ DirectX (et .Net sous Vista) sont installés par défaut, pourquoi Microsoft ne fait-il pas de même pour le runtime de VC++, sachant que pas mal d'applications tierces sont développées avec? Si c'est une question de mise-à-jour, je ne vois pas en quoi c'est diffèrent de .Net: quand une application nécessite une version de .Net qui n'est pas installé, Windows prévient. Cela pourrait être de même avec un runtime installé par défaut.
tof
 
Messages: 1763
Inscription: 11 Avr 2005, 12:00

Messagepar Gavos » 25 Juil 2009, 14:39

Moi j'ai une dernière question : dans quels cas notre programme devient-il dépendant d'un runtime VC++ ? Est-ce à partir du moment où on développe une application Win32 sous Visual Studio ou bien cela vient-il de l'utilisation de certaines libs bien précises
Gavos
 
Messages: 1089
Inscription: 19 Mar 2005, 13:00

Messagepar Aranoth » 25 Juil 2009, 15:46

2/ Pourquoi par défaut VC++ ne fournit-il pas la possibilité de compiler soit pour le dév (compilation classique, où le développeur a déjà toutes les dll sur sa machine), soit pour une release (en incluant alors le runtime)? Les gens utilisant Scons ou les Autotools passent leur temps à jongler entre les diffèrentes targets de compilation pour simplifier la vie des utilisateurs, donc pourquoi ne pas faire de même sous Windows?

3/ DirectX (et .Net sous Vista) sont installés par défaut, pourquoi Microsoft ne fait-il pas de même pour le runtime de VC++, sachant que pas mal d'applications tierces sont développées avec? Si c'est une question de mise-à-jour, je ne vois pas en quoi c'est diffèrent de .Net: quand une application nécessite une version de .Net qui n'est pas installé, Windows prévient. Cela pourrait être de même avec un runtime installé par défaut.
A mon avis ça vient du fait que VS C++ est à la traine sur VS C#, il suffit de voir l'IDE, c'est le jour et la nuit.
Les efforts de Microsoft se tournent clairement vers le .NET (et le C# plus particulièrement) et pas vers le C++.

Ils annoncent un rattrapage pour Visual Studio 2010, on verra ce que ça donne, ils reverront surement leur copie à ce moment là.

Je rêve d'un IDE C++ aussi bon que Visual Studio C#...


Moi j'ai une dernière question : dans quels cas notre programme devient-il dépendant d'un runtime VC++ ? Est-ce à partir du moment où on développe une application Win32 sous Visual Studio ou bien cela vient-il de l'utilisation de certaines libs bien précises
Il me semble que c'est dans tous les cas.
Un peu comme le -lmingw32 avec MinGW.
Mais à vérifier quand même.
Avatar de l’utilisateur
Aranoth
Hello World, I'm new !
 
Messages: 1327
Inscription: 10 Avr 2005, 00:10
Localisation: Montréal

Messagepar tof » 25 Juil 2009, 16:30

Ca me semblerait logique aussi que ce soit dans tous les cas. Après tout, une appli C++ compilée sous linux aura aussi une dépendance sur la libstc++.so.
tof
 
Messages: 1763
Inscription: 11 Avr 2005, 12:00

Messagepar NewbiZ » 26 Juil 2009, 00:48

Moi j'ai une dernière question : dans quels cas notre programme devient-il dépendant d'un runtime VC++ ? Est-ce à partir du moment où on développe une application Win32 sous Visual Studio ou bien cela vient-il de l'utilisation de certaines libs bien précises

C'est à toi, développeur, de choisir la politique d'accès au CRT ( C++ RunTime library ) que tu préfères pour ton application.

Il y a deux versions de cette librairie:
  • MSVCRT.lib : c'est une librairie d'import (qui ne sert qu'à la résolution des symboles et au chargement de la DLL) pour le code distribué dans MSVCR80.DLL (ou MSVCR90.DLL, ... selon ta version de la librairie).
  • LIBCMT.lib : c'est la version statique de la librairie C++.

Tu peux configurer la librairie avec laquelle tu va lier ton programme dans les options du projet, ce sont les paramètres /MD (MSVCRT.lib) et /MT (LIBCMT.lib), comme le montre la capture suivante:

Image

Je ne vois pas en quoi Microsoft est en cause dans l'histoire, c'est une question de développement, et de déploiement.

Sous Windows, les installeurs individuels ont un rôle plus important que sous les unixoïdes, ou la gestion des dépendances est souvent confiée à un programme dédié. On peut le critiquer bien sur, mais de toute façon il faudra faire avec.
Il y a des avantages comme des inconvénients, comme dans tout système.

Toujours est-il que c'est au développeur/déployeur de choisir parmis ces possibilités:
  • Linker vers la version dynamique de la CRT a des avantages, particulièrement lors du développement. Il est très pratique de pouvoir benchmarker son programme avec différentes versions de la CRT sans avoir à tout recompiler (j'ai eu l'occasion de travailler sur des librairies qui mettaient plus de 30 minutes à compiler, je vous assure, ca sauve la vie).
  • Linker avec la version dynamique permet aussi à votre programme de profiter de futures versions de la librairie améliorées sans que vous deviez fournir un nouvel executable.
  • Linker avec la version statique alourdit le poids de l'executable.
  • Linker avec la version statique permet à votre programme d'être un standalone, c'est à dire de pouvoir être distribué sans installeur, ce qui est pratique dans des projets comme ceux des novendiales.
  • Si vous décidez d'utiliser la version dynamique de la CRT, alors c'est la charge de l'installeur de vérifier que le client possède bien un runtime à jour (ou de l'installer le cas échéant).

En gardant en tête toutes ces considérations, il n'y a pas de raison que la distribution se passe mal :)
~ Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet ~
Avatar de l’utilisateur
NewbiZ
 
Messages: 1265
Inscription: 02 Juin 2005, 22:25
Localisation: Tallinn / Estonie

Messagepar Eva » 27 Juil 2009, 11:07

A noter aussi qu'il existe des projets de déploiement sous VS...
Avatar de l’utilisateur
Eva
Hello World, I'm new !
 
Messages: 651
Inscription: 31 Mai 2005, 15:43

Messagepar Mokona » 27 Juil 2009, 12:18

Avec une intégration des réponses de NewbiZ dans le message initial de tof et un développement de ce qu'à dit Eva, le tout mis en forme, on a un excellent article qui sera en plus très pratique pour toutes les futures productions faites avec VS.
Mokona
Hello World, I'm new !
 
Messages: 1686
Inscription: 13 Mar 2005, 13:00

Messagepar tof » 27 Juil 2009, 14:36

Je trouve aussi.
tof
 
Messages: 1763
Inscription: 11 Avr 2005, 12:00

Messagepar MrGecko » 04 Aoû 2009, 02:17

J'ai eu cette erreur sous windows 7
J'ai donc cherché avec joie le nouvel Observateur d'événements.

Image

Et c'est ainsi que j'ai pu découvrir l'utilitaire sxstrace (n'existe pas sous xp):

=================
Début de la génération du contexte d’activation.
Paramètre d’entrée*:
Flags = 0
ProcessorArchitecture = x86
CultureFallBacks = fr-FR;fr
ManifestPath = N:\Users\Astronaut\Downloads\RegenDry\RegenDry.exe
AssemblyDirectory = N:\Users\Astronaut\Downloads\RegenDry\
Application Config File =
-----------------
Information*: analyse du fichier manifeste N:\Users\Astronaut\Downloads\RegenDry\RegenDry.exe.
Information*: l’identité de la définition du manifeste est (null).
Information*: référence*: Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"
Information*: référence*: Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0"
Information*: résolution de la référence Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
Information*: résolution de la référence pour l’architecture ProcessorArchitecture x86.
Information*: résolution de la référence pour la culture Neutral.
Information*: application de la stratégie de liaison.
Information*: aucune stratégie de serveur de publication trouvée.
Information*: aucune redirection de la stratégie de liaison trouvée.
Information*: début de la recherche d’assemblys.
Information*: impossible de trouver l’assembly dans WinSxS.
Information*: tentative de recherche du manifeste sur N:\WINDOWS\assembly\GAC_32\Microsoft.VC90.DebugCRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.DebugCRT.DLL.
Information*: tentative de recherche du manifeste sur N:\Users\Astronaut\Downloads\RegenDry\Microsoft.VC90.DebugCRT.DLL.
Information*: tentative de recherche du manifeste sur N:\Users\Astronaut\Downloads\RegenDry\Microsoft.VC90.DebugCRT.MANIFEST.
Information*: tentative de recherche du manifeste sur N:\Users\Astronaut\Downloads\RegenDry\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.DLL.
Information*: tentative de recherche du manifeste sur N:\Users\Astronaut\Downloads\RegenDry\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.MANIFEST.
Information*: manifeste pour la culture Neutral introuvable.
Information*: fin de la recherche d’assemblys.
Erreur*: impossible de résoudre la référence Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
Erreur*: échec de la génération du contexte d’activation.
Fin de la génération du contexte d’activation.


Le problème est donc identique mais il faut ici fournir les versions debug des dll et du manifest.
Pareil pour le nom du dossier: Microsoft.VC90.CRT devient Microsoft.VC90.DebugCRT


nb: à ce propos tof, tu as écris Microsoft.VS90.CRT


Merci pour l'astuce.
Avatar de l’utilisateur
MrGecko
Hello World, I'm new !
 
Messages: 1078
Inscription: 02 Mai 2005, 17:43
Localisation: Montpellier

Messagepar Kristof » 04 Aoû 2009, 09:48

Genial ce sujet.

J'avoue que j'ai jamais trop compris comment resoudre ce probleme.
Je suis un programmeur console (Wii/DS, pas console Win32), et c'est vrai que c'est bien différent et plus complexe sous windows.

Je m'étais deja hasardé a tout linké en statique, mais ca m'avait généré des dizaines d'erreurs de fonctions en double ou manquantes. Je regarderai de plus près les messages précédents.
Avatar de l’utilisateur
Kristof
Hello World, I'm new !
 
Messages: 645
Inscription: 14 Avr 2005, 11:56
Localisation: Montigny le Bretonneux (78)

Messagepar Ced666 » 04 Aoû 2009, 20:20

Il y a effectivement deux solutions: soit tout lier en statique (et on se retrouve avec un exe énorme) ou alors installer le runtime (qui est en fait la librairie C-runtime et les librairies MFC). Il y a moyen de télécharger le runtime sur le site de microsoft: http://www.microsoft.com/downloads/details.aspx?FamilyID=32bc1bee-a3f9-4c13-9c99-220b62a191ee&DisplayLang=en .

Mais le meilleur moyen reste encore d'utiliser un installeur qui s'occupe de ça (je pense que InnoSetup gère ce genre de chose mais je n'en suis pas sûr).
Ced666
Hello World, I'm new !
 
Messages: 315
Inscription: 10 Avr 2005, 09:43

Messagepar NewbiZ » 04 Aoû 2009, 20:53

Kristof a écrit:Je m'étais deja hasardé a tout linké en statique, mais ca m'avait généré des dizaines d'erreurs de fonctions en double ou manquantes.

C'est le genre d'erreurs symptomatiques de quand on essaye de lier ensemble des modules compilés avec différentes CRT. Si ta solution comporte plusieurs projets et/ou librairies, vérifies qu'elles utilisent bien toutes les même version de la CRT.

Ced666 a écrit:lier en statique (et on se retrouve avec un exe énorme)

Faut aussi relativiser, la librairie standard ca doit pas peser plus de 1mo :)
Si tu fais des intros 4k je comprends, mais pour une application traditionelle, c'est rien.
~ Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet ~
Avatar de l’utilisateur
NewbiZ
 
Messages: 1265
Inscription: 02 Juin 2005, 22:25
Localisation: Tallinn / Estonie

Messagepar valentin » 08 Sep 2009, 09:47

J'up juste pour parler du logiciel DEPENDS bien pratique pour connaitre les dépendances d'un executable sans même l'exécuter.

J'avoue que tous les problèmes évoqués ici, je n'en avais jamais entendu parlé avant les novendiales. Je ferai attention maintenant, mais néanmoins les .dll de la SFML sont compilées en utilisant la runtime et j'ai du les recompiler en static pour que mes prochains exécutables puissent marcher pour tout le monde.

Bref, ce sujet mériterait un petit article quelque part.
Avatar de l’utilisateur
valentin
Hello World, I'm new !
 
Messages: 494
Inscription: 20 Mai 2008, 16:10
Localisation: GRENOBLE

Messagepar TobyKaos » 08 Sep 2009, 10:18

Oui DEPENDS est très pratique et si tu lances l'application avec tu as pas mal d'infos sur les dépendances.

Sinon pour pas m'embêter avec le manifest j'inclus dans mon installeur l'exécutable vcredist_x86.exe (sur msdn) et l'installeur l'install. Comme ça on compile en dynamique et les dll sont fournit par vcredist_x86.exe à l'installation.

C'est vrai qu'au départ c'est un peu galère tout ça et qu'un article serait le bienvenue.
Toby or not Toby.
Développeur Indépendant de Jeux vidéo.
www.chaos-interactive.com
Twitter
Facebook
[SIGPIC][/SIGPIC]
Avatar de l’utilisateur
TobyKaos
Hello World, I'm new !
 
Messages: 332
Inscription: 03 Jan 2007, 13:07

Messagepar Kristof » 15 Sep 2009, 12:45

ou alternativement, si le développeur veut simplifier la vie de l'utilisateur (rappelons que c'est la politique habituelle sous Windows), il suffit de fournir un répertoire nommé Microsoft.VC90.CRT contenant les 3 dll du runtime et un fichier manifest, à placer à côté de l'exécutable.


Merci Tof, j'ai utilisé cette méthode pour mon "Equilibrio" PC. On verra ce qu'en dise les beta testeurs.
Avatar de l’utilisateur
Kristof
Hello World, I'm new !
 
Messages: 645
Inscription: 14 Avr 2005, 11:56
Localisation: Montigny le Bretonneux (78)

Messagepar Gavos » 13 Mar 2011, 15:32

Merci Tof, j'ai utilisé cette méthode pour mon "Equilibrio" PC. On verra ce qu'en dise les beta testeurs.


Hej Kristof, est-ce que tu as eu des soucis avec cette technique finalement ? Apparemment ça n'a pas l'air simple d'utiliser SFML sans le runtime DLL, mais si je peux éviter d'avoir à faire installer ce vcredist je serais content.
Gavos
 
Messages: 1089
Inscription: 19 Mar 2005, 13:00


Retourner vers Programmation

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 12 invités

cron