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@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? 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 is. > > >> 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 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/ Configure.help 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 > > > Lawson -- ---oops--- ________________________________________________________________ Sign Up for Juno Platinum Internet Access Today Only $9.95 per month! Visit www.juno.com _______________________________________________ wine-users mailing list wine-users@winehq.com http://www.winehq.com/mailman/listinfo/wine-users
