Hi,
I want to write a program that uses audio plugins. I also want to add support for a couple of plugins I use that are compiled as windows dlls. I know the interface the plugins expect, so there will be no real problem in this regard. But I will have to know about how to load a windows dll under linux and the potential obstacles involved in this.
I know that some other free programs are already loading windows dlls: mplayer loads foreign windows video/audio codec dlls and the cvs version of soundtracker more or less loads so-called "buzzmachines". Both of them use wine code to achive this.
I basically will have to do the same as soundtracker. The soundtracker code uses wine code but it is pretty outdated (may 2001). The actual code loading the buzzmachines is closed source because the author of the original windows program using buzzmachines does not want that code snippet to be free - so I cannot read it in plain C. But I can see what functions are being called in the object code (thanks nm). Three of which come from wine:
LoadLibraryA GetProcAddress FreeLibrary
Are these all I need? In theory, this looks about enough to be able to load a shared object... but I will need a lot of other wine internals too, in case a dll does a system call (like malloc, which will definitely happen), won't I?
What happens if I pass a pointer to a method contained in a windows dll?? Will wine take care about low level stuff like keeping track of memory layouts of structs and convert them if they are incorrect? More precisely: If I reimplement data structures external to the dll but used by it, will the difference in memory layout between the original struct the dll expects and my new implementation under linux matter?
Thanks stefan
Stefan Sperling wrote:
But I can see what functions are being called in the object code (thanks nm). Three of which come from wine:
LoadLibraryA GetProcAddress FreeLibrary
Hi Stefan.
What you just saw is the bare minimum you need in order to load a library. I'm afraid, however, that it is far from all you need.
First, when you load another library, that library may need any DLL at all. In order to assess how much of Wine you need, you need to also look at the DLLs loaded. Also, please bear in mind that GetProcAddress can load other functions, and those functions called.
Are these all I need?
Almost defenitely not.
In theory, this looks about enough to be able to load a shared object... but I will need a lot of other wine internals too, in case a dll does a system call (like malloc, which will definitely happen), won't I?
Yes. That can, potentially, grow to be the entire rest of Windows. Most likely, however, by looking at the DLLs loaded, you can narrow that down, somewhat.
What happens if I pass a pointer to a method contained in a windows dll?? Will wine take care about low level stuff like keeping track of memory layouts of structs and convert them if they are incorrect? More precisely: If I reimplement data structures external to the dll but used by it, will the difference in memory layout between the original struct the dll expects and my new implementation under linux matter?
Sometimes.
The theory goes thus: An ELF binary can only call other ELF binaries. A PE (Windows) binary can only call other PE binaries. Wine invented something called "winelib executable". This is an ELF library that can also link to PE DLLs. It appears that your best bet, if you don't want to embark on massive copy/paste activity, is to create your util as a winelib. There are some disadvantges to that as well (a dependancy on Wine, for one). I'll let someone who's actually worked with winelib answer those parts, however.
Thanks stefan
Shachar
On Fri, Jun 06, 2003 at 08:47:31AM +0300, Shachar Shemesh wrote:
Stefan Sperling wrote:
But I can see what functions are being called in the object code (thanks nm). Three of which come from wine:
LoadLibraryA GetProcAddress FreeLibraryHi Stefan.
What you just saw is the bare minimum you need in order to load a library. I'm afraid, however, that it is far from all you need.
First, when you load another library, that library may need any DLL at all. In order to assess how much of Wine you need, you need to also look at the DLLs loaded. Also, please bear in mind that GetProcAddress can load other functions, and those functions called.
I don't think there will be a lot of dependencies on other DLLs, apart from the standard C stuff (which is a lot already!). I can only think of one or two, and they do not belong to windows. I have them and I will load them as well. What do I have to look out for when loading a DLL other DLLs depend on? If a DLL calls a function of another DLL, is wine managing the call for me or will my code have to be aware of this, granted I use winelib? Will the requested DLL be loaded automatically? Is the standard C stuff covered by wine? What files from the wine source tree will I need so I have the apropriate code at hand?
What happens if a DLL expects functions from the windows environment in a certain windows DLL not yet implemented in wine? Anything else than my app crashing when those functions are called, that is? How could I provide those functions myself?
Bottom line: I have a lot of questions... Is there any documentation about this? I don't want to bother the wine-devel mailing list too much with these problems since they are not really concerned with developing wine itself.
Wine invented something called "winelib executable". This is an ELF library that can also link to PE DLLs. It appears that your best bet, if you don't want to embark on massive copy/paste activity, is to create your util as a winelib. There are some disadvantges to that as well (a dependancy on Wine, for one).
Will this affect my whole app or can I tuck the winelib dependency away in a seperate module? Again, I bet there's a lot of documentation on that in the sheer amount of wine docs, is there?
Stefan
On Fri, Jun 06, 2003 at 12:23:50PM +0200, Stefan Sperling wrote:
On Fri, Jun 06, 2003 at 08:47:31AM +0300, Shachar Shemesh wrote:
Wine invented something called "winelib executable". This is an ELF library that can also link to PE DLLs. It appears that your best bet, if you don't want to embark on massive copy/paste activity, is to create your util as a winelib. There are some disadvantges to that as well (a dependancy on Wine, for one).
Will this affect my whole app or can I tuck the winelib dependency away in a seperate module? Again, I bet there's a lot of documentation on that in the sheer amount of wine docs, is there?
I just found the winelib docs. I'll read them and come back if I have further questions.
thank you stefan
Will this affect my whole app or can I tuck the winelib dependency away in a seperate module? Again, I bet there's a lot of documentation on that in the sheer amount of wine docs, is there?
It will affect the whole process, if you use IPC (like corba) between components then you can isolate WineLib at the object level.
Stefan Sperling wrote:
Will this affect my whole app or can I tuck the winelib dependency away in a seperate module? Again, I bet there's a lot of documentation on that in the sheer amount of wine docs, is there?
Stefan
This will, in fact, affect your entire app. You can, however, create a stub utility. This stub will be the winelib. You should be able to use it from a regular ELF exec, and communicate with the PE DLL that way. Not sure what the implications be in your case, however.
Shachar
On Fri, Jun 06, 2003 at 06:36:36PM +0300, Shachar Shemesh wrote:
Stefan Sperling wrote:
Will this affect my whole app or can I tuck the winelib dependency away in a seperate module? Again, I bet there's a lot of documentation on that in the sheer amount of wine docs, is there?
Stefan
This will, in fact, affect your entire app. You can, however, create a stub utility. This stub will be the winelib. You should be able to use it from a regular ELF exec, and communicate with the PE DLL that way. Not sure what the implications be in your case, however.
I thought about creating a class (I'm in C++) that will create a subprocess loading dlls via winelib (ie just as you would in windows). It shall do the forking and inter-process-communication involved itself, and the code using the class shall be able to handle the dll just like a "normal" shared object:
LoadLibraryA GetProcAddress FreeLibrary
or whatever I'll call them...
As for implications, there is the story with the memory layout of structs I'll be passing to the dlls... will they have to be linked with the winelib too? But that design is about according to what you were saying, isn't it?
I cannot figure out yet to what extend my program will have to be dipped into the winelib. Mmmh... Looking at it now it might even be easier to just write the whole thing as if it was to run under windows and compile it against the winelib. But I'd actually rather not get my hands too dirty on the windows API ;-)
Any suggestions?
thanks a lot stefan
I cannot figure out yet to what extend my program will have to be dipped into the winelib. Mmmh... Looking at it now it might even be easier to just write the whole thing as if it was to run under windows and compile it against the winelib. But I'd actually rather not get my hands too dirty on the windows API ;-)
Well you can make your app a WineLib binary but still use native Linux APIs like GTK or whatever.... using WineLib just *allows* you to use the Win32 API, doesn't force you to
On June 6, 2003 08:36 am, Shachar Shemesh wrote:
Stefan Sperling wrote:
Will this affect my whole app or can I tuck the winelib dependency away in a seperate module? Again, I bet there's a lot of documentation on that in the sheer amount of wine docs, is there?
Stefan
This will, in fact, affect your entire app. You can, however, create a stub utility. This stub will be the winelib. You should be able to use it from a regular ELF exec, and communicate with the PE DLL that way. Not sure what the implications be in your case, however.
Shachar
I wish it were possible. However from what I remember from previous discussions, wine has to be the main ELF executable. That's why I need a client-server setup to allow PHP under Apache to be able to talk to a Windows exe running under wine.
On Friday 06 June 2003 05:58 pm, Bill Medland wrote:
I wish it were possible. However from what I remember from previous discussions, wine has to be the main ELF executable. That's why I need a client-server setup to allow PHP under Apache to be able to talk to a Windows exe running under wine.
I think there were some experimental/kludgy patches for this originating from the .NET-for-UNIX project (for the life of me I cannot think of their name, and it's impossible to search for ".net").
On June 6, 2003 05:36 pm, Gregory M. Turner wrote:
On Friday 06 June 2003 05:58 pm, Bill Medland wrote:
I wish it were possible. However from what I remember from previous discussions, wine has to be the main ELF executable. That's why I need a client-server setup to allow PHP under Apache to be able to talk to a Windows exe running under wine.
I think there were some experimental/kludgy patches for this originating from the .NET-for-UNIX project (for the life of me I cannot think of their name, and it's impossible to search for ".net").
You mean Mono?
On Monday 09 June 2003 04:04 pm, Bill Medland wrote:
I think there were some experimental/kludgy patches for this originating from the .NET-for-UNIX project (for the life of me I cannot think of their name, and it's impossible to search for ".net").
You mean Mono?
Of course. I suddenly remembered this when I saw Marco Pietrobono's name on wine-devel yesterday. Go figure :P
-
Bill Medland -
Gregory M. Turner -
Mike Hearn -
Shachar Shemesh -
Stefan Sperling -
Stefan Sperling