As announced in a previous blog entry, nspluginwrapper 1.0.0 was around the corner. I got some time this weekend to iron out the latest (cosmetic) problems. This version doesn't feature everything I wanted to include for a “1.0” release but it turns out to be rather stable for some time now. Missing features became either obsolete (XPCOM) or totally irrelevant (Windows support).

Here is a short list of changes since 0.9.91.5, details to follow:

• Don't wrap root plugins to system locations, keep them private
• Fix support for Acrobat Reader 8 (focus problems)
• Fix support for mozplugger (in full-debug mode)
• Fix support for WebKit
• Fix crashes with Flash Player 9 Update 3 (9.0.115)
• Improve error handling during RPC initialization (possible memory leak on error)
• Improve error handling in NPP_WriteReady() and NPP_Write()

Wrapping root plugins. Previous versions of nspluginwrapper used to incorrectly wrap root plugins system-wide. The fix introduced in this version is very minimalistic and works as follows: any plugin located under ~root will be wrapped into his private plugins directory (~root/.mozilla/plugins). If a wrapped root plugin is found in any system location during upgrade, it will be moved to the ~root private location instead. A better fix is planned for nspluginwrapper 1.2.0.

Acrobat Reader 8. A very stupid bug was introduced in version 0.9.91.5 which prevented Acrobat Reader 8 (8.1.2) from working correctly: no keyboard event was propagated to the plugin. This is now fixed. For reference, this problem is reported as Novell bug #353503. Thanks to Stanislav Brabec for reporting the issue.

WebKit. This release fixes support for WebKit-based browsers. In particular, this should fix WebKit bug #18883 whereby plugins were crashing on exit. However, you will also need a recent enough snapshot of WebKit (>= rev 33570, see WebKit bug #18882).

Flash Player. This release fixes support for Flash Player 9 on Linux for SMP or CMP systems.

There are some (unresolved) threading issues with Flash Player 9 on *BSD systems, in particular FreeBSD 6.1 and NetBSD 3.1. i.e. pages with only one Flash instance will work though multiple instances will fail because of multithreading. This may be an issue with the Linux emulator on those systems. Probably some TLS stuff or some Linux syscalls unsufficiently supported. BSD hackers should probably look into waitid, tgkill, futex syscalls and also coverage of newer CLONE_* flags.

Flash Player 10 Beta for Linux is working but you may encounter keyboard input problems with some sites. In particular, the usual Bloxorz game^W testcase at Addicting Games is failing again with this Beta. This is not an nspluginwrapper problem but a generic issue with Flash Player 10 Beta that also occurs with 32-bit web browsers.

Build system. Some –with options were moved to –enable style. In particular, –enable-biarch replaces –with-biarch and –enable-generic replaces –generic-build. Besides, the binaries are no longer stripped by default. Should you wish to strip the installed files, you have to configure your build with the –enable-strip option.

NSPluginWrapper 2.0.0 preview. There is no public preview of this because source code is currently ugly and maintaining three branches at a time was going to be a nightmare. Now that nspluginwrapper 1.0.0 is released, trunk will be the default development branch towards 1.2.0. Then, it will be branched out within the next few months for nspluginwrapper2 integration.

The primary goal of this project is not to rewrite its core functionality but rather to re-organize the source code so that it is more flexible and suitable for inclusion into third-party applications (public API). nspluginwrapper2 will also address support for OpenGL-rendered browsers, WebKit/Clutter in particular. Here is a short video to demonstrate this: Magic Pen in a WebKit actor. You can also note that the reflection texture accounts for the plugin texture (Magic Pen).

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.