MSVCP100.dll provem avec C++ Win32

Signaler
Messages postés
78
Date d'inscription
mardi 31 décembre 2002
Statut
Membre
Dernière intervention
14 août 2010
-
Messages postés
78
Date d'inscription
mardi 31 décembre 2002
Statut
Membre
Dernière intervention
14 août 2010
-
Bonjour,

Je suis nouveau sur ce forum et je débute avec C++ Visual Studio 2010.
Je viens de terminer le portage d'un de mes projet powerBASIC Win32 qui utilise uniquement la flat API bas niveau et des Dlls Win32 natives. Ce projet est destiné à fonctionner uniquement sur Windows Seven.

Je génère mon projet en mode release, et je place l'EXE dans le répertoire "debug" car c'est là que se trouve toutes les DLLs et l'ensemble des ressources utilisées par le projet. Puis je créé un ZIP contenant le projet VS2010 complet, afin de poster le tout sur le forum de mon ami José Roca qui se trouve ici.

Sur ma machine tout fonctionne bien, cependant sur certaines config, le programme refuse de démarrer car il ne trouve pas MSVCP100.dll.
Je ne sais pas à quoi sert cette DLL, ni pourquoi VC++ 2010 en a besoin, alors que je génère un exécutable Win32 classique.

Pouvez-vous m'éclairer ?

Note: Sur le forum de José Roca, il faut être un utilisateur enregistré pour pouvoir voir et télécharger les pièces jointes.
Cependant vous pouvez télécharger le ZIP également ici.

Merci !


Patrice Terrier

21 réponses

Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
12
T'es sûr d'avoir tout compilé en Release avec le linkage en statique des libs VC++ ?

VB.NET is good ... VB6 is better
Utilise Réponse acceptée quand un post répond à ta question
Messages postés
1107
Date d'inscription
mercredi 15 juin 2011
Statut
Membre
Dernière intervention
10 juillet 2018
4
salut,

je me trompe peut-etre, mais il semble que ce soit l'erreur classique de déploiement d'un exe Visual.
Il faut installer les redistribuable (dans ton cas 2010) sur la machine cible. Peut-etre que certains de tes postes l'ont déjà et pas les autres.
Messages postés
78
Date d'inscription
mardi 31 décembre 2002
Statut
Membre
Dernière intervention
14 août 2010

Il faut installer les redistribuables (dans ton cas 2010)


C'est probablement la raison...
Mais alors, comment faire pour créer un exécutable C++ 2010 qui ne nécessite pas de runtime, puisque je n'utilise que la flat API et des DLLs Win32 standards ?

A quoi peut bien servir MSVCP100.dll ?

Merci pour vos réponses à tous les deux.

Patrice Terrier
Messages postés
354
Date d'inscription
mercredi 18 décembre 2002
Statut
Membre
Dernière intervention
24 mars 2011
1
Salut,

La MSVCRT (MS Visual C Runtime) contient les fonctions "standarts" du C (printf, fopen, strcpy & co ...).

Le probleme, c'est que MS nous en pond une version spécifique à chaque version de visual C++.

Tu peux compiler sans linker au CRT, mais il faudra embarquer l'implementation des fonctions standarts.

Brunews propose une implementation de celles ci.

Enfin bref, fait une recherche sur le CRT et tu trouveras les codes.

D@runia
Messages postés
78
Date d'inscription
mardi 31 décembre 2002
Statut
Membre
Dernière intervention
14 août 2010

Je croyais, peut être naïvement, qu'en me mettant au C++ je pourrai créer des exécutables extrèmement compacts qui ne nécessitent pas de runtime, je tombe de haut !

L'exécutable PowerBASIC "HUD window" que je viens de traduire en C++ ne fait que 30 Ko, et ceci sans runtime, je pensais pouvoir faire au moins aussi bien avec Visual Studio...

Patrice Terrier
Messages postés
1107
Date d'inscription
mercredi 15 juin 2011
Statut
Membre
Dernière intervention
10 juillet 2018
4
oui,

Il n'y a guère que les dév avec Visual C++ 6.0 (donc la préhistoire) où tu es quasi sûre que le runtime est installé par défaut sur les OS actuels (à partir de XP).
Messages postés
78
Date d'inscription
mardi 31 décembre 2002
Statut
Membre
Dernière intervention
14 août 2010

Je crois avoir trouvé la raison pour laquelle MSVCP100.DLL est requis dans mon projet.

J'utilisais l'instruction sprintf_s (qui est "secure"), mais comme je suis sûr de ne pas dépasser la taille de mon buffer, j'utilise sprintf à la place avec "#define _SCL_SECURE_NO_WARNINGS" (pour ne pas avoir le warning error) ce qui devrait avoir pour effet de ne plus nécessiter le CRT 2010 !

Etant moi-même un dinosaure, j'aurai pu me contenter de Visual c++ 6.0, j'ai cru bien faire en achetant Visual Studio Pro

Patrice Terrier
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
24
Tu as très bien fait, le compilo de VS10 est énormément meilleur en optimisation rapport au VS6.

ciao...
BruNews, MVP VC++
Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
12
Je rêve ou t'as rien lu de mon post ? Va dans les propriétés de ton projet, sélectionne le target Release et modifie le type de linkage de la CRT en mettant /MT au lieu de /MD :


A ne pas faire pour le target Debug vu que ce dernier ne devra en aucun cas être publié (tu veux pas non plus donner le source de ton programme, tant que t'y es ?)

VB.NET is good ... VB6 is better
Utilise Réponse acceptée quand un post répond à ta question
Messages postés
78
Date d'inscription
mardi 31 décembre 2002
Statut
Membre
Dernière intervention
14 août 2010

GHUYSMANS99--

Comme je l'ai dit dans mon premier post, je débute avec Visual C++ 2010.
Je ne connais donc pas encore la signification des différentes options de compilation.
En particulier la signification l'option de compilation /MT ?

Une recherche sur MSDN, me donne l'explication suivante:
Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.


Néanmoins, je pense que l'utilisation de "sprintf_s" au lieu de "sprintf" est la cause de mon problème, car sprintf_s est spécifique de la version 2010 (dumoins je crois).

Concernant le code source, celui-ci est livré avec le projet, car c'est une démo WinLIFT/GDImage qui montre l'utilisation d'une fenêtre "HUD" dans l'esprit des DreamScenes de la version VISTA integrale, sauf que le projet utilise des plugins visuels OpenGL à la place des vidéos.

Je vais essayer de compiler la version "release" avec l'option /MT, pour voir la différence, merci !.

Patrice Terrier
Messages postés
78
Date d'inscription
mardi 31 décembre 2002
Statut
Membre
Dernière intervention
14 août 2010

Après avoir compilé avec l'option /MT la taille du code source passe de 31 Ko à 92 Ko (ce qui semble normal puisqu'une partie du CRT est incluse directement dans le code).
Cependant c'est 3 fois la taille de l'EXE généré par PowerBASIC, ce qui me laisse très perplexe...


Patrice Terrier
Messages postés
78
Date d'inscription
mardi 31 décembre 2002
Statut
Membre
Dernière intervention
14 août 2010

Errata: dans mon post précédent, je veux parler de la taille du code EXE, pas celle du code source.

Patrice Terrier
Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
12
sprintf_s est spécifique de la version 2010
Ca existait déjà depuis un bout de temps

C'est plutôt normal comme comportement. Ca marche, maintenant ?

VB.NET is good ... VB6 is better
Utilise Réponse acceptée quand un post répond à ta question
Messages postés
1054
Date d'inscription
samedi 2 octobre 2004
Statut
Membre
Dernière intervention
9 juillet 2013
6
Salut

@Brunews : Tu dis que VS10 est bien meilleur que VC6. Qu'en est il des différences de performance d'optimisation entre VS10 et VS2008?
En gros est il primordiale de migrer vers VS10?

A+

____________________________________________________________________________
Logiciel en traitement de l'image gratuit et open source.
Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
12
@Pistol_Pete : Si tu fais beaucoup de calcul dans ton applications tu verras (peut-être) la vitesse de ton programme augmenter. Si c'est un bête truc fenêtré, faut bien se dire que le plus lent dans l'histoire sera l'utilisateur et pas ton programme (même un dixième de seconde, pour lui, on s'en fout )

VB.NET is good ... VB6 is better
Utilise Réponse acceptée quand un post répond à ta question
Messages postés
1054
Date d'inscription
samedi 2 octobre 2004
Statut
Membre
Dernière intervention
9 juillet 2013
6
Oui on est bien d'accord ghuysmans99. Moi ce qui m'intéresse c'est de faire du calcul... Maintenant j'aimerai avoir une réponse plus précise. Genre, sur une convolution toute banale, combien je peux espérer gagner en temps d'exécution: 10% ou 0.1%
A+

____________________________________________________________________________
Logiciel en traitement de l'image gratuit et open source.
Messages postés
1054
Date d'inscription
samedi 2 octobre 2004
Statut
Membre
Dernière intervention
9 juillet 2013
6
Par exemple une convolution :

for(j=0;j<Height;j++)
  for(i=0;i<Width;i++){
    imOut[i+j*Width]=0;
    nbPix=0;
    for(l=-1;l<=1;l++)
      if(j+l>=0 && j+l<Height)
        for(k=-1;k<=1;k++)
          if(i+k>=0 && i+k<Width){
            imOut[i+j*Width] += imIn[i+k+(j+l)*Width];
            nbPix++;
          }
    imOut[i+j*Width]/=nbPix;
  }



____________________________________________________________________________
Logiciel en traitement de l'image gratuit et open source.
Messages postés
1107
Date d'inscription
mercredi 15 juin 2011
Statut
Membre
Dernière intervention
10 juillet 2018
4
Pour avoir vu, au temps de VS 2005, des développeurs d'algo en traitement du signal, je pense que ce n'est pas le version de Visual qui prime mais sa compatibilité de son compilo à générer du code avec les instructions SSE (version X).
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
24
Je parle du point de vue C et ASM:
Rapport au VS2008, VS2010 ne t'apportera la plupart du temps quasi rien en terme de perfs.
Les instructions SSE 4.2 sont toutes supportées, que soit en pseudo cde inliné ou en fichier ASM.
Il faut bien prendre en compte qu'aucun compilo ne génèrera des instructions PACKées, si on veut des perfs optimales c'est ASM à la main et alignement correct (16) des données.

ciao...
BruNews, MVP VC++
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
11
Salut,

Zap -> Pour un projet C, tu peux descendre à 4 ko voire en dessous (Dépend du compilateur) pour un programme vide, sans trop forcer (Exemple à 3ko5 environ). Il ne faut pas utiliser tout ce qui est runtime C/C++. Donc déjà, il faudrait enlever tes inclusions de stdlib, stdio, iostream... Comme déjà dit, il ne faut utiliser que des fonctions windows. Voilà un tableau proposant quelques fonctions de remplacement pour les chaînes.

Ensuite, le main n'est pas vraiment le point d'entrée du programme d'un point de vue Windows. Le vrai point d'entrée est fourni par la runtime. La runtime s'initialise (Il prépare notamment argv et argc)avant d'appeler le main. A la fin du main, la runtime reprend la main pour se finaliser avant de demander l'arrêt du processus.

Si tu n'utilise pas la runtime, tu n'as pas besoin d'exécuter cette initialisation et cette finalisation. Il faut redéfinir le point d'entrée. Il y a différente méthode. #pragma comment(linker, "/entry:main") par exemple (VC uniquement). Mais je préfère à présent plutôt utiliser les signatures recherchées par le linker (Fonctionne pour VC et gcc) :
Pour un programme console :
int __cdecl mainCRTStartup();
Pour un programme fenêtré :
int __cdecl WinMainCRTStartup();

Enfin, pour être sûr que le linker ne s'occupe pas de la CRT, il faut utiliser NODEFAULTLIB sous VC et ajouter kernel32, user32 et autres nécessaires en entrée du lieur.