NSpluginwrapper works with plugins conforming to the Netscape 4 Plugin Application Programming Interface (NPAPI). As its name implies, NPAPI was initially developed in the pre-Mozilla days at Netscape, but today it lives on both in Mozilla-derived browsers such as Firefox, and in a number of independent applications, such as the Opera browser and KDE's Konqueror. NPAPI specifies about 15 data structures and 20 methods that the plugin must expose to the browser, and 16 methods that the browser must expose to the plugin.
To hook a binary i386 plugin into the AMD64 build of Firefox (for example), NSpluginwrapper simply registers itself with the browser as the plugin handling the appropriate content types, and when necessary, launches the binary plugin and dispatches calls between browser and plugin via RPC.
Installation and setup
You can download NSpluginwrapper from developer Gwenole Beauchesne's personal site. As of this writing, the current release is numbered 0.9.90.1, and it is available in binary .RPM for x86_64 and as source code in RPM and tarball. The binary release consists of two separate packages, nspluginwrapper and nspluginwrapper-i386 (which contains the i386-specific executable). I had no difficulty converting them to .DEB format with alien and installing them on Ubuntu 6.06 for AMD64.
Before beginning installation, make sure that you have 32-bit i386-compatibility set up on your machine. For AMD64 users, this is probably via a system package called linux32, a package that allows you to run 32-bit executables. PowerPC users will need to make use of an emulator like QEMU. QEMU itself is the the recommended choice, since Beauchesne personally works on it. Once you have this i386 compatibility environment set up, you can proceed to install NSpluginwrapper.
The nspluginwrapper package installs a "proxy" plugin named npwrapper.so to /usr/lib/mozilla/plugins/ and a command-line configuration tool called npconfig to /usr/lib/nspluginwrapper/x86_64/. You may find it helpful to manually add a symbolic link to /usr/local/npconfig, though it is not necessary. Upon installation, the installer is supposed to search the system for 32-bit plugins and install them -- but this feature may not function correctly, particularly if you converted the package from RPM to another format.
In any event, you can install and remove plugins with the npconfig program. Running
/path/to/npconfig -v -a -i will search for plugins (the
-a flag), install any it finds (the
-i flag), and be verbose about its progress (the
-v flag). One slight wrinkle to this process is that npconfig looks for plugins in /usr/lib/mozilla/plugins -- which on some systems may be the location of 32-bit plugins, but on others is the location of 64-bit plugins. If npconfig does not find all of the plugins you need automatically, you can add them manually by running
/path/to/npconfig -i /path/to/the/original/32bit/plugin.so.
Usage and limitations
|Flash playing inside an AMD64 build of Firefox. Click to enlarge.|
The screenshot you see here shows the Adobe Flash plugin -- a 32-bit, i386-only download -- running happily inside a 64-bit AMD64 build of Firefox. Beauchesne lists Flash, Adobe Reader (formerly known as Acrobat Reader), DejaVu Libre, JPEG2000, Mplayerplug-in, and RealPlayer as working "reasonably well" at this time. I had little success with RealPlayer, but I haven't used it years anyway.
The first time I tried NSpluginwrapper, the proxy plugin would consume 100 percent of my system's CPU and crash every time. The latest release does not suffer the same malady. On occasion, the browser will still lock up when NSpluginwrapper is running a plugin, but this seems to happen only when the i386 plugin in question is itself frozen or waiting on a connection -- a situation not uncommon with YouTube and other Flash-based video-sharing sites.
I regret that I was not able to test the PowerPC performance of NSpluginwrapper, as this sounds like an interesting experiment. Given how much work Beauchesne seems to devote to PowerPC emulation, I suspect that this is a good solution to the paucity-of-plugins problem. After all, whatever percentage of plugin-makers actually produce a Linux version of their product, only a fractional percent of those supply one for anything other than i386 Linux.
Which brings me to another point: in all the talk about emulation and cross-platformness, NSpluginwrapper is limited to plugins built for Linux specifically. In other words, NSpluginwrapper will allow you to run the i386 Linux version of Adobe's Flash plugin on AMD64 Linux -- but it will not enable you to run the i386 Windows version of that plugin on your Linux box.
Similarly, it is worth noting that for all the successes this tool has to brag about, it is still very early in its development. Beauchesne is an employee at Mandriva, but has been working on NSpluginwrapper in his spare time.
The release of the source code with version 0.9.90.1 is a big milestone; prior to that Beauchesne had only released executables because -- due to work commitments -- he had to back-burner the project. That left users who stumbled onto the project in a peculiar position; nevertheless, Beauchesne was helpful in responding to questions. Now, Beauchesne reports, Mandriva's release cycle has calmed down enough to allow him more free time to work on the project.
Given the response met by this early release, it is safe to say that the project has a future.