Détection dans une DLL du mode debug ou release d'un programme appelant

Bonjour,

J'ai un programme qui fait appel à une DLL. J'ai les sourcres du programme et de la DLL et je peux les recompiler à la demande. La DLL est compilée uniquement en mode release. Le programme est compilé en mode debug et en mode release.

Je voudrais savoir s'il est possible, de manière pas trop usinagazesque, dans le code de ma DLL (en mode release donc) de savoir si le programme appelant est en mode debug ou en mode release afin de modifier le comportement de la DLL si le programme utilisateur est en mode debug.

Merci pour vos réponses

Pour un test rapide, je dirais tester si MSVCRxxD.DLL est chargée (par GetModuleHandle()). Mais ça ne détectera rien pour les programmes liés statiquement...

Citation:

---

Envoyé par Médinoc

Pour un test rapide, je dirais tester si MSVCRxxD.DLL est chargée (par GetModuleHandle()).

---

Pas idiot

Citation:

---

Envoyé par Médinoc

Mais ça ne détectera rien pour les programmes liés statiquement...

---

liés statiquement ... à MSVCRxxD.DLL ou à ma DLL ?

Citation:

---

Envoyé par ram-0000

liés statiquement ... à MSVCRxxD.DLL ou à ma DLL ?

---

À libcmtd.lib (CRT statique) au lieu de msvcrtd.lib (lib d'importation de MSVCRxxD.dll)

Je vais faire un bout de code comme cela et utiliser la fonction GetModuleHandleEx()

Code:

---

1 2 3 4 5 6 7 8 9 10 11

HANDLE handle if(GetModuleHandleEx(L"MSVCRxxD.dll", GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT) == FALSE) { // traitement de l'erreur // probablement que le process utilisateur n'est pas en mode debug } else { // le process utilisateur utilise la DLL MSVCRxxD.dll, il est donc en mode debug // traitement supplementaire en mode debug }

---

Par contre, dans le cas où je récupère un HANDLE valide, qu'est ce que j'en fais, je l'oublie (je n'en ai plus besoin après) et j'ai un handle leak (c'est pas très grave mais c'est pas très propre). Je ne peux pas appeler FreeLibrary() sinon, cela va décherger la DLL ce qui ne me semble pas une bonne idée.

1. GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT possède le même effet que GetModuleHandle() tout court. Comme le nom du flag l'indique, pas besoin de faire un FreeLibrary(), et pas de leak non plus.
2. Normalement, il ne s'agit pas d'un HANDLE kernel mais d'un HMODULE, qui sous Win32 représente l'adresse du module dans la mémoire du process.

Un petit retour sur l'implémentation de la méthode "Médinoc"

Citation:

---

Envoyé par Médinoc

Pour un test rapide, je dirais tester si MSVCRxxD.DLL est chargée (par GetModuleHandle()). Mais ça ne détectera rien pour les programmes liés statiquement...

---

Effectivement aucune détection possible par ce moyen des link statiques avec le runtime C.

Autre problème, il y a plusieurs versions du du runtime C (version 8 et 9 au moins sur ma machine). Donc il va falloir faire plusieurs essais successifs pour être sûr de détecter l'usage du runtime C en version Debug. De plus il est probable qu'une version 10 et plus va voir le jour dans le futur.

Autre chose encore et je ne sais pas y répondre : Est ce que les binaires compilés par d'autres environnements/compilateurs que Visual Studio utilisent le runtime C Microsoft ? Est ce qu'ils n'ont pas leur propre runtime ?

Tout cela pour dire que j'abandonne cette méthode car elle n'est pas suffisemment "déterministe" à tous les coups.

D'autres idées ?

Je sais que MinGW utilise le run-time Microsoft, plus ses propres extensions (comme les fonctions de <dirent.h>).
J'en ai pour preuve que MinGW utilise le printf() de Microsoft, avec tous les inconvénients qu'il comporte : Absence de spécificateurs C99 pour les size_t et cie, non-gestion des long double.