Winlib, winebuild and linux shared libraries questions

whitnl73 at whitnl73 at
Mon Apr 7 14:24:16 CDT 2003

On Mon, 7 Apr 2003, Paulo de Carvalho wrote:

> 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 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?

I am sorry, I still don't have any idea what you are trying to do,
probably because I don't have any clear idea what Java Native Intrerface
>  >> You already said I can't use the library <> 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

Oops.  winelib dll or native windows 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.

In effect, all of winelib is ported Windows dlls.
I thought you had dll's with no source, and programs with.  That is
exactly what winemaker is for.
> 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.

Sorry, I still don't see why not.  There is a kernel option
(CONFIG_BINFMT_MISC) that you might like for java and/or winelib
executables.  lots of nice doco in <linux>/Documentation/ and binfmt_misc.txt

> 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.
Hmmm.  You have a linux JVM...

> 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).
I guess so.  Mind I've never tried anything like this.
> Thank you so much.
> Best regards,
> Paulo


Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!

More information about the wine-users mailing list