[tonyb]

Are the xbmc-linux active devs (yavult, jmarshallnz) hanging out on a particular irc channel? #xmbc-linux was created on Sunday, if they'd like to go there to discuss.

I've got a few patches that I'd like to submit to someone with SVN rights, and I also wanted to discuss what the approach is that is going to be taken with loading the dlls?

Seems to me that using the "compiled for windows" dlls is going to be a hard road, as we'll have to re-implement the imports that those dlls use ( eg, libid3tag relies on MSVCR71 which in turn relies on KERNEL32, then NTDLL )
I've been able to modify the DllLoader so that it looks for and loads linux .so files instead. It's able to resolve the exports (well, most of them, anyway ) from libid3tag.so (this library was just a pre-compiled one from the ubuntu repo )....so perhaps those dlls could be recompiled and targetted as linux shared libraries?

So anyway, let's talk?

I've got a head full of ideas, that are driving me insane!

[elupus]

we need to get alot of windows exports emulated to get everything going anyways, however i'm all for getting it to support linux shared objects too. upload the the patch to sourceforge then i'll have a look at it.

we hang out in #xbmc as always.

[tonyb]

Sure, we need to implement a lot of windows api calls as used in the xmbc code, but emulating kernel32 and ntdll? That's a whole other world of pain. (IMHO)

upload the the patch to sourceforge then i'll have a look at it.

Don't I need an svn account to do that? I don't have one.... is there a process?

[Gamester17]

All patches that are under 255KB when zipped can be submit to our patch-tracker on XBMC's the SourceForge project site (link), please create separate patched for each fix (or feature/function) so it is easy for our developers to keep apart and manage (close patches that have aready been applied), thanks. We ask the same when submitting bug reports and feature requests to those trackers, (only one problem per Bug Report and Forum thread is allowed (for easier manageability).


http://www.xboxmediacenter.com/wiki/inde...ment_Notes
http://www.xboxmediacenter.com/wiki/inde...pment-Team

[elupus]

ntdll isn't needed. we already emulate alot of kernel32 on the xbox already. check export_kernel32.cpp in source tree. anything that is prefixed with dll is emulated to a certain degree.

everything need not be emulated the way our dlloader works. only functions that actually get's called, thus it can be taken step by step, dll by dll.

The reason we need this is for example paplayer that uses a huge amount of dll's. more painfull to port every dll + some are closed source. then we have wmv/wma and quicktime, ffmpeg still only have partial support for those formats, mplayer uses it's own dlloader to use windows dll's.

[Gamester17]

Here are a couple of great links for any programers out there that was to help:
http://www.xboxmediacenter.com/wiki/inde...r_Workings
http://www.xboxmediacenter.com/wiki/inde...evelopment
and as for the DLL loader specific case see:
http://www.xboxmediacenter.com/wiki/inde..._Libraries
http://www.xboxmediacenter.com/wiki/inde...ource_code

[tonyb]

Thanks for the links, and now I can see why we would want to continue with the windows libs in the dll loader - it gives us the ability to reimplement certain calls to work on top of the "XBox Filesystem" (giving us protocol/location independence).... cool.

I'll have to dig deeper to find out how the symbols that the dlls import are exported out of xbmc.

Cheers.

[Gamester17]

While you guys are looking at the DLLs you might also want to take a look at XBMC's Visualisations (.vis) and Screensavers (.xscr) APIs which also use the DLLloader. True the visualizations and screensavers themselves are currently designed for DirectX Direct3D but they could probebly all be ported to also support OpenGL, if the API could give the a parameter of the platforum (like "-direct3d", "-opengl" or "-sdl") on loading them so it is done automaticly and no need to keep two vis/xscr files for Direct3D and OpenGL.

[elupus]

tonyb, dlloader is up and running right now. currently only msvcr(t/32).dll is exported from xbmc thou.

exports from xbmc is done from the exports_*/emu_* files in the exports subdir of dlloader. After you get an export_* file to compile, with any needed emulated functions in the emu_* file you add another DllLoader static variable in DllLoaderContainer.cpp where msvcrt stuff is now, and it get's exported. Kernel32.dll is missing (will probably work on that myself next), but feel free to take a stab at the socket exports.

I've been able to modify the DllLoader so that it looks for and loads linux .so files instead.

I'd very much like to have a look at those modifications if they are atleast sort of clean . I assume you replaced the coff loader with an elf one?

/Joakim

[Gamester17]

You guys might get some WINE developer (like [EMAIL="[email protected]"]Mike Hearn[/EMAIL]) to help you with the DLL loader out as well, one of their ideas for this year's SoC (Google Summer of Code 2007) was actually "Implementing a WinePluginApi so other programs can use Windows DLLs inside of Linux apps", so they would love to have the same function in WINE as you are implementing in XBMC Linux port, so if you can get it working good in XBMC then they might want to port it over to WINE (and thus it be in their interest to help XBMC with this project). You can read more about their idea here:
http://www.winehq.org/pipermail/wine-dev...46779.html
and here:
http://wiki.winehq.org/WinePluginApi

Good idea or not?

PS! Have anyone looked into backporting any updates that MPlayer have added to their DLL loader in their SVN since it was first ported and introduced into XBMC?, have they make any improvements or bug-files to it over the last year or so?

PPS! In related news to loading visualizations DLLs; MediaPortal developers has now code to their SVN to support loading and using of WinAmp visualisations as is, see:
http://forum.team-mediaportal.com/showth...hp?t=21481

[tonyb]

I'd very much like to have a look at those modifications if they are atleast sort of clean . I assume you replaced the coff loader with an elf one?

No, nothing that complicated, and after reading up on why we export msvcrt & friends to the loaded dlls, I don't think you'd want my changes.

All I did was use dlopen() and dlsym() to load an .so, and find the exported functions. So all the benefit we get from loading the dll ourselves no longer applies -- so in the end, it's not that useful.

[elupus]

ok, one can use preloading to overload specific libc functions (like open/close and so on). that is what we intend todo.

[yuvalt]

Are the xbmc-linux active devs (yavult, jmarshallnz) hanging out on a particular irc channel? #xmbc-linux was created on Sunday, if they'd like to go there to discuss.
I've got a head full of ideas, that are driving me insane!

Hi,

We are always happy to get help from people. I've added another DllLoader which loads .so files (called SoLoader). It still causes some leaks but it is working (ImageLib is loaded with it).

If there are areas that you want to assist, please let me know. There are quite a few areas that no one is dealing with. For example, if you want to add support for lirc (remote control) or other area, please let us know.

-Yuval

[Gamester17]

I've added another DllLoader which loads .so files (called SoLoader). It still causes some leaks but it is working (ImageLib is loaded with it)

I'm just curious, why is a seperate loader needed for "so" library files (is that not just unnessesary code duplication?)? Would it not be better to extend the existing DllLoader so that it supports loading both Win32 (.dll) and Linux (.so) dynamic libraries? If it the only way to load closed source binary libraries (.dll for Win32, and .so for Linux) such as audio/video codecs then I understand, but if the DllLoader can not be extended to load a specific library then for at least for open source libraires the libraries themself should be able to be modified so they will load under our existing DllLoader, shouldn't they?
http://winehq.org/site/docs/winelib-guide/bindlls

...if I understand correctly then MPlayer for Linux for example can load both codec library files that are Win32 (.dll) and Linux (.so) dynamic libraries, how is that MPlayer can do not and XBMC can not?, I thought that MPlayer "loader" code is what XBMC's DllLoader was originaly based upon?, see "\mplayer\trunk\loader\" in MPlayer Subversion repository:
http://www.mplayerhq.hu/design7/dload.html



PS! As for kernel32.dll emulation in XBMC (export_kernel32.cpp), have you looked at getting some of the code for that from WINE, (not the whole WINE, only some parts from their kernel32 emulation code), or is WINE code to complicated and bloat to even try to extract anything that could be used in XBMC's Linux port?
http://winehq.org/site/docs/winedev-guide/x3500
http://winehq.org/site/docs/winedev-guide/index
http://winehq.org/site/docs/winelib-guide/index