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@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
_______________________________________________ wine-users mailing list wine-users@winehq.com http://www.winehq.com/mailman/listinfo/wine-users
