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 …