oui f6 pour générer la solution :p
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 ;)

++

Salut à tous,

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".

++

Salut,

Eh pour le FullPath y pas vraiment besoin d'importer psapi.dll
qui je pense ne fais rien d'autre qu'un NtQueryInformationProcess

#define ProcessImageFileName 27
NtQueryInformationProcess(hProcess, ProcessImageFileName, &wbuff, 1024, &dwLen);

Ceci dit, sais-tu ou je pourrais trouver les declares de la structure peb pour vista x64 ?

++

Wai c'est exactement ça, pas facile de trouver la meilleur solution surtout qu'on est souvent tres seul face à nos choix :s
Des fois j'essai de demander a ma copine ce qu'elle en pense mais bon, ca m'aide rarement je dois dire! :)

Wai c'est clair que les listview mangent surement plus que de reinterroger les process...
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.

erf je me disais justement pourvu qu'il ne me sorte pas que c'est pour le GDIObjects :s

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...

++

Salut,

"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 ?

re,

Erf, c'est encore pire que ce que j'avais pensé...
Mais j'ai plus ou moins trouvé

On prend mon petit projet (celui du zip plus haut)
on vire la declare et l'option du compilo, erreur crtMain machin

on active l'option, l'erreur crtmain est corrigee, mais on a l'erreur fltused

on fait un petit #pragma comment(lib, "ntdll.lib")
et hop plus d'erreur!!!
direction sortie asm... que voit on ?
EXTRN __fltused:DWORD

Voilà qui explique le mistére, tu peux toujours essayer sous vs2005 sait-on jamais...

++

re,

Pas de quoi, de mon coté je ne m'explique toujours pas pourquoi dans mon autre projet cette option suffit au compilateur.
Je viens encore de verifier, si je desactive cette fonction le projet ne compile plus!
Enfin comme on dit, la theorie c'est quand on connait tout mais que rien ne va, et la pratique c'est quand tout fonctionne et qu'on ne sait pas pourquoi...

++

Salut Racpp,

Eh en effet cette option est capricieuse je viens de retester sur un new projet et ca me donne la meme erreur :s
Je suis pourtant actuellement encore sur un projet ou cette option suffit...

Enfin bref avec cette declare ça regle le probleme:

#if defined(__cplusplus)
extern "C" {
#endif
int _fltused;
#if defined(__cplusplus)
};
#endif

Voici un ptit projet de test (avec un ftoa), regarde le code assembleur stu veux moi perso j'ai trouvé aucune trace du crt.
http://systemzeb.free.fr/FloatNoCRT.zip

++