so library with winelib

pvshura · Post by **pvshura** » Thu Apr 12, 2012 3:49 pm

Hi everybody!

I am new with wine and very sorry for my question.
Is it possible to create standard linux so library which would call Win32API functions?

Thank you,
Alexander.

vitamin · Post by **vitamin** » Thu Apr 12, 2012 9:09 pm

pvshura wrote:Is it possible to create standard linux so library which would call Win32API functions?

Yes, but you have to run it under Wine. You can not create standalone winelib applications. They will still require full Wine.

pvshura · Post by **pvshura** » Thu Apr 12, 2012 11:41 pm

Documentation says I am able to skip wine loader, is it true?

http://www.winehq.org/site/docs/winedev-guide/c2726

"wine_init() can, with the correct preparation, be called from programs other than the wine loader itself"

Does it mean I may call wine libraries from standalone Linux process?

Thank you.

vitamin · Post by **vitamin** » Fri Apr 13, 2012 11:05 pm

pvshura wrote:Documentation says I am able to skip wine loader, is it true?

That documentation is old and many things are not true anymore.

pvshura wrote:Does it mean I may call wine libraries from standalone Linux process?

I've already gave you the answer: No, you can not.

Wine is not just a set of libraries. Wine requires a particular environment to run. One of the major parts of that is wineserver. Most/all parts of Wine will fail without being able to talk to the wineserver.

pvshura · Post by **pvshura** » Sat Apr 14, 2012 12:38 am

I understand that wineserver should be started first. Imagine you started it and after that use your own process instead of wine loader.

vitamin · Post by **vitamin** » Sun Apr 15, 2012 7:06 pm

pvshura wrote:I understand that wineserver should be started first. Imagine you started it and after that use your own process instead of wine loader.

What is that you don't like so much about wine-loader that you absolutely can't use it?

Don't forget that wineserver is only a part of the picture. Everything else living in it's own process(es) & address space(es). You can't just load wine's dll.so and expect it to just magically start working. It needs more dlls, which in turn will need more. After you said and done you'll end up with most core Wine dlls loaded. And for that to work properly address space have to be correctly setup, which is the main function of the wine-loader, among few others.

pvshura · Post by **pvshura** » Mon Apr 16, 2012 10:12 pm

I have the same problem as some other people on wine forums. We run java + windows dlls on Windows platform and want to switch to Linux.

As far as I understand Wine was initially designed to run Windows applications on Linux but nobody considered it as a Windows API provider for application components. That makes Wine useless for people who wants to migrate to Linux. Wine becomes a toy, thing for itself because it's closed for the world and especially for the people who wants to migrate or have their applications working under both platforms.

Running java.exe under wine probably would work but it's overkill and makes any Linux transition meaningless.

Say we recompile our application with Wine but we still have problem with Wine loader. Since we have server application we use a relatively small part of Windows API - no user interface, no windows messages etc. Therefore we may try to compile only required part of Wine libraries from sources to avoid wine loader at all.

The simplest approach is to avoid recompilation (use windows built binaries) and emulate wine loader functionality if it's still possible.

Martin Gregorie · Post by **Martin Gregorie** » Tue Apr 17, 2012 4:54 am

On Mon, 2012-04-16 at 22:12 -0500, pvshura wrote:

I have the same problem as some other people on wine forums. We run
java + windows dlls on Windows platform and want to switch to Linux.

With respect, I think you're looking at this backwards. Your real
problem is that you've got a Java program that's been locked to Windows
by the inclusion of Windows-specific non-Java code, probably via JNI.

The only long-term solution is to run Java natively under Linux, which
means replacing the Windows-specific code by its Linux equivalent but,
if your application isn't written in Java 6, you should first check
whether this functionality is now included in the Java standard class
library. Java is, in general, forward compatible, so programs written
for an early Java version should run unchanged[*] when they are
recompiled with a current version.

[*] from Java 5, which introduced generics, some classes which took
Object arguments, e.g. Vector, will throw compile-time warnings because
they now use generics for improved compile-time type checks. Code using
them will still compile and run if left unmodified.

Martin