Winlib, winebuild and linux shared libraries questions

[Paulo de Carvalho]

Hi Lawson,

I am very sorry for only be answering now. It was very rude of me
to leave you without any answer for such a long time, after all your
answers.

After I was contacted be another person interested in this issue I
decided to face this issue again. Maybe this way some momentum to
can be created to resolve this.

We've been advancing in our project but, unfortunately, without linux
support. At least, I convinced our project manager to use MinGW
(Minimalist GNU for Windows ) as our main compiler platform, leaving
MSVC out of the picture :).

Our (monopolistic) db library supplier keeps postponing linux support
and I think it will never be supported since there isn't a single market
competitor and I we are the only client asking for linux support.

whitnl73 at juno.com wrote:

 >> Well, working with JNI, involves creating a library. Using a library,
 >> I can't use the wine command to setup the windows environment these
 >> dlls expect so I must do this in some other way.
 >
 > Why not?  What is wrong with system(), - as long as not in a suid
 > executable - or fork() and execve()?  A winelib program has the *NIX
 > environment, fd's and library API available to it.


Sorry... I'm not sure I'm following you here... Are you saying I can use
system()/fork()/execve() to lauch the winelib program to setup the
windows environment needed to call DLL functions from my JNI shared
library?

Or are you suggesting I should  make a winelib program and then use
system()/fork()/execve() to call this winelib program from the JNI
shared library? But in this case will I not need some way to pass data
between the winelib program and the JNI library, like IPC or some
kind of io redirecting?

 >> You already said I can't use the library <appname.so> winemaker
 >> creates because it's an "Unix library in format not in content" so,
 >> this won't do.
 >
 > Well, sort of.  Any reference not imported from a winelib dll
 > (remember you can create your own winelib dll's too (and/or contribute
 > them back to wine, if they have some wide relevance)) is resolved
 > against the *NIX libraries, so in that respect a winelib app or dll is
 > a *NIX program or library in content as well.  Winemaker (or
 > winebuild (not sure which) sets up an _init to do windows
 > initialization and call either main or WinMain...  winebuild has
 > an option -i to force a reference to be linked against the unix
 > libraries instead of imported from a winelib dll.

I see.

 >> That's why I was thinking in taking the wine code needed to setup the
 >> virtual windows environment and put it in the _init proc on a shared
 >> library...
 >
 > I don't think you need to.  See if you can make sense of what I've
 > written above.

The imported references or the system()/fork()/execve() issue?

 >>   "If a function ``_init'' is exported in a library, then it is
 >> called when the library is first opened (via dlopen() or simply
 >> as a shared library)." - Program-Library-HOWTO
 >>
 >> but many questions arise...
 >>
 >> - Can _init proc be used to do something like this ?
 >> - Which pieces of wine code should I put in the _init proc ?
 >> - Is the _init proc behavior is compatible with wine way of doing
 >> things?
 >> - How JNI will react to something like this ?
 >>
 >>
 > If you turn out to need answers to these, we may need to move this to
 > wine-devel

I don't fully understant yet how Windows DLLs and linux shared libraries
work, so my conclusions may be wrong.

The way I understand how Wine works is, if you want to port a Windows
DLL to linux and use that DLL from a Linux program, you will have to
compile all Linux programs, which use the ported Windows Dll, like they
were ports from a Windows programs. You will then need to lauch them
with the wine command (the need for "Wine runtime" is always implicit).

The way I see it, in the specific case of ported Windows Dlls, this is
wrong.

I have nothing against this behavior, in the case of ported windows
programs *with* ported windows DLLs. Now, when I want to develop on
Linux and use some proprietary windows DLLs, for wich I don't have the
source, I don't want to be forced to use wine to launch my Linux
program. I don't mind doing a wrapper around the propretary Windows DLL
but that's it.

You should be able to port the Windows DLL as a normal linux shared
library, this way you could compile any linux program that uses the
ported Windows DLL normally, as you would if that linux shared library
was not a port from a Windows DLL. I am aware the differences
between Linux and Windows calling conventions, but I think that could
be resolved with somekind of wrapper. Of course you would also always
need to have the "Wine runtime" with the system/drives configuration,
system dlls, etc, but the whole picture would be a lot cleaner and
transparent for the linux developer.

What about JNI?

Well, I can't call a winelib program from a Java program through
System.loadLibrary( java.lang.String ). For this I need the Java
JNI program to be compiled as a linux shared library. This was
the reason for this thread.

In this case, the only way I could use System.loadLibrary(
java.lang.String ) on a ported Windows DLL from Linux using Wine
was to use the Windows JVM and use Wine to lauch the java.exe!!
This could work but IMO is the wrong way of doing things.

That's why I thought:

"Well, wine command "bootstraps" the emulated windows environment
and starts wineserver if it's not running, right? So what if I
put this code from wine command on _init proc on the shared
library it should have the same effect, no?"

This is almost like embbeding the wine executable in each ported shared
library. Is this feasible? (See all my above questions about a
shared library _init proc).

 >> > As it said in the snippet you quoted to start this, a wine dll is a
 >> > win32 dll encapsulated inside a Unix library.
 >>
 >> ... only to be used with wine!
 >>
 >> IMO this sentence should be changed, since it can be misinterpreted
 >> (well, at least I did). It should be added what you've said: a Unix
 >> library in format not in content.
 >>
 > Oh, come on!  I can misinterpret anything.

That is very true. :)




Thank you so much.

Best regards,
Paulo