Reprise du message précédent :

Prend le 1er qui aura implémenté avec succès LaunchMonitoringProgram et CloseMonitoringProgram

 
Chiche Pourtant c'est pas difficile, un ShellExecute du chemin vers l'exe trouvé dans le registre

 
Ta fais du Pascal toi un jour dans ta vie

http://msdn.microsoft.com/en-us/li [...] 85%29.aspx

C'est surtout une API Windows.

 
Oui c'est exactement ça qu'on utlisais sous Lazarus (bien pourris ce truc)
 

 
Je me fais moins chier avec de Process.Start():
 
 

 
J'ai déjà codé la partie qui récupère le chemin dans le registre    
Ce soir j'essaye le ShellExecute.

En plus de ça j'ai donné la clé à récupérer dans la BDR (attention au piège !) dans l'un de mes posts

Oui enfin les plugins on les a fait il y a 6 ans 4 ans, et on ne les a jamais modifié (enfin si, juste une fois lors du passage Everest->Aida64 où il fallait faire un 'replace all' dans le code)
De plus, depuis qu'on a annoncé publiquement notre API de monitoring, il y a eu environ 0 personne intéressée et cela nous a vexé
Bref, je ne suis pas bien convaincu que l'utilité de la chose

 
La ligne au dessus est symptomatique  
 
Si tu veux un exemple :
 

 
Source : http://forums.codeguru.com/showthread.php?t=302501
 
Pour aida64, le flag SW_SHOWNORMAL est celui à utiliser.

 
C'est exactement ma position Je suis pour l'ouverture et co, je suis super content que vous me fassiez, vous deux, les plugins en question Mais je suis pas persuadé que cela déchaîne les foules

Le gagnant est embauché à plein temps pour le dev de OCCT.
 
Et à ce rythme là, OCCT(c)(r) ( ), deviendra un projet communautaire et ouvrira le code

 
Le code sera ouvert le jour où je déciderai d'abandonner le projet définitivement. En attendant, par contre, c'est non

 
J'ai rajouté une mention

Thx

A l'époque où tu n'avais pas de built-in et où l'on avait pas encore conçu les plugins, ça pouvait avoir un sens. Aujourd'hui la très grande majorité utilise le built-in, et les autres utilisent un soft déjà supporté par un plugin.
Du coup tout cela va rester très anecdotique. Et puis l'API est en 1ère page, donc ça n'empêchera pas quiconque de pouvoir proposer son plugin maison, avec ou sans sources, ou même de le garder que pour lui

 
On est bien d'accord. Il a fallu que tistou me rapporte le bug aida64 pour que quelqu'un le découvre. Je suis pas sur que les gens utilisent les autres plugins.
 
Bref, on verra, mais si je propose une feature, autant qu'elle marche, même si le built-in est majoritairement utilisé.

Un p'tit sondage pour voir à quel point il est utilisé ?  
 
J'en avais fait un pour CSMT et j'ai ça comme résultats (en ne regardant que les votes utiles) :
 - 6.6% n'utilisent pas de monitoring
 - 31.8% utilisent le monitoring intégré
 - 53.3% utilisent un plugin + soft externe
 - 8.3% voudraient un nouveau plugin (dont 1.7% seraient prêt à le faire eux-même) -> aucun d'entre eux ne s'est manifesté
 
Mais avec OCCT, le built-in est bien plus complet et l'emporterait haut la main. Mais dans quelles proportions...

2ème édition

Le spawn marche.
 
Qu'on soit d'accord:
 
1 - Le Hidden de LaunchMonitoringProgram(), c'est le paramètre à ShowWindow() ?
 
2 - CloseMonitoringProgram() tu ne semble pas l’appeler ?
 
3 - "Forced"  c'est quoi ? (pour moi CloseMonitoringProgram() => TerminateProcess() )
 
Au "Forced", tu veux quoi que je fasse un WaitForSingleObject() sur le handle pour être sûr le process soit bien mort ?
 
---
 
Remarques:
 
1 - Aida64 fait un ShowWindow() après l’initialisation (option pourrie dans les préférences), l'état de visibilité au CreateProcess() n'a pas d'impact.
2 - Pareil la mémoire partagé est ouverte trop tard par rapport au OpenMonitoring().

1) Oui : TRUE = SW_SHOWMINIMIZED, FALSE = SW_SHOWNORMAL

2) Je ne sais pas mais ça fait partie de l'interface, et moi je l'utilise

3) Non, ça ne concerne pas la façon de le fermer, mais la décision de le fermer ou pas. FALSE = on ferme que si le logiciel a été ouvert suite à LaunchMonitoringProgram() pas lorsqu'il était déjà lancé, TRUE = on ferme le logiciel dans tous les cas. Le mot "forced" est peut-être mal choisi.

De mémoire, voilà comment j'utilise tout ça :

Je vérifierai à mon retour. Corrigé.

Pareil, j'arrive a spawn l'appli.
Par contre ça merdouille.
OpenMonitoring() est lancé trop tôt.

Avec Everest Aida64 toute la difficulté réside dans la prise en compte du Hidden à TRUE. J'hésite à poster mon vieux hack pourri ici (en tout cas, pas maintenant, la sélection du plugin est en jeu !)

Pour la mémoire partagée initialisée tardivement, c'est pas très grave, si ?

Aida64 est ouvert bien avant qu'OCCT est fini son "démarrage", donc pas de problème avec la mémoire partagé, je pense

Désolé, je suis en pleine bourre au taff.

Pour OpenMonitoring qui arrive trop tôt, vous devez lui faire faire une pause de quelques secondes jusqu'à ce que la mémoire partagée soit ouverte ou activée.

Ca signifie au pire que l'utilisateur qui n'a pas aida64 attendra un peu avant de voir "je le trouve pas" (et encore), mais spa grave.

Bref, faites un sleep dans OpenMonitoring jusqu'à ce que les valeurs soient good. Enfin c'est comme ça que j'avais fait de mémoire.

De mémoire, j'allais plus loin même dans openmonitoring. L'algo était le suivant :
Est-ce que le process aida64 tourne ? Si non, je renvoie false immédiatement.
  Si oui, je vérifie si la mémoire partagée est ouverte.
    Si Oui je renvoie true, monitoring ouvert
    Si non, pendant quelques secondes j'essaie de l'ouvrir. Au bout d'un timeout, je renvoie false, elle est surement désactivée.

Mais alors vraiment de mémoire d'il y a 4 ans. Il y a GetProcessList dans les API Windows. Vérifiez bêtement si aida64*.exe (un truc du genre) est dans la liste. http://msdn.microsoft.com/en-us/li [...] 85%29.aspx

 
Bon bah moi OCCT appelle mon LaunchMonitoringProgram(), avec le paramètre 2 ce qui correspond à SW_SHOWMINIMIZED ^^ (pas juste 1 ou 0)
Pour le CloseMonitoringProgram(), pour moi le bench n'a pas a fermer un programme qu'il n'a pas ouvert, donc le forced est useless.
Mais bon je vais regarder coder cette logique, même si OCCT s'en sert pas.

Je le finis pour le finir ^^

 
Le problème du sleep, c'est que c'est un truc qui ralentit encore le lancement d'occt.
Pour faire les choses bien, OCCT devrait essayer d'ouvrir la mémoire partagée tout les secondes tant qu'il n'est pas en benchmark, et actualiser l'UI en conséquence une fois que ça a réussi.

+1, occt trop long à s'ouvrir
 
Ouverture plus rapide + UI Disabled quand que pas trouvé. Je plussois

Ouai bon ca va hein. 80% du temps de chargement d'OCCT (voir plus) est pris par le démarrage du plugin d'infos système/du monitoring. Regardez le temps de lancement de CPU-Z... c'est bête, mais c'est comme ça.

Je sais
 
D'ailleurs j'ai testé la dernière beta de OCCT, les bonhomes ont tappés pendant 20sec, j'ai fini par tué de le processus et relancé, et ça à prit 6/7sec.

 
Le 1er lancement concernait l'installation du pilote CPU-Z. Le second, il a réutilisé le pilote installé. C'est on ne peut plus normal.

 
Y'a pas moyen de le refactoriser pour le faire en threadé ? (Un thread par sous-système qui prends des plombes, ça permet de recouvrir les temps d'initialisation au lieu de les cumuler, ou juste des sections OpenMP dans l'init)
Bon je sais c'est du boulot ^^

 
Yep, c'est du boulot pour gagner quelques secondes au démarrage. Je t'avouerai préférer focaliser mon taff dans tout ce qui peut être détection d'instabilité et GPU:MEMTEST pour le moment

Le temps de démarrage me choque pas plus que ça.
 
Tu le code toujours en OpenCL le GPU:MEMTEST ?

 
Oui, même si ca fait une grosse semaine que j'y ai plus touché par manque de temps.
 
Faut dire, 20h de peinture sur deux jours ce week end, ca fatigue son homme

Ouai ça serait cool comme ça ils pourra faire aussi office de CPU memtest en utilisant le iGPU des CPU Intel/APU AMD....  

Si ma mémoire est bonne, quand ca tourne sur un CPU Intel avec le framework intel, sur mes 2Go de ram sur le powtable je suis limité à 512Mo. Pas en mode IGP, en mode "je tourne sur le CPU". Plutôt limité, du coup.

Non mais via le iGPU t'as pas accès a quasi toute la RAM via le PCI Express  ?
 
Bon après le pilote OpenGL GPU d'Intel est en mousse, faudrait plus tester sur un APU AMD pour le coup.

 
Le IGP intel que j'ai ne supporte pas l'OpenCL (c'est con je sais). Oui, c'est un i5.
 
J'ai pas tout le matos de la terre à dispo hein

 
Ok
Bon courage pour tes travaux  

Ne regrette rien, même les IGP Intel qui supportent OpenCL le supportent de manière tellement moisie qu'on peut considérer que ça fonctionne pas
http://www.hardware.fr/articles/86 [...] xmark.html

Tetedeiench, tu aurais pas dans OCCT même un truc qui cherche aida64.exe et qui inhibe l'appel de LaunchMonitoringProgram() des plugins quand il le trouve ?