Various projects have re-implemented the code necessary to host Win32 DLLs in-process, for instance Xine, MPlayer and GStreamer all have (different) forked, badly hacked copies of the Wine codebase inside themselves to load and use codec DLLs. The GIMP now has the ability to use Photoshop plugins using Wine. And so on.
It'd be nice if there was a simple API programs could use to do this, for instance, wine_dlopen("whatever.dll"), wine_adopt_thread() and so on to make re-use of Win32 components and COM objects easy.
This has been discussed before and Alexandre wasn't sure it was worth it as it'd be a significant extension to the (stable??) Wine APIs, so IMHO this one shouldn't be judged on whether it gets checked in or not but rather whether it works and how easy it is to use.
Thoughts? I know roughly what needs to be done so I could mentor this one, but students be warned - it requires _excellent_ understanding of operating system design and things like threading. There's a reason such a thing doesn't already exist, and it's because it's hard. On the flip side it's not a massive amount of code IMHO so the work would mostly involve learning, debugging, etc rather than simply being a hard typing slog.
Also, a student has all summer and the nice thing is, it's mostly generic computing knowledge that'd be useful for future work (whereas learning a specific api in depth probably isn't ...).
Such a thing has many uses:
* Hosting ActiveX controls inside a native Firefox
* Allowing more apps to use plugins from popular Windows apps. GIMP is a bit weird in that its plugin system is out of process and has a simple wire protocol .... a hangover from the days before ELF (!!), but most programs aren't like that. EG imagine being able to use WinAmp visualizion plugins in your music player of choice.
* Maybe getting the xine/mplayer/gst mess sorted out a bit (on the other hand they need to run only a small, relatively unchanging amount of code so it may not be worth it)
* Allowing piece-by-piece porting of a modular Windows app without Winelib (which is annoying as you have to switch toolchains all at once, you may not even have the sources to some DLLs etc ...)
* Actually there is a huge component marketplace in Windows which is especially rich in the boring sort of business components (grid views etc) that open source hackers tend to ignore ... this could allow developers to embed some of the very sophisticated Win32 business objects into native Linux apps, so reducing development costs (of course the result would not be free software, but for in house custom apps that's not really a concern anyway)
I'm sure you can think of some more. Discuss! :)
thanks -mike