Meilleur auteur de réponses
Je continue ma migration

Question
-
Pour migres des codes qui ont été généré avec BCB je copie des includes de ce compilateur pour en assurer la compatibilité
J'ai ce message que je comprend et je ne sait psysmac.H(53): error C3641: 'GetDiskFreeSpaceEx' : convention d'appel '__stdcall ' non valide pour la fonction compilée avec /clr:pure ou /clr:safes comment l'éviter
sysmac.H(53): error C3641: 'GetDiskFreeSpaceEx' : convention d'appel '__stdcall ' non valide pour la fonction compilée avec /clr:pure ou /clr:safe
Jean Noël Martin
Réponses
-
J'ai finalement été plus à la source. Cette erreur provenait d'include Borland et j'en auris eu des années pour les traiter. j'ai donc décidé de m'en passer et de prendre les includes de microsoft à la place
Jean Noël Martin
- Marqué comme réponse JeanNoel53 vendredi 11 mai 2012 13:42
-
Pensez quand même à assouplir les conditions de compilations si nécessaire. Des includes non compatibles .NET il en existe même dans le SDK de M$.
Paul Bacelar, Ex - MVP VC++
- Marqué comme réponse JeanNoel53 samedi 12 mai 2012 07:26
Toutes les réponses
-
Le plus simple est de changer la configuration du projet C++/CLI pour qu'il ne soit pas purement .NET (donc avec du code natif, /clt:pure), et qu'il puisse être "non-validable" (/clr:safe).
Vous avez cette erreur car votre projet est soit en /clr:pure (donc que du .NET) ou en /clr:safe (donc validable, donc pas d'appel de fonction avec des conventions type _stdcall).
Pour changer cela : click droit sur le projet dans l'explorateur de solution -> Propriétés -> Propriétés de configuration -> Général-> Prise en charge du Common Language Runtime (/clr)
Paul Bacelar, Ex - MVP VC++
- Proposé comme réponse Ciprian Duduiala jeudi 10 mai 2012 12:20
-
-
Il faut prendre "Prise en charge du Common Language Runtime (/clr)" dans la DropDownList de la ligne "Prise en charge du Common Language Runtime".
Avec ce choix voix êtes toujours dans du C++/CLI et compatible .NET.
Il faudrait prendre le choix "Pas de prise en charge du Common Language Runtime" pour ne pas pouvoir faire du .NET.
En passant de "Prise en charge du Common Language Runtime MSIL sécurisé (/clr:safe)" à "Prise en charge du Common Language Runtime(/clr)", cela permet d'utiliser des fonctionnalités de C++ qui peuvent poser des problème pour "la validation sécuritaire" de l'assembly. L'une de ces fonctionnalités est la convention d'appel __stdcall qui permet des attaques par stackoverflow, par exemple.
Le seul inconvénient de choisir "Prise en charge du Common Language Runtime(/clr)" à la place de "Prise en charge du Common Language Runtime MSIL sécurisé (/clr:safe)", c'est que certain environnement d'exécution .NET comme IIS ou SQL Server peuvent obliger à n'avoir que du code "safe".
Paul Bacelar, Ex - MVP VC++
-
J'ai finalement été plus à la source. Cette erreur provenait d'include Borland et j'en auris eu des années pour les traiter. j'ai donc décidé de m'en passer et de prendre les includes de microsoft à la place
Jean Noël Martin
- Marqué comme réponse JeanNoel53 vendredi 11 mai 2012 13:42
-
Pensez quand même à assouplir les conditions de compilations si nécessaire. Des includes non compatibles .NET il en existe même dans le SDK de M$.
Paul Bacelar, Ex - MVP VC++
- Marqué comme réponse JeanNoel53 samedi 12 mai 2012 07:26