SOC Idea: Easy usage of native DLLs in Linux programs
mike at plan99.net
Tue Apr 18 16:40:51 CDT 2006
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! :)
More information about the wine-devel