Je vais r�pondre bout par bout �a devient tout much en quote
�a j'avoue que je n'en sais rien car je ne me suis jamais servi de CPU-Z , je ne sais donc pas comment cela fonctionne...seulement � moins que je sois compl�tement � cot� de la plaque il me semble que l'on doit obligatoirement passer par une GUI pour les valid non ?
Oui, MFC32 qui plus est, mais l� on entre dans un autre domaine, d'une mani�re g�n�rale CPU-Z n'est pas limit� par une utilisation de GUI, la moiti� des choses qu'il d�tecte crash avant la GUI. Le probl�me de CPU-Z n'est en fait absolument pas l�, mais malgr� tout il reste plus light lorsqu'il s'agit de faire une sauvegarde : CPU-Z charge au d�but la majorit� des infos/MFC, donc en fin de compte au moment de valid� il te reste plus qu'un banal refresh GUI et sauvegarde txt avec cryptage, rien de plus, �a reste plus l�ger qu'un dump JPEG de l'�cran
D'un c�t� tu as un refresh (chose "naturelle" qui se fait naturellement CPU-Z ou non) de l'autre un dump via probablement getWindowsRect & co...
Ce n'est pas moins qui le dit.
C'est bien pour �a que SnapMAx n'utilise pas de GUI , qui est facultative...
cf plus bas tu vas comprendre plus ce qu'est le terme GUI dans windows...
D'accord et pas d'accord...
Un programme n'�tant qu'un ensemble de variables et d'instructions stock�s dans la RAM si l'on y fait pas appel le CPU s'en fout, seulement on m'a demand� de dev un programme qui ne squattait pas la RAM inutilement quand on ne s'en sert pas, ce que j'ai fait.
La ou je suis dubitatif, c'est sur la question des process...
Allez, soyons logiques, qui se charge de g�rer et de lister l'ensemble des process en vigueur , le syst�me d'exploitation ok ? le grand chef d'orchestre...
On ne viendra pas me faire croire qu'un chef d'orchestre quand il dirige 2 musiciens ou quand il en dirige 2000 c'est la m�me chose pour lui...
Il suffit de consulter le task manager de windows...si il est capable � tout moment de lister tout les process qui tourne et en plus d'afficher leur consommation ressource c'est bien qu'il y � un �change d'infos entre les deux non ?
Et ce support ne se fait surement pas gratuitement...
La th�orie des syst�mes d'exploitation ne se limite pas � un banal check, c'est nettement plus complexe que cela. Sache que quoi qu'il en soit, qu'il y est 500 process ou 2, d'un point de vue syst�me d'exploitation tu auras toujours le m�me r�sultat : toutes les 16 ms environ le syst�me r�allou un message au processus suivant, en gros toutes les 16ms un nouveau processus r�cup�re l'exec syst�me et peut travailler avec (l'API getMessage est l� pour cela dans ton programme C...), �a veut donc dire que 2 ou 200 processus, ou m�me un seul, c'est la m�me, tu augmentes juste la taille des variables g�rant ce passage d'un processus au suivant, ni plus ni moins.
Je te dis franchement humblement "peut �tre que tu a raison" car question clocking je suis nul part, mais alors �a voudrait dire que tout les clockeurs qui se font embett� a "tweak�" leur OS en �liminant tout les process inutiles le font dans le vent...? Y'en � qui vont �tre d��us...
Pour avoir �ut bcp de th�orie sur les syst�mes et avoir beaucoup test� (pour rappel je suis oceur ^^), cela n'a peut d'importance. tweak� ou non le syst�me r�agit juste plus vite, l� est la diff�rence.
Les plantages qui n'interviennent que plus loin (raison majeur des tweaks) vient simplement de processus "parasites" qui sollicitent trop le syst�me, les enlever � donc un sens nous sommes d'accord, mais en aucun cas cela changera l'oc max d'un point de vue de l'os noyau
Je suis d'accord sur le fait qu'avoir une GUI quand tu recherche la perf �a suxe...et je le r�p�te, c'est bien pour �a que SnapMax n'en � pas.
Oui mais je n'avais pas le programme sous la main
Dur dur de savoir ce genre de choses dans ces cas l�
Essaie le et essaie SnapMax, tu vera.
M�me si j'ai d�j� le mien, j'y compte bien
Task manager tout simplement...si maintenant tu viens me dire que c'est de la daube et que c'est pas fiable alors...
Ca donne une bonne indication, mais �a n'est pas fiable
Utilise plut�t process explorer pour ne citer que le plus connu et appr�ci�
Alors l�, c'est bien parce que tu ne l'a jamais essay� !
Amuse toi un peu � prendre une centaine de screens d'affil�s...Tu verra comme ton CPU va tirer la langue au bout d'un moment...
Contrairement a capture SnapMax se comporte exactement de la m�me fa�on que tu prenne 1 ou 1000 screens...
Je pourrais expliquer pourquoi mais je suis un peu fatigu� la et je bosse demain.
Quand j'aurais un peu de temps ptete que je m'y collerai � d�cortiquer les deux, l� comme �a j'ai pas le temps ^^
Bon allez on d�marre (attention �a cause prog now :o)
Les captures parlent toujours plus que les mots, voila le r�sultat via un programme pour le moins incomplet, mais je pense que malgr� le fait qu'il ne liste pas tout tu verras tout de suite de quoi je parle en terme de GUI... D'une mani�re g�n�rale, une GUI sous windows correspond � tous programme hors 16bis/DOS, tu comprendras ais�ment que malgr� le fait que tu n'es pas de GUI a proprement parl� tu te retrouves avec ce bordel j'y pris soin de laisser le nom du programme que j'ai utilis� pour te montrer �a si cela t'int�resse :
Bon une rapide lecture va t'aider � mieux comprendre ce qui va de ce qui ne va pas (en toute objectivit�, moi je suis pour la concurrence dans le domaine de l'oc
, pourvu qu'elle soit frenchie
)
Explication rapide : ce que tu vois, c'est toutes les DLL qui interviennent durant l'ex�cution de ton programme, qu'elle soit appel�es directement ou indirectement.
Deux choses me frappe :
-GDI32 ('oula...)
-La redondance (bonne chose)
GDI32 est certainement la bibli que tu utilises pour capturer, d�j� je remet les choses au point : elle est lourde, elle plante, son seul avantage est d'�tre facile d'utilisation. Pour tout te dire, actuellement d'apr�s le programme rien que GDI32 fait appel � pas moins de 683 fonctions externes, r�parties dans plus d'une centaines de DLL...
Manque de bol, tout ce monde prend de la place et n'est jamais r�pertori� car charg� par le syst�me et non ton programme (tu ne verras donc jamais apparaitre la taille de tout ce bazar).
Je me souviens que Intel proposait une dll unique pour la manipulation des jpeg, ce serait une nettement meilleure approche de la chose...
-La redondance : �a par contre c'est un bon point, �a indique que le syst�me, une fois charg� la centaine de DLL de gdi n'en chargera pas d'autres puisques la plupart sont directement d�j� charg�s pour GDI...
Donc bon point
Il y a deux trois autres choses qui me choquent, mais �a reste minime.
Autre "d�tail", des programmes comme UPX Shell existent, c'est pas fait pour rien
D'une mani�re g�n�rale : tu utilies 3 DLL principales, donc c'est un tr�s bon point, l� ou c'est moyen c'est GDI, c'est � �viter si possible, � toi de voir si le jeux en vaut la chandelle, quand j'avais fait mon screenshot il �tait clairement apparut que non.
Par contre l� ou �a fait mal : GDI passe par un stockage ram et un traitement ram, seul soucis : GDI est une bibli Windows, ce stockage et ce traitement passe donc par du BMP non compress� � quelques Mo... D'ou la lib d'Intel (si elle existe encore) qui elle travaille d�s le d�but en JPEG
Voila ce ne sont que des conseils, sinon sous Vista x64 �a passe sans trop de probl�me, fait gaffe par contre je ne sais pas si c'est mon OS qui d�conne mais une fois lanc� je me retrouve avec une pile de rundll32 en stock qui se d�chargent environ toutes les 2/4 secondes. Probablement qu'il va falloir revoir ta mani�re de hook sur le clavier
