Windows dll as Linux Shared Object

[Phil Lodwick]

Greetings,

My googling skills are letting me down today.   I believe I have seen several
people requesting to do the same and answers indicating it is possible.
However, after several hours of reading email archives from 2000-2007 are am
officially confused :-(

I have successfully ported an application using winelib.  However, what I
really want to do is port a DLL to an SO which I can use natively from a
Linux application.

I believe this is something that can be done with winemaker/winebuild etc if
I just get the recipe right -- correct?

ie:

WindowsDLL.cpp

int AndTheAnswerIs()
{
  Return 42;		
}

WindowsDLL.def

EXPORTS:
    AndTheAnswerIs

Use winemaker/winebuild to create WindowsDLL.dll.so

Linux.cpp:

main()
{
  printf("AndTheAnswerIs: %d\n", AndTheAnswerIs());
}

g++ linux.cpp -lWindowsDLL

Is this possible, or am I missing something?

Thanks much!

Phil

[Stefan Dösinger]

I'm not the DLL expert, but I think you're missing something here.

The problem is that your windows dll will most likely use the windows 
api(otherwise, don't use wine at all). The windows API depends on some other 
things, like a few memory management constraints, the windows registry, and 
most likely other things too. So you can't lift the Wine core dlls outside of 
the enironment wine sets up.

Applications and DLLs ported using winelib are native Linux .so files. So you 
can try to link then in, but you'll get unresolved symbols which in the long 
run will end up somewhere in ntdll.dll.so and libwine.so. And I think both of 
them depend on the environment wineloader sets up.

So the options you have are doing a real port of the dll if it does not depend 
on the win32 api too much(so ditch wine), or put the whole app into wine(do a 
full winelib port of the application), or to write some proxy winelib app and 
talk to the DLL using ipc like sockets, pipes, shared memory, etc.

[Phil Lodwick]

> or to write some proxy winelib app and 
> talk to the DLL using ipc like sockets, 
> pipes, shared memory, etc.

Thanks Stefan.  I thought I was missing something.

This was the approach that I was planning on as a backup.  Looks like I bring
the backup plan to the front burner.  Basically Linux wrapper .so execs
winelib app and then communicates via pipes.

Thanks again,
Phil

[Stefan Dösinger]

Am Donnerstag 12 April 2007 00:28 schrieb Phil Lodwick:
> > or to write some proxy winelib app and
> > talk to the DLL using ipc like sockets,
> > pipes, shared memory, etc.
>
> Thanks Stefan.  I thought I was missing something.
>
> This was the approach that I was planning on as a backup.  Looks like I
> bring the backup plan to the front burner.  Basically Linux wrapper .so
> execs winelib app and then communicates via pipes.

What is the problem with running the whole app as a winelib app? You don't 
save any resources by having the application outside since you still have 
wine running, and you have the IPC overhead. You should still be able to use 
any Linux Library from inside a winelib app(Ok, I don't know how to do that 
with the C++ libraries like for file access to use Linux paths instead of 
Windows paths).

[Phil Lodwick]

> What is the problem with running the whole app as a winelib app? 
> You don't save any resources by having the application outside 
> since you still have wine running, and you have the IPC overhead.

I want to provide a library other developers can use without having them
worry about the intricacies of execing a winelib application and the IPC.  I
will take care of all that in my wrapper shared object.

Phil

[Stefan Dösinger]

Am Donnerstag 12 April 2007 15:57 schrieb Phil Lodwick:
> > What is the problem with running the whole app as a winelib app?
> > You don't save any resources by having the application outside
> > since you still have wine running, and you have the IPC overhead.
>
> I want to provide a library other developers can use without having them
> worry about the intricacies of execing a winelib application and the IPC. 
> I will take care of all that in my wrapper shared object.

Fair enough :-)