GESTIONNAIRE DE SERVICES WINDOWS
cs_vicenzo
Messages postés
178
Date d'inscription
mardi 16 août 2005
Statut
Membre
Dernière intervention
25 août 2010
-
27 janv. 2008 à 09:31
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 30 janv. 2008 à 14:55
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 30 janv. 2008 à 14:55
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/45526-gestionnaire-de-services-windows
https://codes-sources.commentcamarche.net/source/45526-gestionnaire-de-services-windows
30 janv. 2008 à 14:55
Faut illico renommer en c le 1er fichier au lieu de cpp, se fait en 2 clics dans explorateur de solutions de VC++.
27 janv. 2008 à 23:03
Ceci vient du fait que j'utilise le generateur de template de BruNews qui par genere un fichier .cpp pour un projet Cdlg. Je sais pas si c'est voulu ou si c'est une erreur de sa part.
Enfin bref, je comprends la confusion et je remplacerai ca aussi.
++
27 janv. 2008 à 22:48
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+
27 janv. 2008 à 22:42
<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)> erf wai je comprends mieux now, en effet il faut compiler en C.
Merci pour vos commentaires
++
27 janv. 2008 à 18:20
- Pour szPrePath ce serait absurde de déclarer 5 caractères. Le plus simple est donc:
char szPrePath[4] = {'\\', '?', '?', '\\'};
27 janv. 2008 à 16:26
normalement aucun compilateur ne laisse passé cette erreur . j'ai aussi les warnings
et 2 erreurs de cast. il est vrai que si j'étais encore débutent en voyant ton code je l'aurais mis a la poubelle on s'attend a un code sans erreur .
allez bonne continuation mais je te conseil de corrigé les erreurs car brunews aime pas les sources buggé
27 janv. 2008 à 16:05
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é)
++
27 janv. 2008 à 15:51
"...fait que fournir un pointeur dans les choux à HeapFree() c'est pas "pas grave" mais dangeureux... Toujour être sur qu'un pointeur a été initialisé dans le code avant d'appeler une fonction de libération".
Cela dit, c'est mon VS2005 qui me l'a signalé car ayant survolé le code, je ne l'avais vu...
Donc, un conseil (surtout quant tu diffuses du code), compile un coup avant avec un niveau de warning 3 ou 4. Cela permet de détecter des choses que l'on n'a pas vu ...
Bon courage.
27 janv. 2008 à 15:46
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
27 janv. 2008 à 15:32
Pour ceux qui jette un code pour si peu, bah c'est a eux de voir pas a moi.
Pour le code generique, qui a dit que je voulais du generique? Non plus serieusement j'utilise les versions xxA des api pcq sinon l'editeur ne m'affiche pas les parametres en infobulle mais seulement "#define RegOpenKeyEx RegOpenKeyExA" ce qui n'est pas tres pratique!
Dans tous les cas, j'ai bien dit que j'allais corriger donc y a pas de je suis tetu mais juste pas envie de reuploader toutes les 5 minutes. Et je precise quand meme que le code est fonctionnel et que rien n'empeche reellement la compil si ce n'est tes reglages compilos.
Je viens de tester sur une instal fraiche de vs en vm et ca a compiler direct dans le moindre warning...
Voila des que j'ai une minute je up les corrections
++
27 janv. 2008 à 15:03
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...
27 janv. 2008 à 14:50
Pour szPrePath, aucun soucis je n'utilise que les 4 premiers octets...
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.
Quoi qu'il en soit je corrigerai ca mais je vais attendre de voir s'il y a d'autres erreur pour pas faire un maj pour changer 3 lettres...
++
27 janv. 2008 à 14:28
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 !!
27 janv. 2008 à 13:41
Tu compile avec quoi?
27 janv. 2008 à 09:31
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 !