[Lanceur] Gestion des "instances multiples"

[fat115]

Bonjour,

Suite au souci rencontré dans ce topic : viewtopic.php?f=73&t=32221
J'ai voulu jeter un oeil plus en détail sur la gestion des "instances multiples".

J'ai constaté que les lanceurs réalisées avec la v3 du Pack de portabilisation comprenait bien une fonction de vérification pour savoir si l'appli est déjà lancée (voir le code du lanceur de Sumatra par exemple) ... sauf que celle-ci ne peut pas fonctionner parce que le processus nommé myMutex doit rarement exister.
Dans le script nsi que j'ai mis à jour et qui est inclus dans la version du pack dispo ici : viewtopic.php?f=73&t=32072
J'ai remplacé certaines "vieilles" fonctions définie dans le nsi par des fonctions standards de NSIS (GetParameters, GetRoot et FindProcDLL à la place de Mutex). Ça a donc réactivé la fonction de prévention d'exécutions multiples (cf les soucis du premier lien).

J'ai également regardé le lanceur générique utilisé par pyg dans certains cas (Notepad++ par exemple) : il n'y a aucune vérification.
Par contre, il ne peut tout simplement pas être utilisé en conjonction avec CAFE puisqu'il ne gère pas non plus les paramètres passés au script.

Il ressort de toutes ces observations que l'utilisation de CAFE peut être largement perturbée en fonction du lanceur utilisé.

Le comportement le plus propre, selon moi, serait d'empêcher le lancement d'une application portable dans le cas ou la même appli est déjà exécutée en local et de reconfier à sa version portable la gestion des lancements multiples si celle-ci est lancée.
Ça n'est pas très compliqué à vérifier avec le lanceur mais ça implique de laisser tourner le processus PortableMachin pour distinguer l'appli locale de l'appli portable. Ça induit donc une charge mémoire plus importante.
Le comportement serait alors le suivant lors du lancement de PortableMachin :
- appli locale déjà lancée : avertissement lors de la tentative d'utilisation de PortableMachin et sortie
- pas de version locale ou portable lancée : on lance Machin avec ses éventuels paramètres et on laisse tourner PortableMachin (ExecWait)
- appli portable déjà lancée : on passe les paramètres à Machin et on sort direct de PortableMachin (Exec, pour ne pas avoir plusieurs instances de ce dernier)

Un cas qu'il n'est pas possible de gérer : PortableMachin tourne et l'utilisateur lance la version locale de Machin.

Selon vous, quel est la meilleure façon de faire ? Est-il utile de s'en préoccuper ? J'avoue qu'étant entouré de gens qui clique dans tous les sens sans avoir la moindre idée de ce qu'il font , je suis devenu très prudent.
Et autant avec certaines applis les risques en cas de lancement conjoint des versions portables et locales est minime, autant j'ai des doutes sur certaines.

Et la solution de l'ini proposée dans le premier lien me parait n'être qu'une rustine.

Voilà, la discussion est ouverte.

[takshil]

C'est bien de lancer le débat sur le lanceur.

Pour ma part, je pense qu'il serait bon de repenser totalement le lanceur des applications portables.

Aujourd'hui, aucune norme n'existe vraiment pour ces lanceurs, et malheureusement tout le monde le fait un peu à sa sauce suivant l'application sur laquelle il travaille.

Moi ce que j'aimerai bien ça serait que le lanceur soit revu avec la sortie de la V2 mais est-ce que ce serait possible ?

Je ne suis pas plus attacher que ça au script NSI pour le lanceur, faut dire que je ne connais pas encore assez le langage.

Sinon, je ne suis pas d'accord sur un point dans ta description sur le comportement du lanceur : je pense qu'on doit pouvoir une appliportable en même temps que l'appli locale. Enfin, ce n'est que mon avis.

Edit: il serait bon que les lanceurs intègrent la possibilité de placer le répertoire profile où on le souhaite pour par exemple pouvoir mettre les profile dans le répertoire data d'une framakey complète plutot que dans le répertoire de l'application.

[Téthis]

MyMutex n'est pas un processus, c'est un mutex, autrement dit une sorte de sémaphore allumé pour indiquer qu'une instance d'un programme est déjà en mémoire. C'est *ce* qu'il faut faire pour gérer les instances multiples.

Détecter les modules chargés peut être une solution mais ça peut empêcher deux instances différentes de programmes, genre une portable et une pas portable. Et c'est assez limité.

Il y a un problème avec le lanceur de Sumatra : le nom du mutex est horriblement peu original, il suffit d'un autre lanceur qui utilise le même nom de mutex pour que les lanceurs se perturbent mutuellement.

Edit: Je viens de regarder au niveau des processus en cours une fois PortableSumatraPDF.exe executé. Ce dernier disparaît, le mutex ne sert donc à rien puisqu'il est détruit à l'arrêt de PortableSumatraPDF.exe.

Edit2: Même en utilisant ExecWait au lieu de la commande Exec dans le fichier .nsis afin que PortableSumatraPDF.exe ne se termine pas avant sumatrapdf.exe, il n'y a pas affichage de la boite de message prévenant qu'une autre instance du programme est en cours. La gestion du mutex est donc foireuse dans le lanceur.

Edit3:
Gotcha! il faut mettre, en plus du ExecWait,

Code: Tout sélectionner

Function .onInit
  Call Mutex
FunctionEnd

au lieu de

Code: Tout sélectionner

Section .onInit
  Call Mutex
SectionEnd

Puis tant qu'à faire, autant mettre le corps de la fonction Mutex dans celui de .onInit.

[Agent Ty]

C'est bien de lancer le débat sur le lanceur.

Pour ma part, je pense qu'il serait bon de repenser totalement le lanceur des applications portables.

Aujourd'hui, aucune norme n'existe vraiment pour ces lanceurs, et malheureusement tout le monde le fait un peu à sa sauce suivant l'application sur laquelle il travaille.

Moi ce que j'aimerai bien ça serait que le lanceur soit revu avec la sortie de la V2 mais est-ce que ce serait possible ?

Je suis d'accord avec ça. (D'ailleurs en cas de rapprochement avec PortableApps.com, je crois qu'il ont un modèle standard de lanceur, auquel il faudra se conformer.)
Mais ça voudra dire aussi faire un tutoriel précis en expliquant les caractéristiques requises.

Sinon pour la gestion des instances multiples, je crois que la question doit être étudiée au cas par cas : dans le cas de certains logiciels ça ne posera aucun problème, pour d'autres on aura affaire à des comportements aberrants...
Une solution pour éviter les problèmes c'est effectivement d'interdire les instances multiples, mais est-ce qu'on ne peut pas faire mieux ?

[fat115]

MyMutex n'est pas un processus, c'est un mutex, autrement dit une sorte de sémaphore allumé pour indiquer qu'une instance d'un programme est déjà en mémoire. C'est *ce* qu'il faut faire pour gérer les instances multiples.

Détecter les modules chargés peut être une solution mais ça peut empêcher deux instances différentes de programmes, genre une portable et une pas portable. Et c'est assez limité.

Il y a un problème avec le lanceur de Sumatra : le nom du mutex est horriblement peu original, il suffit d'un autre lanceur qui utilise le même nom de mutex pour que les lanceurs se perturbent mutuellement.

Merci pour la précision sur la différence entre le mutex et le processus, j'avais effectivement fait la confusion.
Par contre, tes edits confirment ce que je disais : tel quel c'est inefficace.
Et en ce qui concerne l'originalité du nom du mutex : tous les lanceurs fait de manière semi-automatique avec le pack de portabilisation v3 utilise le même nom myMutex. Autrement dit, heureusement que ça ne fonctionne pas.

Pour ma part, je pense qu'il serait bon de repenser totalement le lanceur des applications portables.
Aujourd'hui, aucune norme n'existe vraiment pour ces lanceurs, et malheureusement tout le monde le fait un peu à sa sauce suivant l'application sur laquelle il travaille.
Moi ce que j'aimerai bien ça serait que le lanceur soit revu avec la sortie de la V2 mais est-ce que ce serait possible ?

J'ai pu constater quand même que c'est souvent celui du pack qui est utilisé. Mais il ne peut être utilisé sans modification que dans le cas ou l'appli est nativement portable. Après il faut traiter au cas par cas.
À propos des instacnes multiples: essaie de lancer simultanément GimpPortable et Gimp local : tu risques d'avoir des surprises puisque la version portable (venant de PA.com) fonctionne en faisant un backup des réglages de la version locale si elle existe.

Je suis d'accord avec ça. (D'ailleurs en cas de rapprochement avec PortableApps.com, je crois qu'il ont un modèle standard de lanceur, auquel il faudra se conformer.)
Mais ça voudra dire aussi faire un tutoriel précis en expliquant les caractéristiques requises.

Ils ont surtout un modèle qui évolue en permanence et qui est ensuite adapté à chaque logiciel. Difficile de trouver dans leurs applis deux versions identiques (même numéro) de leurs lanceurs. Et ils n'hésitent pas à faire des modifications lourdes sur le système hôte pour portabiliser leurs applications : backup de la base de registre, backup des dossiers d'AppData.

Sinon pour la gestion des instances multiples, je crois que la question doit être étudiée au cas par cas : dans le cas de certains logiciels ça ne posera aucun problème, pour d'autres on aura affaire à des comportements aberrants...
Une solution pour éviter les problèmes c'est effectivement d'interdire les instances multiples, mais est-ce qu'on ne peut pas faire mieux ?

Mon idée n'est pas d'interdire les instances multiples mais de confier leur gestion à l'appli en elle-même par défaut. Et seulement pour celles susceptibles d'avoir un comportement aberrant, de le gérer via le lanceur.
Exemple :
Notepad++ est limité par défaut à une instance unique, c-a-d que tous les lancements (par association via CAFE) vont utiliser l'instance ouverte si elle existe. Il ne faut donc pas que le lanceur bloque ce comportement.
Idem pour SumatraPDF => ouverture d'une nouvelle fenêtre sans souci.
Mais pour Firefox ou Thunderbird, ça n'est pas aussi simple (problème des profils).

[Téthis]

Merci pour la précision sur la différence entre le mutex et le processus, j'avais effectivement fait la confusion.
Par contre, tes edits confirment ce que je disais : tel quel c'est inefficace.

Dans l'état, c'est inefficace. C'est du code mort.

Et en ce qui concerne l'originalité du nom du mutex : tous les lanceurs fait de manière semi-automatique avec le pack de portabilisation v3 utilise le même nom myMutex. Autrement dit, heureusement que ça ne fonctionne pas.

J'ai écrit un lanceur (pour sumatraPDF parce que c'était celui que j'avais sous les yeux) qui utilise optionnellement un mutex, mutex dont le nom est généré en fonction du nom de l'application :
viewtopic.php?f=73&t=32244

Et là ça fonctionne.

[fat115]

J'ai bien vu ton nouveau lanceur et je me rends compte que je me suis mal exprimé : je ne cherchais pas vraiment à faire fonctionner le mutex puisque le comportement actuel de PortableSumatraPDf est celui qui me semble convenir. À savoir que le lanceur ouvre un nouveau document dans une nouvelle fenêtre de SumatraPDF lors d'un double clic en association avec CAFE

En pratique : y'a t-il différence entre utiliser le mutex et faire un test dessus et faire directement un test sur le processus PortableMachin ?
Ça revient au même si je ne m'abuse ?



PS : le code de ton lanceur est certes 3 fois plus court mais au final sur l'exécutable, ça ne fait que 239 octets d'écart
Et l'idée, si j'ai bien compris, c'est d'essayer dans la mesure du possible d'avoir un lanceur un peu passe-partout (sauf applis spécifiques comme FF, OOo, TB et quelques autres)

[Téthis]

> je ne cherchais pas vraiment à faire fonctionner le mutex puisque le comportement actuel de PortableSumatraPDf est celui qui me semble convenir.

Peu importe mon but n'était pas de fournir un lanceur pour SumatraPDF mais d'écrire un code de lanceur plus compact et plus lisible pouvant permettre l'utilisation d'un mutex. Mon code n'est pas parfait, c'est mon premier programme en NSIS et j'ai fini les !define un peu à l'arrache.

Je ne connais pas la framakey mais je suis certain que l'on peu faire un code générique pour pas mal de lanceurs. J'ai vu que tu utilises les includes (.nsh) dans le pack de portabilisation. Il est par exemple possible d'intégrer optionnellement le support des mutex (je reste à ça :p) à coup de !ifdef MUTEX ... !endif avec MUTEX définie ou non dans le fichier .nsh généré, je suppose, par FramakGenXML_NG (qui ne mérite plus son nom). Je reste sur les mutexes mais cela peut aussi fonctionner sur, par exemple, la modification de variables d'environnement.

> y'a t-il différence entre utiliser le mutex et faire un test dessus et faire directement un test sur le processus PortableMachin ? Ça revient au même si je ne m'abuse ?

Dans la plupart des cas le résultat sera le même. Cependant ça reste une solution assez primitive qui va finir par détecter des modules ayant le même nom ou échouer à détecter des modules dont le nom a été changé.

> PS : le code de ton lanceur est certes 3 fois plus court mais au final sur l'exécutable, ça ne fait que 239 octets d'écart

34 Ko de code pour NSIS et 30 Ko pour un jpeg, oui ça donne un code prenant peu de place. Difficile de réduire de beaucoup la taille de l'exécutable. Je peux le faire en assembleur et pure API Win32 pour gagner en poid mais le code risque de poser problème à l'équipe de la framakey pour une prochaine adaptation. Puis reste le problème du poid incompressible de l'image.

> Et l'idée, si j'ai bien compris, c'est d'essayer dans la mesure du possible d'avoir un lanceur un peu passe-partout

Ouaip.

[pyg]

Voilà un fil bien interessant
<ma vie>malheureusement, je suis en transit pour les RMLL, donc j'ai un peu du mal à suivre, et ça va durer au moins jusqu'au 15/07 :-( </ma vie>

en résumé :
- excellente initiative que de réécrire les lanceurs (sont la base date en effet de 2005/2006)
- c'est effectivement une bonne chose que de traiter les instances multiples. Par contre, pour moi il ne s'agit pas de les interdire, mais d'avoir un pseudo-contrôle dessus (par exemple à l'aide de la variable "AllowMultipleInstances=true" dans le fichier .ini (et du coup la possibilité de fixer la valeur de cette variable facilement dans le .nsi). En effet, il est difficile (impossible ?) de rendre les lanceurs complètement génériques du fait de la grande diversité des applications.
- pour ce qui est des lanceurs portableApps : j'ai vraiment été tres prêt de faire le switch l'an passé et de basculer vers leurs lanceurs et leurs outils. Mais en suivant attentivement les discussions, j'ai quand même eu des doutes sur l'évolution de la licence. Aujourd'hui, le "PortableApps Installer" http://portableapps.com/apps/developmen ... _installer a une licence transitoire un peu floue (utilisation libre pour des LL, mais utilisation commerciale soumise à autorisation) et je crains que ça n'aille pas en s'améliorant... Du coup, je préfère rester sur des solutions libres classiques et non ambigüe (mono-licence, GPL).

Bref, je n'ai pas grand chose à dire, si ce n'est que c'est une bonne chose de voir les lanceurs dépoussiérés.
Personnellement, je ne pourrais pas remettre les yeux dans le code avant un petit moment, mais on peut effectivement partir du principe qu'on pourrait mettre à jour l'ensemble des applications avec un nouveau lanceur sur le second semestre.