Hi, here a few updates concerning nspluginwrapper.

Project commodities. Many people asked for usual project commodities like mailing-lists and a bug reporting system. I don't want to host that myself because that would require users to create yet another account elsewhere. SourceForge or Savannah-based systems don't suit me because (i) I don't like the interface and (ii) I want to keep the SVN tree hosted on my server at this time (which Savannah wouldn't allow, AFAIK). So, where can I host the project?

• The ideal solution would be Mozilla.org since it is OS and distribution neutral and provides a Bugzilla. I don't know yet if this interests them. Hey, are there Mozilla people reading?

• The practical solution would be to accept the kind offer from Red Hat / Fedora: Fedora Hosted Projects Trac. It could be available immediately. However, I don't know if other people (distributors, *BSD people) would get frustrated by that or not (politics is always troublesome).

Standalone Player. Lately, I was working on a standalone NPAPI plugins player. The initial goal for that was to allow Flash games to be played without a complete web browser as the front-end. The syntax is actually what is used in <embed> tags. e.g. npplayer src=~/flash/bloxorz.swf width=640 height=480. The term “player” can sound crappy, this is because “viewer” is already used by the “client”, aka the program that actually executes the plugin.

OpenGL Rendering. What can you do when you have a standalone player? Well, apart from investigating some bugs, it can be used to experiment with… OpenGL rendering. I am not using texture-from-pixmap because of some other problems independent from me, so I am using an ugly hack that only works with Flash Player 9 at this time. The other benefit is that cursor changes are monitored and handled gracefully. The OpenGL back-end is using Clutter.

Now, you probably wonder: “what the hell is that useful for?”. Simple answer: initially allow Flash content to be played and interacted with in a Clutter+WebKit-based browser.

Here is the obligatory screenshot for the Clutter-based standalone NPAPI plugins player.

Movies are also available to show off: Magic Pen (reflection), Bloxorz (scaled), WebKit/Clutter (“complex” application like the Google Video player in Flash).

Roadmap. Due to recent developments, some major changes area also necessary. Here is a rough roadmap of the events. Note that I don't mention the dates because I don't know them yet… At least, I am now clear on the versioning that I promise to improve!

• Version 1.0: based on current 0.9.9x branch + some other bug fixes only
• Version 1.2: based on current trunk + Red Hat changes + standalone plugin player based on Gtk.
• Version 2.0: OpenGL rendering support + full SDK to allow third party programs (Gtk or Clutter-based) to embed NPAPI plugins. This will require some changes not suitable for 1.x series.

I am facing a cruel dilemma: on one hand, I want to continue the development of software I contributed to for years or software I created ; on the other hand, I have to realise I just can't pursue in all directions.

Free software is great to the end-user but it generates several costs to a developer, when he is not backed up by companies or sponsors. Yes, everything is done during his free time. In my opinion, this model works best when you are a student (lots of holidays!) or working for a company that develops free or open source software. Otherwise, you are rapidly caught by other costs if you try to get a “normal” life: (i) human costs, e.g. you sleep less because you are absorbed by your project(s), (ii) social costs because you are not devoting much time to other activities like hiking, partying/clubbing, getting in touch with years old friends, dating girls, etc.

About the financial costs. I generally buy what I need for development/testing purposes, without looking at the expenses. e.g. I bought MacOS X Leopard earlier this year whereas I really have no need to use it personally but for development (the system is still sub-optimal, I will get back to it in a future post). I am not developing shareware, so the money comes from my pockets. I recently sorted my papers and wanted to gather some stats about my computer hardware or software related expenses. I wish I hadn't as more than 70% of them were directly used for OSS development. I won't tell you the exact amount here but it looks quite indecent, even for a 7 years timeframe. Fortunately, some chipmakers were helpful, otherwise this would have increased the costs (though, by a very small margin)!

It's true that enthusiasts generally do not count the expenses of their hobbies, neither the time devoted to them. However, the latter can exactly be a problem for reasons I mentioned earlier. As a side note, I have been very busy the past months with other (personal) “projects”. Yes, you can think this is a very selfish decision to not finish some things I started earlier, but I wanted/needed to do other activities, e.g. lately, that was another sort of optimisation problems + sometimes nothing at all simply to relax my brain and sleep more the weekend! For the record, I generally sleep only 5 to 6 hours per night, which seems to be the optimal duration for me nowadays (vs. 8 to 9 hours 11 years ago), so only 3 long to 4 short sleep cycles. Even worse, the most optimal time to start to sleep is between 00:25 and 00:55, and I mean it. Last night, I tried 23:27 because I felt very sleepy. What a bad idea, I got up around 4:12!

Overall, in order to achieve my new personal goals, I came to the conclusion that I still need to reduce my OSS developments for at least the next 4 to 6 months. IOW, reduce to one project, at most. I know I failed to reply to your mails efficiently. However, I will try again but bear in mind I probably won't look at solutions right away. It's better I don't make you promises I might not honour…

Is there another solution? Yes, win the lottery and get rid of a full-time job so that one can devote any time he wants onto a particular project. However, let's get back to the real world, this is just highly unlikely to happen. So, costs reduction choices have to be made. This is a very difficult problem because I equally like every project I contribute to and they can require the same amount of time to work on. Further thoughts lead to the conclusion that I will be suspending any development on Basilisk II or SheepShaver. Why? Well, it was brought to my attention that Red Hat / Fedora uses nspluginwrapper by default. So, there is now probably more than a million nspluginwrapper users, either they know they use it or not (assuming desktop users would browse the Internet with contents requiring a plug-in). Henceforth, more people should benefit from nspluginwrapper development than from Mac emulators. Besides, I also need it for one professionnal project.

In summary:

• Basilisk II / SheepShaver: suspended. Note this doesn't mean indefinitely stopped, I still have many ideas planned and even started to implement some of them! It means I may get bored by other activities and come back to do what I used to be good at instead.
• NSPluginWrapper: active development. I will also post recent happenings around this project. You may be surprised to see what it could be used for nowadays. There will also likely be a new location to host the project with lists and bug reporting tools. SVN is already available here.

BTW, I came across Ohloh and I compiled the projects I work on to here. Ohloh has interesting metrics but I have several problems with it:

• The cost of a project is probably over-valued, at least in terms of human efforts (men-year).
• The name is somewhat crappy. Really, what the hell does “Ohloh” mean? Then, my brain tried some word associations and came by very bad ones. I hope the authors didn't meant that…

Hi, the website will be under maintenance from time to time, so don't be surprised if it is temporarily unavailable. Actually, there are some performance problems I would like to investigate: pages are served slowly, aren't they? e.g. this blog is served in about 2 seconds to wget but noticeably more when served to graphical browsers like Firefox or Safari. There are only 1200 unique visitors per day on this site, overall. So, for something like one visitor per minute, it's highly unlikely that the server, based on a VIA C7 @ 2 GHz, couldn't cope with that tiny load.

Further experiments show that a static version of the nspluginwrapper page can be served under 0.30 second vs 1.5 second for the dynamic page. I have installed PHP e-Accelerator and all pages are even cached internally by Dokuwiki, so XHTML is normally served directly instead of parsing the wiki pages again. I don't know yet what more could I do since I don't really grok PHP.

BTW, Dedibox announced newer servers (64-bit Celeron based on the Core 2 architecture, 2 GB of memory, etc.) for the same price level, so I will probably upgrade unless the “old-time users” are rewarded with a cheaper subscription, as this is currently rumored.

Note: I have upgraded to Dokuwiki 2007-06-26b, please tell me if you notice any problem. At least, the plugins upgrade also brought in some fixes to ToC generation on the front page. Some day, if I ever get more time, I will probably switch to Drupal.

Some people have reported that NSPluginwrapper crashes with the new Flash 9 Update 3 (9.0.115) plug-in. It turns out this is triggered in multithreaded context and is more visible on SMP/CMP machines. If you have crashes similar to those reported in RedHat #360891 or Ubuntu #177856, please try the following patch, or use this source snapshot for the upcoming version 0.9.91.6.

As a side note, I revived my Antec Aria box with a new PSU. It was somewhat kludgely to replace due to the many cables in there but it now works and is even more silent than before!

To SheepShaver users et al., I don't forget you either. Lately, I was working on a new video back-end using OpenGL for rendering. However, I still think MacOS X is under-efficient for graphics. In particular, the MacOS X kernel is so slow, wrt. Linux on the same machine, that it prevents some further optimisations, e.g. intercepting illegal writes to write-protected memory to track emulated video memory changes (dirty pages). I am not convinced that Leopard brings the expected performance improvements either, Mach syscalls and signals delivery is painfully slow!

Some of you have been wondering what's happened lately. I will try to summarize rough status and targets in this post.

An inoperative development platform. My Antec Aria power supply burned three weeks ago and proprietary PSUs do suck. I have two choices: (i) either buy a replacement PSU for 50 EUR, or (ii) buy a new bare-bone case that includes a PSU for 80 to 100 EUR. Then, I wonder: if I were to change the case, why not change motherboard, CPU et al.?

There is no interesting desktop CPU available yet so I should wait for AMD Phenom (K10 architecture) or Intel Penryn (Core 2++).

• On one hand, there is a “native” quad core CPU capable to handle misaligned SSE vectors and that provides other interesting architectural changes for e.g. improved virtualization, cache and power management… but with an obsolete manufacturing process (65 nm).

• On the other hand, there is an improved Core 2 CPU with larger caches and SSE 4.1 support… but it will soon be obsoleted by Nehalem architecture processors with a few other instructions (SSE 4.2) in late 2008(?). In that case, why would I need a Penryn if I already have a Core 2 CPU?

The K10 processor is very appealing and provides a real advance wrt. the previous generation on the AMD line, so it looks like an interesting “immediate” choice. I would then be tempted to buy a Nehalem CPU in 2009. However, I noticed AMD is preparing a new SIMD extension (SSE5) which looks very interesting, provided they also implement Intel SSE4.x, and that may be available in 2009 too. Hmm, it could help to make a better choice if I were to know more about the Nehalem CPU architecture…

I probably should just stop thinking too far away and analyze my immediate needs and solutions available, and just go with them, i.e. get a new PSU and get it now? Oh, I hear a friend telling me: “you should apply this model/reasoning to other situations”. Probably, but I am very attached to my current Algorithm.

Basilisk II. Current CVS includes universal binaries for MacOS X with the original Cocoa GUI from Nigel Pearson. I have a couple more patches from Michael Alyn Miller to integrate and a few other arrangements to make prior to releasing a new build. BTW, the JIT is now working for any 68020+ emulation model and most instruction semantics have been validated against a real 68040 (thanks to Ray Arachelian!). I would like to rework the MacOS X video back-end but this will only cause further delay in the release process.

SheepShaver. There is a more intuitive and native GUI for MacOS X, available in CVS (thanks to Alexei Svitkine). There probably are still problems on Tiger/ppc but I have yet to find such a platform to investigate the issues myself and not waste some user's time. The video back-end rework for MacOS X will be necessary here because I want to get rid of SDL and be able to build universal binaries at once. This means a new SheepShaver release won't happen close enough to a Basilisk II release, as it used to be in the past.

• Leopard support. MacOS X 10.5 completely dropped the Classic environment. However, I don't intend to buy this system because I would like to keep my development platforms baseline enough for testing purposes. This means my PowerBook will stick to MacOS X 10.2 and my MacBook to MacOS X 10.4. This doesn't mean SheepShaver won't run on Leopard, this means I won't be able to test it there. I believe that, if SheepShaver runs correctly on Tiger, there is no reason it wouldn't run on Leopard.
  
  BTW, I hope Leopard matured enough to implement poll() and thread cancellation points correctly. I also wonder if performance now matches Linux wrt. exception delivery, though I doubt it (Mach IPC) but who knows…

• Windows Vista support. I have Windows Vista (64-bit edition) installed on my professional laptop but the lesser I use it, the better I feel. For one, I am mainly developing for Linux platforms. Second, Windows Vista is depressively slow and sub-optimal to use. It would be nice to have Basilisk II ethernet driver for Vista, anyone willing to take this task? I should still have Lauri Pesonen's old sources somewhere for anyone interested… Otherwise, ethernet solutions from a Basilisk II / SheepShaver point of view for Windows Vista will remain the “NAT/Router” and “slirp” network stacks, and “TAP” from OpenVPN. However, I don't think users would want to install the latter.

NSPluginWrapper. Thanks to Martin Stransky for still sending me patches, they will be reviewed soon. The next release will be a major version (most likely 0.9.92) because of license and internal changes.

• License change. Some people expressed an interest in integrating nspluginwrapper parts into a browser. I am not against this idea though I have yet to see sort of a reference implementation because nspluginwrapper is “only” an NPAPI bridge, not an NPAPI emulation layer. The plug-in part, i.e. npwrapper.so and dependent code like RPC/marshalers, is intended to be LGPL. The viewer part and configuration tool are intended to remain under GPL.

• Internal changes. The RPC code is intended to be more portable and flexible (API additions). The windowing system needs to be abstracted too (raw X11, gtk and win32). This means code will be re-organized, not overhauled since it should not really impact the way nspluginwrapper works. The ultimate goal is to provide Windows plug-ins support either under Linux or Windows platforms. Yes, I also thought about MacOS X plug-ins support under MacOS X but, if I remember correctly, NPAPI is undergoing changes on that platform. So, I probably should wait for its finalization?

I hope this clarifies the current situation. I am sure there are more things to work on (including for other projects), but this gives a rough idea of where I am heading to.

Oh sunny day in Paris, it was becoming a scarce resource lately! And why am I blogging here about a new release of nspluginwrapper instead of getting out? Huh, let's say I needed my mind to get busy differently, looking for other kinds of problems, and feeling capable to fix those at least…

As usual, NSPluginWrapper is an Open Source compatibility plugin for Netscape 4 (NPAPI) plugins. That is, it enables you to use plugins on platforms they were not built for. For example, you can use the Adobe Flash Player 9 plugin on Linux/x86_64, NetBSD and FreeBSD platforms.

Short list of changes in 0.9.91.5, details to follow:

• Fix a memory leak in NPP_Destroy()
• Fix DiamondX XEmbed example plugin
• Fix focus problems (Debian bug #435912)
• Add support for 64-bit plugins (Martin Stransky)
• Add support for newer NPAPI 0.17 functions and variables
• Add support for broken 64-bit Konqueror versions (run-time detect)

Improved XEMBED support. NSPluginWrapper now has improved support for plugins using the XEMBED protocol. This means theDiamondX XEmbed example plugin is now working even though that was not specifically an XEMBED problem but rather a communication/initialisation one. Most importantly, Flash Player 9 Update 3 (beta 2) is also working better. Note that Konqueror NPAPI emulation layer still doesn't support the XEMBED protocol, so this only works for Mozilla-based browsers.

Fixed focus problems with Flash Player. Debian bug #435912 is about Flash Player grabbing the keys from other windows even if the Flash Player window lost the focus. The way nspluginwrapper handles input focus has now changed, thus also removing some other (rare?) crashes. However, this curently relies much on XEMBED support. And since Konqueror doesn't implement it yet, this bug is still present there.

BTW, I also suspect that Flash Player is not totally innocent to those focus problems. The Flash Player 9 Update 3 (beta 2) “re-introduces” the bug, though it's not nspluginwrapper's fault this time as the problem can be reproduced with a plain 32-bit browser.

Run-time detect broken 64-bit Konqueror versions. Support for Konqueror was added in version 0.9.90.4. However, it required an additional patch to get 64-bit Konqueror on-par with NPAPI defined types. Now, nspluginwrapper will try to detect broken 64-bit versions of Konqueror at run-time and should be able to address both cases from a single binary.

The heuristics for detecting Konqueror are: “it's a Qt application that has either an Xt application name of nspluginviewer or a user-agent string containing Konqueror”. The heuristics for detecting what I (wrongly?) call LONG64 NPAPI structures, i.e. those that were made up of 64-bit uint32 types, are mostly based on what NPP_SetWindow() receives and assumptions of what specific NPWindow fields have to look like. Besides, Konqueror doesn't implement NPN_NewStream() et al., so this also simplifies the wrappers around NPStream in this case. You are welcome to suggest any improvement to those heuristics, but I believe they are reasonable enough.

Support for wrapping 64-bit plugins. Martin Stransky from Red Hat Engineering has added support for 64-bit plugins. This means you can now wrap both i386 and x86_64 plugins into an x86_64 browser. This is so that you can let a crashing plugin die alone without bringing the browser with him into the grave.

BTW, if you are running Linux, you should use the packages provided by your distribution. In particular, Fedora packages have further improvements to fit both their build and run-time policies. Additional changes (e.g. plugins viewer restart) will be merged in a future release.