whitnl73@juno.com wrote:
(These little answers with common knowledge which is not written anywhere are invaluable pieces of information :) )Not a matter of allowed. .dll.so libraries don't export the windows functions as elf symbols, so you need winemaker to resolve them.
> What do you have against winelib?
Are you kidding?!? You must be joking! I have dreams at night with a world in which you don't need to have Windows to run some application. Wine and winelib are making my dreams come true. :)
Do you want to distribute something without dragging all of winelib
along? I guess yo can limit the winelib dll's you need, but remember
you will need wine (and at least the winelib dll's it links to
directly) ("ldd /usr/local/bin/wine")) to ...
I am aware of that. That's not the problem...
What is it you are trying to do?> This is getting too abstract for me.
Ok, you're right. I'm sorry.
What I really want is to use some proprietary 3rd party windows dlls in JAVA through JNI (Java Native Interface) and I want to do it using Linux. ( Gosh! How this sounds absurd! )
But suppose you would want to use those 3rd party libraries in Perl, or Python, or PHP, or something like that, on Linux, I believe you would also need some kind of extension mechanism based on libraries. If so, link-against-wine-libs-and-lauch-with-wine method wouldn't work, I guess.
I already made some sample applications that use those 3rd party dlls, ported them using winelib and they run fine under wine :))
But, as you've said, these applications have to be linked with wine libs and they need a wine command to be launched.
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.
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.
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...
"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 ?
... only to be used with wine!As it said in the snippet you quoted to start this, a wine dll is a win32 dll encapsulated inside a Unix library.
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.
Thank you!
Paulo
_______________________________________________
wine-users mailing list
wine-users@winehq.com
http://www.winehq.com/mailman/listinfo/wine-users
