nspluginwrapper 1.2.0

Posté par  . Modéré par Pascal Terjan.
Étiquettes :
23
26
déc.
2008
Technologie
nspluginwrapper est maintenant disponible en version 1.2.0. nspluginwrapper est une solution qui permet d'exécuter des greffons NPAPI en dehors d'un navigateur Internet, tout en maintenant un lien avec celui-ci. Ainsi, il permet par exemple d'exécuter les greffons propriétaires Flash Player, initialement prévus pour i386, dans un navigateur web compilé pour x86_64. Nous allons voir d'autres usages par la suite. Voici un condensé des modifications apportées pendant la phase de développement (versions 1.1.x).

Gestion des greffons en mode windowless. Vous avez sans doute remarqué que les greffons s'exécutaient dans une fenêtre séparée, mais intégrée dans la hiérarchie de fenêtres du navigateur. De ce fait, les menus déroulants pouvaient parfois s'afficher en dessous de la fenêtre du greffon. Eh bien, Firefox 3 autorise à présent les greffons qui le supportent à dessiner dans une pixmap. On appelle cela le mode windowless. En pratique, il s'agit typiquement de Flash 10 et Gnash un peu aussi maintenant. nspluginwrapper s'aligne sur le support du navigateur.

Greffons natifs. Vous avez sans doute entendu parler de Google Chrome et de son architecture multi-processus et de confinement. L'idée n'est pas neuve, et Red Hat l'implémentait déjà depuis quelques temps avec l'aide de nspluginwrapper. Vu que nspluginwrapper est un processus indépendant, l'intérêt est triple :
  • Si le greffon se vautre (crash), il n'emporte pas tout le navigateur avec lui. Ainsi, le navigateur survit et il suffit de recharger la page incriminée. Pour l'instant, le greffon n'est pas rejoué, i.e. il ne redémarre pas tout seul, il faut que ce soit une action motivée par l'utilisateur.
  • Si le greffon est un goinfre de mémoire mais qu'il la digère mal, alors les fuites de mémoire sont limitées à ce processus, et non au niveau du navigateur qui vit plus longtemps. Rappel : s'il n'existe plus aucune instance d'un greffon donné, alors il est dé-initialisé. Cela correspond à l'arrêt normal du processus nspluginwrapper, et ainsi de toute la mémoire non-partagée qui y était créée.
  • Mesures de sécurité. Il est possible d'autoriser le greffon à n'accéder qu'à certaines ressources. e.g. connexion aux ports HTTP uniquement, interdiction de lire certains fichiers dits sensibles comme /etc/shadow, etc. Tout ceci se contrôle avec des règles SELinux, ou RSBAC. nspluginwrapper ne fournit aucune politique de sécurité, cela échoit au distributeur.

Lecteur auto-suffisant de greffons. En fait, il s'agit d'une petite application (nspluginplayer) qui permet d'exécuter des greffons sans navigateur web. C'est assez utile si l'on veut par exemple exécuter une pauvre animation Flash sur un stand,... ou de déboguer un greffon. Bon, ça ne supporte pas l'intégralité de NPAPI mais c'est tout à fait suffisant pour exécuter Flash Player et le greffon d'Adobe Reader. La syntaxe de nspluginplayer peut sembler compliquée, mais il suffit en fait de lui fournir les arguments de la balise embed.

Par exemple, pour jouer à Magic Paint, on lancera la commande: $ nspluginplayer src=<a href="http://magic.pen.fizzlebot.com/magic-pen.swf">http://magic.pen.fizzlebot.com/magic-pen.swf</a> width=800 height=520

Prise en charge de nouvelles architectures et systèmes. nspluginwrapper tourne maintenant sous OpenSolaris 2008.xx. Transitive Technologies l'utilise notamment pour exécuter le greffon Adobe Reader, qui n'existe que pour Solaris/SPARC. Encore plus intéressant, ils utilisent nspluginwrapper pour exécuter le greffon Flash 9 Linux/i386 sur Linux/ARM.

Aller plus loin

  • # Merci

    Posté par  (site web personnel) . Évalué à 4.

    Je voulais juste te dire merci et bravo pour ton logiciel, qui m'a rendu de fiers services du temps de Flash 9 et 10 32 bits.

    • [^] # Re: Merci

      Posté par  . Évalué à 3.

      effectivement, je vois aussi que tu as contribué à des projets particulièrement audacieux (emulateur powerpc etc), félicitations et merci Gwenolé !

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # mem leak

    Posté par  . Évalué à 2.

    Mais gros problème de fuite mémoire avec Acrobat reader sur amd64 depuis la version 0.9 :(

    • [^] # Re: mem leak

      Posté par  . Évalué à 9.

      Euh, oui, il y avait des fuites de mémoire dans le bridge NPRuntime jusqu'à la version 1.1.6. Je ne sais pas si c'est ton problème en particulier, mais c'est ce que j'avais remarqué lors de ma phase de review du code.

      Si tu suspectes encore des fuites de mémoire dans la version 1.2.0, il est également possible de ne lancer valgrind que sur nspluginwrapper, et donc les plug-ins, i.e. on ne s'embête pas à valgrind'er sur tout le browser. Pour ce faire, démarre juste le browser en le préfixant de la variable NPW_USE_VALGRIND=yes.

      Par exemple:$ NPW_USE_VALGRIND=yes NPW_VALGRIND_OPTIONS="--leak-check=full" firefox file:///path/to/file.pdf 2>&1|tee l
      Ca fait un peu fonctionnalité secrète mais a priori ce n'était utile que pour moi. ;-) Ah oui, si tu vois une tripotée de variables utilisées avant d'être initialisées, t'en fais pas, c'est "normal" pour les plug-ins d'Adobe, ou bien est-ce valgrind qui ne détecte pas bien ces cas?

  • # et java

    Posté par  . Évalué à 2.

    Est ce que ça marche avec java ? Il n'est pas listé sur la page du projet

    • [^] # Re: et java

      Posté par  . Évalué à 3.

      Non, les plug-ins Java ne sont pas supportés. Ceux utilisant l'API OJI ne le seront jamais, a priori. En théorie, il devrait être possible de supporter le nouveau plug-in Java de Sun, qui utilise NPAPI et NPRuntime. En pratique, c'est un peu plus complexe car il semble exister encore des bouts de XPCOM dedans, ce qui n'est pas supporté. Quant au plug-in Java d'IcedTea, je n'ai pas encore regardé mais (i) il exécute déjà l'appletviewer dans un autre processus me semble-t-il, et (ii) il est disponible nativement.

  • # Des plugins i386 sur un i386

    Posté par  . Évalué à 1.

    Est il possible d 'utiliser nspluginwrapper sur du i386, pour éxécuter des plugins i386?

    Vu les avantages de la description, notament pour la gestion des crashs et de la consommation.

    Merci.

  • # nspluginwrapper 1.2.2

    Posté par  . Évalué à 3.

    Une nouvelle version de maintenance vient d'être publiée:
    * Correction du support du plug-in VLC (0.8.6)
    * Correction d'un problème de déallocation mémoire dans NPN_GetStringIdentifiers() pouvant causer un crash du navigateur
    * Correction d'un cas d'erreur lors de la création de flux dans le lecteur autonome

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.