Bonjour à tous,

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 !

Comme promis, voici quelques explications sur les différents bugs qui ont entaché la sortie de la v3.4.1.

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.

Depuis que j’ai un Windows Vista à la maison, j’ai pu tester l’installeur de Bill2’s Process Manager, l’améliorer, et aussi découvrir des effets inattendus pour les utilisateurs non connectés en administrateur.

Windows, les répertoires spéciaux, et l’UAC
Avec les nouvelles versions de Windows, Microsoft a renforcé la sécurité des répertoires spéciaux comme Program Files, et introduit l’UAC.
Bill2’s Process Manager gère correctement tout ça depuis la version 3.3 : le fichier de config est enregistré dans le répertoire utilisateur dédié à ce genre de fichiers.
Résultat : chaque utilisateur du PC peut avoir sa propre configuration, et n’écrit plus dans le répertoire Program Files.

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.

Au détour d’un article sur les technologies .Net, j’ai découverts les outils de type « memory profiler », que je me suis donc empresser de tester.

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 …

Vous étiez nombreux à l’attendre, et la voici enfin.

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 …