Wine Plugin Api
It would be cool to be able to have:
WinAmp visualization plugins running inside XMMS or some other music player (Banshee/RhythmBox etc)
- Of course some of these are sucky or not that useful on Linux, but still, there are some real jewels out there.
We could use this to allow Rhythmbox/Banshee/AmaroK to play songs bought from the iTunes music store without having to constantly break their DRM (iTunes 6 DRM has not yet been broken) - QuickTime is a library that other apps can use, so could simply be a pluggable audio backend like GStreamer or Helix. Likewise, with a bit of work playback of encrypted WMA/WMV files in such a way that doesn't make defeating the DRM trivial would be possible (and _very_ useful)
An ActiveX Firefox host. A lot of corp migrations to Linux are blocked on web apps that require IE or ActiveX
Things to google are, Reaktivate (svn), Gecko ActiveX, Mozilla XTF - Ability to use Windows GUI themes in GTK+ (though actually, I'm not sure there are many which are all that pretty)
- Ability to use the Windows Flash plugin in Linux (the native one lags behind the Windows one quite seriously in terms of features...)
See the original proposal here:
Here's a bit more so you can see what you're getting yourself in for ....
- There is some code in Ardour that can be reused
- The code in xine/mplayer/gstreamer might prove helpful as a reference but it's been so badly hacked/rewritten/forked that it's no longer worth trying to merge in (even if the licenses were compatible, which I'm not sure they are)
There are a few different technical problems here:
- wine_init() has to be callable from within a pre-existing program
The Wine bootup sequence is rather convoluted, for instance, you end up running on a new stack
So there has to be some way to do this in a more controlled manner, perhaps at the expense of slightly less compatibility? - You need a way to "adopt" a thread into the Windows environment, which basically means registering it with the wineserver and giving it a TEB etc ... so, adapting the existing thread initialization code to be independent of actually creating the underlying thread.
- Address space layout conflicts. See the dev guide.
- For bonus points, embedding a Win32 window into GTK+ (XEmbed?)
And then there's the fun of producing a nice API that other developers will be able to easily use.