YET ANOTHER PROCESS MONITOR
The Meteorologist
Messages postés
232
Date d'inscription
jeudi 18 janvier 2007
Statut
Membre
Dernière intervention
3 novembre 2011
-
2 janv. 2009 à 02:29
draluorg Messages postés 625 Date d'inscription vendredi 23 avril 2004 Statut Membre Dernière intervention 25 novembre 2010 - 25 nov. 2010 à 19:05
draluorg Messages postés 625 Date d'inscription vendredi 23 avril 2004 Statut Membre Dernière intervention 25 novembre 2010 - 25 nov. 2010 à 19:05
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/48860-yet-another-process-monitor
https://codes-sources.commentcamarche.net/source/48860-yet-another-process-monitor
25 nov. 2010 à 19:05
Pour etre certain vas dans générer>"regénérer la solution".
KEN,
Ok visiblement tes sources ici n'étaient pas du tout à jour, étant abonné à la source j'ai jetté un oeil pensant que tu n'etais pas sous Seven...
Bonne continuation à tous ;)
++
25 nov. 2010 à 13:37
Il y a un autre moyen ?
Merci quand même de m'aider c'est cool ++
25 nov. 2010 à 07:26
24 nov. 2010 à 23:16
Bref, c'est pas grave si cette source pète un cable, c'était juste à titre informatif que je voulais voir ce que ce projet avait dans le ventre.
bye
24 nov. 2010 à 23:00
Premièrement désolé de ne pas être très présent, j'ai pas mal de boulot en ce moment :-p
Pour ce qui est de l'exception, elle concerne quel formulaire, et dans quelles circonstances ?
As-tu essayer de compiler tout le projet dans un premier temps (certaines forms ne sont pas affichables tant que les contrôles utilisateurs ne sont pas compilés) ?
Pour le driver KernelMemory, il est utilisé pour la récupération des noms des handles. Sous Window 7 32-bit aucun problème, mais en version 64-bit çà ne marche plus en effet. En fait le driver est compilé pour les systèmes 32-bit seulement... et ne pourra pas être utilisé sur une plateforme x64 vu qu'en 64-bit les drivers doivent être obligatoirement signés ! Ce qui n'est bien évidemment pas le cas pour ce driver.
Normalement dans la dernière version du programme, le driver n'est pas chargé sur les versions 64-bits, et le programme fonctionne sans problème sans, en mode dégradé (les handles ne sont pas tous listés et/ou leur nom de peut pas être récupéré).
EnableDebug et EnableShutdown normalement devrait passer sans pb, même si le résultat ne fonctionnera que si le compte est autorisé. Encore une fois, si le compte n'est pas admin, le programme fonctionne en mode dégradé (certaines fonctions et/ou informations pas disponibles).
Sinon je conseille de télécharger la dernière version dispo publiquement du code ici : http://downloads.sourceforge.net/project/yaprocmon/YAPM-beta/YAPM-2.4.1/YAPM-v2.4.1-source.zip
C'est normalement beaucoup plus à jour que le code de vbfrance ^^
@+ !
24 nov. 2010 à 19:40
Ken:
Je viens de dl la source pour tester sous seven x64
Il semblerait que ton driver "KernelMemory.sys" ne soit pas compatible :s
Il faudrait le debuger/recompiler sous seven en espérant que cette méthode soit encore possible sur cette plateforme :s
Si mes souvenirs sont bon, ce driver avait pour seul but d'éviter les deadlocks sous XP, il serait interessant de voir le comportement sous Seven sans utiliser ces drivers, avec un peu (beaucoup) de chance il se pourrait que ce problème ne se produise pas sur cet OS
AUS3004:
En attendant AUS3004, tu peux d'aller dans le constructeur clsOpenedHandles.vb et commenter la ligne : Class_Initialize_Renamed()
La tu pourra lancer l'appli elle se lancera mais plantera assez vite, car il en resulte des collections vides etc, il te faudra donc désactiver tout ce qui fait appel aux fonctions et objets de cette classe excepté "EnableDebug" et "EnableShutdown".
++
23 nov. 2010 à 20:31
Une erreur s'est produite lors de la création du formulaire. Pour plus d'informations, consultez Exception.InnerException. L'erreur est : len
J'ai hâte de pouvoir explorer ce projet ;)
17 mai 2009 à 16:06
http://www.vbfrance.com/codes/YET-ANOTHER-PROCESS-MONITOR-REMOTE-VERSION_50027.aspx
@+
14 mai 2009 à 21:24
après de (très) nombreuses heures de code, la prochaine version est presque finie (il reste pas mal de bugs et de features à peaufiner, mais c'est fonctionnel et bien avancé).
Voici les 2 nouveautés les plus importantes :
- REMOTE MONITORING : monitoring des processus/services/modules/handles/threads/.../ distants, via WMI ou via un serveur. WMI est simplifié et offre la liste des process/services/modules/threads uniquement, mais le serveur permet TOUTES les fonctions disponibles en local.
Je crois bien que ce sera le seul logiciel à proposer cela, qui plus est gratuit et open source.
- application entièrement multi-threadée
et aussi :
- code refactoring avec utilisation des fonctions non documentées de Windows pour de meilleures performances (notamment pour les processus)
- plein de nouvelles informations disponibles sur quasiment tous les objets (process, services, threads...+ meta-counters)
- sauvegarde de toutes les préférences (colonnes, forms...)
- IHM avec un Orb à la Office 2007
....
Sinon le code est disponible maintenant via SVN :
svn co https://yaprocmon.svn.sourceforge.net/svnroot/yaprocmon yaprocmon
@+ (je posterais une nouvelle source je pense, car le code a vraiment entièrement été repris, plus rien à voir avec celui-là).
21 mars 2009 à 19:15
C'est la dernière version avant la RC1, toutes les fonctionnalités nécessaires à la release RC1 sont désormais disponibles.
Changelog détaillé :
- 1 graphe par CPU est OK
- options de configuration des intervalles (tray & system infos)
- start hidden OK
- ajout de la fonctionnalité State Based Actions (SBA), voir ci dessous
- Code refactoring (maintenant 2 dll en plus, et projet réorganisé)
- log ok (+ sauvegarde possible)
- compteur runTime dans form detail
- corrections de bugs
- encore des optimisations
Deux principaux points dans cette MAJ :
- refactoring du code (solution à 4 projets, le coeur applicatif est compilé en dll, les providers également) -> meilleure modularité
- ajout de la fonction SBA suite à la demande d'un utilisateur
La fonction SBA permet de lancer des commandes personnalisées (kill, changement de priorité, reboot du pc, lancement d'une commande via cmd, création d'un log, beep...25 disponibles au total) en fonction de l'état des processus (30 variables disponibles, comme la charge CPU, la priorité, la taille mémoire...).
Concrêtement, ceci permet par exemple :
- de réduire la priorité d'un processus dans c:\windows\ si il prend plus de x% du temps CPU
- créer un log si un processus prend plus de x Mo de mémoire
- tuer systématiquement tous les processus lancé par le processus explorer.exe
- changer l'affinité de Internet Explorer à son lancement
- éteindre le PC quand une application tourne depuis plus de x secondes
- ....
Cette fonction est donc extrêmement pratique, les applications sont nombreuses. Elle est unique, je connais pas d'autre logiciel la possédant. Mais elle est TRES DANGEREUSE. Imaginez que vous configuriez de tuer tous les processus localisés dans c:\*...
Du coup j'ai mis un mode simulation : quand la form de gestion des SBA est affichée, les SBA ne sont PAS ACTIVES pour de vrai, mais leur traitement est simulé et le résultat des règles est affiché dans une console (touche F2 pour l'afficher/masquer).
Donc je recommande de systématiquement activer la console de simulation et de vérifier que les règles ne font pas n'importe quoi. Ensuite, on ferme la form de configuration des SBA et les SBA sont lancées (elles se lancent également automatiquement à l'ouverture de l'application).
Bref, très utile (je pense !) mais pas safe donc gaffe !!!!
@+
16 mars 2009 à 21:03
- shutdown/logoff fonctions
- listview groupé pour le monitoring (plutôt que texte)
- récupération d'à nouveau tous les services existants
- infos CPU (form infos générales) OK (+ pourcentages)
- optimisation récupération infos services (refresh que les services modifiés)
- ajout log pour processus
- suppression message avertissement admin
- correction bug (clic sur module frmMain)
- correction bugs recherche suite à la dernière MAJ (trouver les Windows, icones des processus...)
- ajout affinité des threads
- infos générales maintenant toutes correctes
- download des informations sur un processus asynchrone
- classement des items d'un listview par taille et par valeur hexa OK
- affichage tailles formatées
- optimisation refresh liste des zones mémoire
- corrections bugs divers & orthographe
- ajout rapport général
- IHM -> ajout de la version 'menus classiques'
- custom inputbox
- nouvelles options & préférences
- ajout de la fonction State Based Actions
- ctrl+A, ctrl+C pour toutes les listviews
- nouveaux compteurs disponibles dans la listview des processus (io counters)
- affichage de l'historique de toutes les statistiques sur les processus
La prochaine MAJ viendra dans très très peu de temps, se sera une Beta 4.
Ensuite viendra la RC1.
@+
27 févr. 2009 à 18:43
- fermeture handle OK
- meilleure performances (plus aucune erreur systématiquement levée -> tests pour les éviter)
- sélection de colonnes pour tous les listviews
- correction de bugs critiques
@+
22 févr. 2009 à 20:03
@+
22 févr. 2009 à 19:34
Des fois j'essai de demander a ma copine ce qu'elle en pense mais bon, ca m'aide rarement je dois dire! :)
22 févr. 2009 à 19:27
Le but est de ne supprimer aucun item, juste rafraichir les subitems.
C'est le mieux que j'ai trouvé pour avoir
- un code générique
- OO
- pas trop lent
- qui permet de rajouter/supprimer des colonnes au listview
- qui permet d'afficher facilement les items qui viennent d'être ajoutés/supprimés
Il y a surement mieux mais c'est assez galère de trouver la solution la meilleure^^
@+
22 févr. 2009 à 19:12
Je ne sais pas trop ce que tu utilise comme methode pour le refresh, mais si tu stok les infos dans une structure pour comparer et ne modifier la listview que pour les infos differentes de celle affichees ca ne prend presque plus rien.
Mais bon je dis ca juste pour le plaisir d'échanger sur les differentes methodes possible, j'ai fais des tonnes de tools qui listent les process et je remets à chaque fois mes methodes en question afin d'obtenir le meilleur compromis.
Pour mon process mgr il est codé en C.
22 févr. 2009 à 16:07
Effectivement, c'est une solution (de n'afficher qu'à la demande).
M'enfin, dans la mesure ou j'utilise pas NtQuerySystemInformation (ou plutôt pas que), j'ai aussi besoin du handle pour autre chose ^^
Et de toutes façons, le temps CPU utilisé par mon appli est très principalement pris par la partie graphique (gestion propre des listview) et par la couche .Net. Donc je suis plus trop à çà prêt ^^
Cela étant, il est possible (je pense) de récupérer l'info GDIObjects d'une autre manière : ni taskmgr ni process explorer n'ont de handle de process ouvert (et ils affichent l'info pourtant).
Sinon ton process mgr est codé en C++ ?
@+
22 févr. 2009 à 15:47
C'est en effet une des rares infos dynamique interessante qui necessite le handle
Perso mon choix serait de ne l'afficher qu'a la demande sur une zone de proprite par exemple.
L'avantage est que tu n'interroge plus les process (dans un timer) tu te sers juste des infos recuperees lors du listage, sauf si new process alors tu demandes les infos statiques
Enfin c'est un choix comme un autre, mon explorer n'a pas pour vocation d afficher bcp d infos mais de les afficher le plus legerement possible...
++
22 févr. 2009 à 15:06
en fait j'ai une classe cProcess qui ouvre un handle sur le process lors de l'instanciation, et le ferme lors du Finalize().
Le handle sert à plein de choses :
- kill/priority/resume/...
- readProcessMemory (CommandLine ou variables d'environnement par exemple)
Certes c'est inutile de conserver le handle pour ce type d'infos/actions (actions ponctuelles et readPM une seule fois car infos fixées), mais certaines infos changeante en ont besoin, comme :
- GDIObjects par exemple
Le handle est gardé ouvert en permanence.
Le problème dans la version précédente, c'est que des instances de cProcess étaient détruites (par le GC) et recrées à chaque refresh (car mauvaise gestion de la méthode de refresh), ce qui ouvrait/fermait les handles associés.
Maintenant elles sont créées qu'une une fois par processus (en théorie).
@+
22 févr. 2009 à 14:46
"pas d'ouverture/fermeture de handles à chaque refresh des process par exemple)"
Tu as besoin des handles pour raffraichir quoi au juste ?
Perso sur mon dernier process explorer je ne reouvre pas les process car pas besoin dans le sens ou les infos dynamique sont renvoyees dans la structure _SYSTEM_PROCESS
celle la meme que tu recupere avec NtQuerySystemInformation
A moins que tu n'utilise pas cette methode de listage ?
22 févr. 2009 à 14:24
Il en résulte :
- meilleure gestion de la durée de vie des objets (et du coup pas d'ouverture/fermeture de handles à chaque refresh des process par exemple)
- consommation mémoire moindre
- refresh temps réel de toutes les listes dans un temps raisonnable (même les handles !)
- gestion des éléments nouveaux/détruits en couleur pour toutes les listes
- grande optimisation niveau usage CPU (exemple : le refresh des services prend 5 fois moins de temps environ)
Par exemple, la consommation CPU pour refresh les processus/tâches/connexions réseau toutes les secondes est environ du double de celle du taskmgr (donc correct).
Reste quelques bugs (notamment remplissage d'une liste en 2 temps pour le premier refresh).
@+
20 févr. 2009 à 17:05
Bah pour les 100% çà va disparaitre normalement comme problème, puisque de toutes façons faut que j'optimise franchement le refresh des services ^^
Et pi ben pour les icones, aucune idée, je garde en tête le problème, j'essayerais sur d'autres postes pour voir si çà le fait aussi.
Merci
@+
20 févr. 2009 à 16:48
Concernant les icones, effectivement tu n'as pas le problème, je me pose d'ailleurs une question : dans les propriétés système il me dit que j'ai Windows XP SP2, pourtant j'utilise bien windows update et donc normalement je devrais avoir le SP3 (je crois même l'avoir installé un jour). Bref, aucune idée...
C'est ça qui est énervant quand on développe ce genre d'appli, les utilisateurs on toujours une merde sur ton appli qui vient surement d'une merde qu'ils ont fait, ou d'une merde qu'a fait un autre programme. Il faut se blinder, mais impossible de prévoir tous les coups. Si personne d'autre te fait la remarque laisse tomber, j'ai un système tellement moisi je ne le redémarre même plus (vive la veille prolongée) à chaque fois j'ai peur qu'il n'aille pas au bout, et il met 5 minutes. Bref je suis pas une référence il faudrait que je formate.
20 févr. 2009 à 16:33
Sinon pour services.exe, il est sollicité périodiquement effectivement : en fait à chaque refresh complet de la liste des services (toutes les 25 secondes par défaut). Cette partie de code est à optimiser assez largement, mais 100% c'est assez étrange quand même... ??
Chez moi voilà ce que çà fait :
http://ups.imagup.com/02/1235164883_mad.png
Je suis à quelques % maximum de manière périodique.
@+
20 févr. 2009 à 16:03
Pour services.exe c'est périodiquement toutes les 10-15 secondes environ.
Et pour les icones, c'est pour tous les icones qui ont un canal alpha j'ai l'impression (firefox par exemple, icone de dossier, l'icone de ton appli). Ça le fait pas pour l'icone d'une form VB6 par exemple, ou pour un icone qui était fait pour windows 98. Mais le noir, c'est pas tout le fond, c'est juste pour les endroits ou y'a de la transparence avec un pourcentage. Bref j'espère que je suis clair ^^
20 févr. 2009 à 15:48
Sinon pour les icones, je n'ai pas de problème sous Vista ni même avec XP SP3 virtualisés ? C'est dans quelle fenêtre que çà le fait ?
Idem pour services.exe. Cà le fait combien de fois ? (périodique, sporadique ?) Et à quel moment (loading de l'appli ou ?)
@+ et merci pour ces infos (tu as quel OS ?)
(Au passage une MAJ, je viens de m'apercevoir que çà crashait sous XP à cause de fonctions de Kernel32 dispos uniquement sous Vista).
- compatibilité XP ok à nouveau
- positions string en hexa
- voir la position de la string en mémoire
- meilleure gestion des zones mémoire
- Module -> voir en mémoire
20 févr. 2009 à 15:27
Juste une petite faute d'orthographe dans le menu contextuel des processus ("priotiy")
Au niveau des icônes des fichiers et fenêtres, je sais pas comment tu les récupère mais ils sont dessinés sur un fond noir (le canal alpha est aplati sur un fond noir), ce qui rend moyen. Je sais que c'est possible de s'en passer, soit d'une façon bourrine en dessinant l'icône dans une pbx à fond blanc, soit en gérant mieux ce canal avec les api mais je sais pas comment faire (mais je suis presque sur de l'avoir vu qqpart).
Quand je l'utilise j'ai de temps en temps un processus "services.exe" qui se met à 100% du CPU pendant 1 seconde environ, ce qui gèle ton appli pendant cette durée. Je sais pas si ça vient de ton appli ou de mon ordi mais je n'ai experiencé ça qu'avec ton appli.
20 févr. 2009 à 14:02
- emergency hotkeys (raccourcis à affecter pour faire des tâches urgente. Par exemple, mettre Ctrl+Alt+Echap pour détruire le processus dont la fenêtre est actuellement active. Les actions associées sont à implémenter dans le code.)
- graphiques beaucoup mieux gérés
- toolitps + tabOrder
- moyenne affichée dans les graphes
- icones Fugue
- refresh handles temps réel
- plus d'infos sur les handles + option nommés ou pas
- option fenêtres nommées ou pas
- vérification (wintrust) des fichiers
@+
18 févr. 2009 à 00:44
Notamment :
- GNU GPL 2.0 -> 3.0
- éditeur hexa intégré pour lire la mémoire
- GUI comme Process Explorer de Sysinternals (détails sur un process dans une vue séparée)
Changelog complet :
- GNU GPL 3.0
- récupération du handlecount
- récupération des strings d'un processus (nouveau tab) (image et mémoire)
- grande optimisation récupération liste des strings (à optimiser x100 encore)
- recherche dans les strings récupérées (et sauvegarde du résultat)
- récupération variables d'environnement
- tray icon avec graphe d'utilisation CPU/mémoire
- hex editor pour lire la mémoire
- priorités des threads OK
- gestion des privileges terminée
- séparations des infos détaillées (nouvelle interface style Process Explorer)
- double click lvTask -> processus associé
- refresh temps réel des modules/threads/windows/regions mémoire/connexions réseaux
- optimisation récupération des infos sur les modules
- nouveau compteur pour les processus (pourcentage d'utilisation moyen)
- ajout de la CommandLine pour les processus
- ajout d'une form de gestion des fenêtres ouvertes par YAPM
- nouvelle police de caractères
@+
12 févr. 2009 à 23:04
- nouvelle about form + licences des codes utilisés qui sont pas dans le domaine public (ribbon + icones pas encore utilisées mais bientôt intégrées)
- adresses remote des connexions TCP ajoutée
- résolution DNS asynchrone des connexions TCP ouvertes (oh yeah c'est plus intéressant qu'une IP)
- nouveaux process en vert, process deleté en rouge (idem pour tasks et connexions)
- (enfin !!) une bonne récupération du username des processus (avec domaine en prime)
- reconstruction globale du code de gestion des taches (nouvelle classe héritant de cWindows)
- récupération de la charge CPU par tâche
- affichage du CpuUsage par défaut pour les processus
- tri temps réel des listviews process, task, service (par colonne)
- corrections diverses
- optimisation du démarrage de l'application (suppression de refresh inutiles)
Et aussi, passage de la solution à une version 10 (avec Visual Studio 2008).
Pour utiliser la version 2005 de VS, changer dans le fichier solution :
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
par :
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
et çà devrait fonctionner.
@+
10 févr. 2009 à 18:15
- bonne optimisation du refresh des informations sur les modules
- grande optimisation du refresh des informations sur les services (+ nouvelles informations disponibles)
- choix des colonnes pour les services (à perfectionner, quelques bugs)
- optimisations diverses (meilleure gestion des erreurs notamment)
- icones 32 bits (^^)
- form pour voir les infos globales sur le système (infos CPU un peu daubées, et graphes à perfectionner)
@+
8 févr. 2009 à 23:18
Raah mais pourquoi les imagelist sont elles 8-bits par défaut ??
Merci bien ^^
@+
8 févr. 2009 à 23:00
Bravo pour toutes ces maj!
Histoire de chipoter encore un peu sur des détails, n'aurais tu pas oublié de mettre ton imagelist sur couleur 32bits ?
++
8 févr. 2009 à 18:45
2) ajout de la gestion des connections TCP/UDP ouvertes par les processus (à améliorer dans le future, pour l'instant très basique mais fonctionnel).
7 févr. 2009 à 17:26
7 févr. 2009 à 15:15
- ajout fonction 'Fin de tache' (tasks tab terminé)
- optimisation du rafraichissement de la liste des processus
- correction de l'affichage de nouveaux processus avec plus de colonnes
- monitoring de la création/destruction des services OK
- suppression processus avec touche Delete
- gestion de l'affinité pour les processus (form + compteur)
7 févr. 2009 à 12:23
Mais pour une fois je vais essayer de terminer complètement ce projet !
Sinon pour l'affinité, l'option est grisée pour le moment (clic droit sur un processus), mais le code est presque terminé. En fait j'ai le code VB6 fonctionnel correspondant, je suis en train de le convertir proprement ^^
@+
7 févr. 2009 à 09:42
Encore félicitation à toi, il est rare de trouver des sources aussi complètes, et mises à jour aussi fréquemment.
Une fois postées, elles sont en général laissées à l'abandon.
Sinon, je ne vois pas encore l'utilité mais le taskmgr permet de définir sur quel core du proco un processus doit travailler (cf "Définir l'affinité").
6 févr. 2009 à 23:33
Si tu as d'autres remarques de ce type (nouvelles fonctions... etc), je suis vraiment preneur !
@+
6 févr. 2009 à 22:33
En fait actuellement je planche sur un système d'affichage des processus sous forme de contrôle hybride TreeView/ListView (en gros un listview hierarchisé par liens de parentés, avec collapse/extend, comme dans 'process explorer').
Du coup je voulais implémenter cette fonction quand ce contrôle aurait été prêt (terminer l'arborescence d'un process au final est surtout pratique quand on voit graphiquement tous les child items à tuer), mais effetivement taskmgr offre la possibilité de le faire bien qu'on ne connaisse pas aisément les parentés entre processus (simple listview).
Bon bref du coup je l'implémente, si taskmgr le permet, y a pas de raison ^^
Merci, @+
6 févr. 2009 à 19:45
Question : Peut-on comme avec le taskmgr terminer l'arborescence d'un processus ?
6 févr. 2009 à 19:00
Logiciel complètement stable (sauf défauts de page un peu abusés !)
- ajout onglet principal "Taches"
- démarrage vraiment bien plus rapide qu'avant
- les options sont toutes OK maintenant
- possibilité de remplacer taskmgr par YAPM (safe)
- 'selected associated item' affiche l'item avec la méthode EnsureVisible
- possibilité de sélectionner les services associés à des processus depuis lvProc
- ajout des icones pour les fenêtres
- nouveau compteur pour les processus (RunTime)
@+
5 févr. 2009 à 18:57
Notamment la stabilité du logiciel (plus de crash après longue utilisation !)
Passage en beta 3.
- bug de dépassement de mémoire corrigé
- bug lors du loading en mode non admin corrigé
- form resizement mieux géré
- suppression de lignes de code inutiles
- correction bugs mineurs dans l'IHM
- "display all processes" correctement géré
- bug lors du téléchargement terminé corrigé
- CPU usage correct (nbre processeurs pris en compte + bon formatage)
- form pour informations générales sur le système
- ajout GDI/User objects count
- ajout de la possibilité de recherche un objet à monitorer
- fichier de configuration directement dans le même dossier que l'exécutable
1 févr. 2009 à 18:29
Notamment la récupération de nouvelles infos (privileges, I/O, plus de services et lien avec les processus).
Change log :
- Suppresion du setup (distribution de l'application par fichier zip)
- Simplification de l'IHM (suppression d'onglets/boutons inutiles/surchageant trop)
- Auto update avec téléchargement auto de la dernière version (bug trivial à corriger aux 100%)
- Choix des colonnes pour les processus (dbl click sur le listview -> premier refresh à peaufiner)
- Déchargement modules OK
- Sauvegarde de rapports OK pour preque tous
- Meilleure interface (zones redimensionnables)
- Meilleure gestion des services (plus de services listés, plus d'informations, processus du service récupéré)
- Toutes les fonctions sur la gestion des fichiers sont désormais disponibles
- Recherche plus rapide
- Optimisation de l'affichage (plus aucun scintillements et temps plus cours de remplissage des listviews)
- Très (très très) nombreux bugs résolus
- Nouvelle interface pour les processus (zone 'détails' en bas, détachable dans le futur)
- Récupération de nouvelles stats pour les processus (informations d'I/O, .Net applications (todo)...)
- Graphe d'utilisation CPU/Mémoire/I-O par processus (à peaufiner dans l'affichage)
- Gestion des privileges des processus (changement de status à corriger, actuellement désactivé)
- Gestion des zones mémoires (l'HEX editor de mémoire arrivera plus tard)
- Gestion des services par processus
- Icones dans les menus
- Monitoring des services créés/détruits avec info dans le tray (à peaufiner)
- Création d'un fichier de log (clic droit sur le bouton Tray -> Show log)
- Optimisation générale de récupération des infos grâce à une meilleure programmation OO (dissociation complète de l'IHM et des objets associés manipulés pour les listviews)
- ....
@+
18 janv. 2009 à 19:12
- Pleins pleins de bugs résolus
- ajout de nouvelles fonctions diverses
- peaufinements divers
- ajout de la production de rapports (sauf pour les processus et le monitoring)
@+
11 janv. 2009 à 16:00
-> Toutes les fonctions générales sont désormais disponibles (sauf les jobs), il ne reste donc plus qu'à :
- faire les fonctions particulières manquantes (cf description)
- corriger les (nombreux) bugs
- optimiser le code + tests détaillés
@+
10 janv. 2009 à 18:09
MAJ : gestion complète des threads des processus (priorité, pause/resume/kill, informations disponibles par le framework.net)
@+
9 janv. 2009 à 21:44
8 janv. 2009 à 19:55
8 janv. 2009 à 19:45
@+
8 janv. 2009 à 19:44
1) Ajout de la fonction de monitoring (Monitoring complet de l'ensemble des objets Windows, identique à l'analyseur de performances dans perfmon.msc, avec gestion plus complète de l'échelle de temps).
Récupération des infos via la classe PerformanceCounter.
2) Optimisation des performances globales, et plus particulièrement de la récupération des informations sur les processus (abandon de la classe Process du framework .Net, utilisation d'API).
3) Correction diverses.
Par contre il y a un bug dans la récupération des attributs de processus :
- temps CPU
- start time
(mauvaise conversion de temps -> valeurs fausses)
A corriger plus tard :-)
4 janv. 2009 à 16:07
merci !
@+
4 janv. 2009 à 15:49
En fait oui les columheaders sont bien au style vista, mais pas la selection...
Du moins d'apres ta capture d'ecran...
Pour comprendre ouvre le taskmgr sur l'onglet process et compare la selection a ta listview...
++
4 janv. 2009 à 15:42
chez moi la listview possède déjà le style visuel de Vista sans avoir à rien faire ?
Idem pour mon XP virtualisé.
Tu es sous quel OS ?
@+
4 janv. 2009 à 15:22
SetWindowTheme vas donner le theme de l'explorateur a la listview
tu fais SetWindowTheme(Lv.handle, "explorer")
Ca change le style de la sélection, ca fait comme la lv du taskmgr.
++
4 janv. 2009 à 14:54
pour SetWindowTheme je ne connais pas je vais jeter un coup d'oeil ^^
Sinon pour le ribbon malheureusement je ne connais pas l'équivalent pour du C.
@+
4 janv. 2009 à 14:20
Ergonomie originale ^^
Ca me donnerait presque envie d'en faire un du genre en C (si quelqu'un connait un Rubban utilisable en C)
Pour la ListView, un petit SetWindowTheme s'impose ;)
Bonne continuation ;)
++
3 janv. 2009 à 23:09
Oui effectivement on sent les vacances ;-)
Sinon il manque encore quelques fonctions, comme par exemple sur les threads et les fenêtres et çà sera à peu près rassemblé en .Net avec un mix API/Framework ^^
Après faut que je rajoute quelques fonctions perso, par exemple en ce moment je fais le "monitoring" à proprement parler : l'utiisateur ajoute un "compteur" personnalisé sur les informations qu'il veut, et on trace le graphe à partir de çà ; l'utilisateur peut librement visualiser l'évolution de son information en fonction de la date/heure choisie.
@+ ^^
3 janv. 2009 à 22:46
Les fonctionnalités sont déjà vues mais ont le mérite d'être (presque ?) toutes rassemblées, ce qui est un sacré boulot. On sent les vacances ;-)
2 janv. 2009 à 18:00
2 janv. 2009 à 16:59
http://www.codeproject.com/KB/toolbars/WinFormsRibbon.aspx
@+
2 janv. 2009 à 16:14
Est-il possible d'obtenir les sources des controls Ribbon ?
Bonne prog
++
2 janv. 2009 à 13:01
Je réutilise des méthodes du framework (exemple SetAttributes dans cFile qui fait appel à IO.File.SetAttributes) de manière temporaire, certaines seront remplacées plus tard par des plus performantes.
@+
2 janv. 2009 à 11:13
@+
2 janv. 2009 à 11:04
A+ et bonne année au fait.
2 janv. 2009 à 10:43
Le second indique que ton exe n'est pas au bon endroit (il ne trouve pas le fichier de préférences avec les chemins relatifs du coup il le recréé).
Le troisième est un readme standard.
En fait, c'est le second qui m'indique que tu as du soit :
- tester dans l'IDE en debug (et du coup c'est normal faut faire en release pour que l'exe soit dans le dossier correct)
- lancer l'exe hors de son dossier d'execution (dossier qui contient un dossier config, et quelques autres fichiers)
@+
2 janv. 2009 à 10:33
Je suis sur XP Pro SP2 (mon professionnel donc légèrement bloqué, même si je connais le compte admin lol).
Pour les messages, j'en ai plusieurs (de toi je suppose au départ)
- You are not logged as an administrator, ....
- Préference file missing or corrupted, ...
- une msgbox please read this.
- l'exception : Impossible de trouver une partie du chemin d'accès .... pour le fichier config.xml.
Je te précise quand même que j'ai commencé par lancer le prog en non admin.
A+
2 janv. 2009 à 10:20
J'ai testé à la va vite sur un XP virtualisé en non admin et çà marchait, qu'as tu comme OS et quel est le message ?
@+
2 janv. 2009 à 10:18
Je sais que c'est moche, mais j'ai eu la flemme de tout recoder en OO lol, d'autant que c'est pas ce qu'il y a de plus rapide niveau temps d'exécution. Y a qu'à voir l'appel à Process.GetProcessById qui est horriblement lent mais que j'utilise quand même pour l'instant.
Il aurait fallut que je recode une classe Process entièrement, par soucis de temps de codage j'ai uniquement mis les fonctions qui auraient été statiques (enumerate..etc) dans un module mdlProcess, et j'ai entassé comme un sale tout ce qui avait un rapport avec un process dans le même module.
Mais par contre les structures j'ai pas toujours le choix (utilisation dans l'appel aux fonction API) et là je ne changerais pas de partout.
Tu as entièrement raison, je vais changer quelques trucs, c'est pas bien compliqué de rajouter la notion de classe, et çà sera moins bordelique.
@+
2 janv. 2009 à 10:13
Je suis assez d'accord avec les remarques de The Meteorologist et je vais ajouté un bug.
Tu as précisé qu'il fallait évidemment être loggé en admin (logique) pour utiliser ton code. Cependant as-tu fais la vérification que le compte loggé est bien l'admin ?
J'ai fais le test et je t'avoue que j'ai trouvé une belle exception.
Sinon j'aime bien l'interface et le concept. Merci : 7/10
2 janv. 2009 à 02:29
Aussi non, mis à part ça c'est très bien fait.
++