Je sais, je n’ai pas donné de nouvelles depuis … trop longtemps !

En fait, Bill2’s Process Manager n’a pas énormément évolué ces deux derniers mois : pas de grosse version en vue.
Mais comme j’ai reçu différents rapports de crash, il va tout de même y avoir une mise à jour mineure d’ici quelques jours.

Bien entendu, j’ai dans l’idée de commencer à travailler sur une version 3.5 mais … avant ça, j’aimerai d’abord changer (enfin !) mon vieux PC.
Comme je l’ai déjà dit, BPM est développé sur un Athlon XP2400+, sous XP SP3.
Oui, c’est un peu la lose de bosser sur un programme spécifique au multicoeur, alors que mon PC est monocoeur !
Bon, je peux tout de même le tester sur le C2D sous Vista de ma femme, mais bon … ce n’est pas très pratique de changer de PC à chaque recompilation pour tester le résultat sur l’ordi d’à côté !

Je ne sais vraiment pas quand j’aurai ce nouveau PC. Ca dépendra des finances, et aussi des dons que je recois. D’ailleurs, je remercie chaleureusement les donateurs au passage.

En conclusion, ne vous attendez pas à voir évoluer BPM en 2010 de façon aussi importante que les autres années.
Mais le développement continue, et je reste toujours à disposition sur le forum pour vous dépanner !

L’aspect le plus travaillé sur cette version a été la gestion de la mémoire, et la correction de fuites mémoire.
Avant de publier la mise à jour, j’ai surtout cherché à ce que l’application des règles se fasse toujours correctement.

Seulement voilà, entre la version « debug », la version « release », la version que j’utilise « en réel » sur mon poste, et le fait que j’ai aussi des copies qui tournent en mode « portable », je n’ai pas poussé les tests assez loin.
Là dessus est venu se greffer le bug dû au fichier Updater.xml … là aussi j’en ai des copies un peu partout. Ce qui fait que mes tests n’ont provoqué aucun crash … et pour cause, je n’ai pas tenté de clean install, avec suppression de toute information dans le répertoire utilisateur.

Bref. sur ce coup là, j’ai vraiment merdé ! Et je sais que la v3.4.1.1 comporte d’autres bugs du même genre … il suffit de vouloir créer une règle sans passer par un clic droit dans la fenêtre des processus : on a une fenêtre qui s’ouvre pour explorer l’ordi, et si on clique sur « Annuler », on un crash direct !

Je vais donc bosser plus sérieusement sur la v3.4.1.2. Pour cette version, mon objectif sera un test complet de tout le programme : fenêtre par fenêtre, toutes les fonctions seront passées au crible, avec validation et annulation, pour vérifier le comportement global.
Après la phase d’optimisation (v3.4.1), voici la phase des tests poussés.
Ces tests avaient été réalisés pour la v3.4, et j’aurai du les refaire pour la v3.4.1, vu les changements interne apportés.

Je bosse dessus, et je vous remercie pour la confiance pour que vous continuez à m’apporter.
Encore toutes mes excuses pour cette sortie un peu trop précipitée.

UAC et installeur
Sous Vista (et Windows 7), si on veut installer un programme dans Program Files, il faut le faire en tant qu’administrateur. C’est pourquoi mon installeur déclanche l’UAC.
Ainsi, le programme peut s’installer là où l’utilisateur le souhaite. Là où ça se complique, c’est qu’une fois installé, si l’utilisateur choisi de lancer directement le programme, il le démarre avec les même droits que l’installeur : en mode admin. Et donc la configuration est sauvegardée dans le répertoire Admin, et pas dans celui de l’utilisateur courant.
C’est pour ça que depuis la v1.2.1 de l’installeur, Bill2’s Process Manager n’est plus lancé automatiquement : ça force l’utilisateur à passer par son menu démarrer, et à lancer le programme avec ses droits utilisateur.
Mais il y a aussi un effet de bord que je n’avais pas prévu …

Mise à jour du fichier des « Exceptions »
Bill2’s Process Manager utilise différentes listes d’exceptions, pour la fonction de Priorité Automatique, pour l’assistant de création de règle, et depuis la v3.4, pour la fonction de « Règle par défaut ».
J’avais donc mis au point un système pour mettre à jour ces listes lors de l’installation d’un nouvelle version. Un fichier Updater.xml était copié sur l’ordi, et au chargement de Bill2’s Process Manager, les nouvelles infos étaient fusionnées avec les paramètres de l’utilisateur.

Sauf que … vu que l’installeur tournait en mode Admin, le fichier Updater.xml était copié dans le répertoire de l’admin, et non dans celui de l’utilisateur courant.
Résultat, vu qu’ensuite l’utilisateur lançait le programme « en son nom », la mise à jour n’était jamais intégrée, vu que le fichier Updater.xml n’était pas dans le répertoire de l’utilisateur.
Vous allez me dire : pourquoi copier se fichier dans le répertoire utilisateur, et pas dans le répertoire d’installation ? Et bien tout simplement parce que ce fichier est supprimé après intégration, et que par défaut, l’utilisateur courant n’a pas le droit de supprimer un fichier dans Program Files …

La solution que je vais mettre en oeuvre
L’installeur v1.3, sur lequel je suis en train de travailler, déposera le fichier Updater.xml dans le même répertoire que l’exécutable, vu qu’il n’a pas accès au répertoire de l’utilisateur courant.
Ensuite, lors de l’initialisation, Bill2’s Process Manager vérifiera un paramètre dans le fichier de config, et intègrera les nouvelles données si besoin est.
Ce nouveau paramètre, intégré avec la v3.4.1, sera tout simplement basé sur la version du programme.

Si j’ajoute cette vérification, c’est tout simplement pour que chaque utilisateur de l’ordinateur puisse avoir accès à la mise à jour.
En effet, les versions 3.3 et 3.4 supprimaient le fichier Updater.xml après intégration.
Si on supprime le fichier qui se trouve dans le répertoire de l’exécutable, alors seul le premier utilisateur qui lancera le programme bénificiera de la mise à jour …
Donc la v3.4.1 ne supprimera plus le fichier, mais conservera en mémoire le numéro de la dernière version ayant fait un update.

Et bien, Bill2’s Process Manager en avait bien besoin !
J’ai pu découvrir pas mal de fuites mémoires, et ainsicorriger un grand nombre d’erreurs.

J’ai sans doute encore un peu de travail, mais je pense que le plus gros est fait.
Le résultat ? Une diminution de 3 à 5 Mo de l’utilisation mémoire du programme. C’est peu, mais c’est toujours ça de gagné !

La prochaine version est donc en cours de préparation, avec quelques corrections de bugs, et diverses autres petites choses …

Je ne vais pas m’étendre sur les nouveautés, elles sont toutes listées sur le site web.

Pour ceux que ça intéresse, je compte rajouter pas mal de tutos sur ce blog dans les prochaines semaines. Ca sera en grande partie des explications sur les nouveautés, et une reprise du fichier d’aide, vu que les gens lisent les blogs, mais pas l’aide intégrée … :p

Amusez-vous bien avec cette nouvelle version, et n’hésitez pas à passer sur le forum pour signaler tout problème, ou laisser des encouragements.

Et si le coeur vous en dit, un petit don via Paypal, ça fait toujours plaisir.

PS : Cet article n’apparait que maintenant, car j’ai eu un gros crash sur la Base de Données du blog …

Bill2’s Process Manager v3.4 devrait donc sortir vendredi 6 Novembre 2009, ou au pire, dans le Week-end.

Alors, pressés d’essayer cette nouvelle mouture ?

Au passage, j’ai mis à jour le fichier d’aide (qu’il me faudra encore relire), et j’ai commencé à bosser sur le site web, en vue de la publication de la v3.4, qui devrait donc arriver fin Octobre / début Novembre 2009, si tout va bien.

Je suis satisfait du résultat, même si sur l’ordi de ma femme, le programme plante parfois sans raison : juste Windows Vista qui indique que BPM a « cessé de fonctionner »   Super pratique à corriger comme bug !

Quoi qu’il en soit, cette version va en ravir plus d’un, du moins, je l’espère.

Depuis fin Septembre, j’ai fini de bosser sur la Beta 7, qui comporte toutes les nouvelles fonctions, et dont le développement devait servir à régler les derniers problèmes.
Du coup, les fichiers sont partis vers certains traducteurs, et de mon côté, en cherchant à optimiser le programme, j’ai encore trouvé quelques bugs (dont certains très gros !)

Je suis en bonne voie vers la version « RC1″, qui incorpore déjà une nouvelle traduction en  … japonais
Mais il faut vraiment que je me motive pour le fichier d’aide par contre …

La Beta 6 a été testé avec succès pour tout ce qui concerne les fonctions touchant aux processeurs HT, et une préversion de la Beta 7 est en cours de test.
Cette dernière doit normalement corriger les rares cas de crashs que certains utilisateurs ont eu lors de la sauvegardes des options et/ou des règles, ou encore lors de la création du fichier « running.txt », utilisé pour gérer le multi-utilisateur et les instances uniques.

La relecture de la partie française est en cours, mais je cherche toujours un testeur « fort en anglais », qui pourrait corriger la traduction, avant que j’envoi le tout vers d’autres « pays » … Avis aux amateurs.

Bon, il me reste à bosser en parallèle sur le fichier d’aide et la mise à jour du site Web.
Je reste confiant pour une sortie durant le courant d’octobre 2009.

En gros, le but du jeu, c’est d’être averti par une info bulle lorsque le taux d’utilisation d’un CPU dépasse un certain seuil.
Est-ce que ça va vous servir ? Ou est-ce qu’il faudrait plus de possibilités ?

Si personne ne souhaite voir ce genre de fonction, alors ça va me permettre de « gagner du temps ».
En effet, j’attends d’avoir terminé l’intégration de toutes les fonctionnalités et nouveautés, pour envoyer les fichiers à traduire.
Vu qu’il y a pas mal de boulot, je n’ai pas envie d’envoyer des « mises à jour » aux traducteurs, ils auront déjà bien assez de travail à fournir.

Alors, quel est votre avis : est-ce que des fonctions de surveillance des taux CPU doivent être intégrées rapidement ?