SOC Idea: Easy usage of native DLLs in Linux programs

[Mike Hearn]

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