GESTIONNAIRE DE SERVICES WINDOWS

Commentaire de vicenzo le 27/01/2008 09:31:53

Remarques suite à tentative de compilation du code :

Erreurs bloquantes :

=> line 0062 : Dépassement de capacité

char szPrePath[4] = "\\??\\";  // -> devrait être szPrePath[5]

=> line 0230 : il faut caster pSvcInfo->szDepends en LPBYTE

RegQueryValueExA(hKey, szDepGrp, NULL, NULL, (LPBYTE) (pSvcInfo->szDepends+dwPos), &dwRet);

=> line 0503 : il faut caster buff en LPBYTE

RegQueryValueExA(hKey, szGrpVal, NULL, NULL, (LPBYTE) buff, &dwRet);

Erreurs très génantes :

=> line 0510 : la variable 'buff' passée à HeapFree() peut ne pas être initialisée et donc avoir une valeur non déterminée
=> line 0510 : la variable 'ItemLen' buff peut ne pas être initialisée et donc avoir une valeur non déterminée

Remarques non bloquantes :

=> line 0139 : variable 'i' non référencée
=> line 0772 : variable 'dwStatus' non référencée

Remarque fonctionnelle :

Dans la liste des services, il serait plus pratique d'avoir le display name et non pas le nom du service. Car si je veux démarrer par exemple La recherche Windows, faut que je me tape le gestionnaire de services Windows pour trouver le nom du service et ensuite venir dans cet appli... Donc ce détail à mon sens faire perdre l'interêt que peut avoir cette appli.

Sinon, j'ai pas encore le temps de voir en détail le reste...

Bon courage !

Commentaire de vicenzo le 27/01/2008 14:28:02

Je compile avec VS2005.

Les erreurs bloquantes quelque soit les options du compilo.

Les autres avec warnings de niveau 4.

Dans tous les cas, il y a trois soucis pouvant conduire à des bugs (déclaration de szPrePath erronée et les variables non initialisées qui peuvent induire des plantages.)

Tu devrais revoir les réglages de ton compilo !!

Commentaire de vicenzo le 27/01/2008 15:03:45

>> Pour szPrePath, aucun soucis je n'utilise que les 4 premiers octets...

Pour toi peut être, sauf que tout le monde ne pourra pas compiler ton code sans avoir à le modifier. Ors tu postes une source pour la partager ! C'est peut être bon pour toi mais primo l'initialisation de szPrePath est fausse, et ensuite y a en certains qui quand ils recupèrent une source et que cela ne compile pas, ils jettent la source à la poubelle. Ma fois c'est toi qui voit !

>> Pour la var buff non initialisee, c'est un ptit oubli, mais y a quand meme extremement peu de chance pour que ca cause un bug, car HeapAlloc reverra une valeur de retour dans tous les cas.

Tétu le monsieur ! Si RegQueryValueExA() à la ligne 498 retourne 0 (on sen sait jamais),
HeapAlloc() n'est donc pas appelé et donc HeapFree() se retoruve avec un buff avec un valeur indéfinie. 99 % de plantage assuré dans ce cas

Sinon, je te déconseille d'explicitement utiliser les fonctions Win32 directement dans leur version xxxA() ou xxxW() mais la forme xxx() car ton code en sera plus générique.
De plus, il sera compilable en ANSI/Unicode si tu utilise des TCHAR au lieu des char par exemple...

Commentaire de vicenzo le 27/01/2008 15:46:31

Je ne m'emballe pas ! je dis seulement qu'il est mieux d'avoir un code propre. C'est tout.

Par contre, c'est quoi ton éditeur ?

Car tu fournis un projet VS et j'utise les outils MS depuis VC5 (donc VC5, VC6, VC2003 et VS2005) et ils m'ont toujours mis les infos bulles sur les versions "génériques" des api Windows.

Tu as quelle version de VS ? car pour moi (VS professional complet), il était impossible de compiler ton code originel !

enfin, je t'ai pas dis qu'il faut uploader toute les 5 minutes, je fais seulement des remarques pour améliorer ton code.... T'es pas obligé de le corrgier dnas la minute ! C'est dimanche, tout de même !


Pour le tetu, c'était seulement pour le

Commentaire de draluorg le 27/01/2008 16:05:14

re,

eh wai je pense qu'on sait mal compris.
Je trouve tes remarques tres pertinentes, j'ai juste voulu relativiser un peu en soulignant le fait que dans l'immediat ca n'empechait pas le bon deroulement du code.

Ce sont pour moi des details certe non negligeable mais qui ne necessite pas necessairement une maj d'urgence.

Pour la version de VS, j'ai la meme que toi si ce n'est qu'elle est mise a jour pour vista, c'est donc un hybride 2005-2008.
Je vais voir pour le niveau de warning (jamais regardé)

++

Commentaire de vecchio56 le 27/01/2008 18:20:10 administrateur CS

- En compilation en mode C, on n'a pas d'erreur (mais le fichier a une extension .cpp donc la compilation en C n'est pas logique)
- Pour szPrePath ce serait absurde de déclarer 5 caractères. Le plus simple est donc:
char szPrePath[4] = {'\\', '?', '?', '\\'};

Commentaire de vicenzo le 27/01/2008 22:48:15

Hum, nne dernière remarque pour la route !

tu dis "en effet il faut compiler en C. "...

Dans ce cas, fournis un svcmanager.c et non par un svcmanager.cpp

Faut rester cohérent *.c => c, *.cpp =>c++

Aller, j'vais prendre mes pillules !!

A+