[Wine] Java on host and wineprefix questions

[Raif S. Berent]

Is it possible to use java from host from within wine? The obvious
answer is no - must install the windows version. However, I am
wondering whether a symlink to the hos java folder (or similar trick)
would work, considering that jva is a VM. I mean, does java really
care what environment the request came from?

Second question is re WINEPREFIX, and whether such a setup is
possible: Let's assume I have dotnet40 and all dependents installed in
.wine-dotnet. Let's then try to install some dotnet dependent software
in a separate prefix so as not to contaminate our working dotnet pool.
Set the prefix as .wine-someapps and link the dotnet dependencies to
the first prefix, install as normal - any additions go into the second
prefix.

Answer to both questions will probably be NO, but I'll ask anyway.

Regards.

[Martin Gregorie]

Post by Raif S. Berent
Is it possible to use java from host from within wine? The obvious
answer is no - must install the windows version. However, I am
wondering whether a symlink to the hos java folder (or similar trick)
would work, considering that jva is a VM. I mean, does java really
care what environment the request came from?

That depends on whether the application is calling native code, i.e.
code accessed via JNI. Obviously native code modules are not written to
be OS-independent. You might get lucky, but I wouldn't hold my breath
because much JNI code is written to access ABIs or libraries (DLLs) that
the JVM doesn't allow access to.

100% Java applications should work under any JRE because thats the WORA
promise. I use one or two graphical Java apps under Linux that were
almost certainly designed to work on a Windows box judging by the targer
audience. They work really well. Bottom line: if you know that the
application is 100% Java, why bother with WINE at all? If you know its
not, then using the Windows JRE is almost certainly necessary. If it
depends on BAT or CMD files to launch, you should be able to rewrite
them as bash scripts.

However, if the app uses JNI modules can you be certain that they are
either entirely self-contained or only call WINE-supported ABIs?

Don't forget that there are half-way houses too: 100% Java client
applications that talk to local Windows-only servers, e.g. a DBMS with
no Linux port. In that case you might run the server under WINE but use
the Linux JRE for the client.

Post by Raif S. Berent
Second question is re WINEPREFIX, and whether such a setup is
possible: Let's assume I have dotnet40 and all dependents installed in
.wine-dotnet. Let's then try to install some dotnet dependent software
in a separate prefix so as not to contaminate our working dotnet pool.
Set the prefix as .wine-someapps and link the dotnet dependencies to
the first prefix, install as normal - any additions go into the second
prefix.

Probably not. There's only one $WINEPREFIX per user logon and no defined
way to communicate between different copies of the directories that
$WINEPREFIX names unless you want to risk using symlinks to break the
WINE-imposed isolation.

There's no problem in having several separate directories pointed to by
$WINEPREFIX in the same user. I do it all the time. You only need a 3 or
4 line bash script to set $WINEPREFIX to point to the setup you want to
run and then run wine. I have the impression that the more recent WINE
releases are expecting a Linux box to have multiple WINE apps installed
in separate prefixes because they seem to share more WINE code between
prefixes.


Martin

[Martin Gregorie]

Post by Martin Gregorie
There's no problem in having several separate directories pointed to by
$WINEPREFIX in the same user. I do it all the time. You only need a 3 or
4 line bash script to set $WINEPREFIX to point to the setup you want to
run and then run wine. I have the impression that the more recent WINE
releases are expecting a Linux box to have multiple WINE apps installed
in separate prefixes because they seem to share more WINE code between
prefixes.

A lot of tools (eg winetricks and playonlinux) work by creating
separate wine prefixes for indivdual apps. It is indeed a common use
case, though I haven't throughly tested what happens when you run them
concurrently and spawn multiple wineservers.

I've just tried it, running two different programs, LK8000 and XCSoar,
which are both installed in their own prefix and both are graphical
navigation programs. Both are written to run on WinCE 5 PNAs but these
executables are versions that were compiled to run on a Win XP box so
their user can learn to use them at home.

Both programs ran simultaneously, which is what I expected.

Each program is launched from a bash script which sets the required
prefix and then starts Wine in it, so the dual run test was started with
the command:

lk8000& xcsoar

which starts lk8000 and detaches it from the main shell and then runs
xcsoar from the main shell. Each program uses a single window. As an
added twist, I ran this test from a Lenovo laptop running Fedora 20. It
was logged in to my house server, a dual core Athlon box running Fedora
18 and ran the programs on the server. The login was via an ssh session
with X11 forwarding enabled, so both programs opened their window on the
Lenovo and accepted mouse input from it.

FWIW both programs normally take all user input via the PNA's touch
sensitive screen. The PC versions accept mouse input instead.


Martin

[Scott Ritchie]

Post by Martin Gregorie
There's no problem in having several separate directories pointed to by
$WINEPREFIX in the same user. I do it all the time. You only need a 3 or
4 line bash script to set $WINEPREFIX to point to the setup you want to
run and then run wine. I have the impression that the more recent WINE
releases are expecting a Linux box to have multiple WINE apps installed
in separate prefixes because they seem to share more WINE code between
prefixes.

A lot of tools (eg winetricks and playonlinux) work by creating
separate wine prefixes for indivdual apps. It is indeed a common use
case, though I haven't throughly tested what happens when you run them
concurrently and spawn multiple wineservers.

[Raif S. Berent]

Thank you both for your answers. It seems I posted with my regular
email, rather than the alias under which I am registered on the list,
so I did not receive notice of your updates on the topic - hence my
delay.

I also see that I left out some important info re version, etc.
OS: FreeBSD_11-Current_amd64. Wine: 1.7.11,1.

if you know that the application is 100% Java, why bother with WINE at all? If you know its not, then using the Windows JRE is almost certainly necessary.

Yes excellent point. The app is not 100% java, it installs in windows,
and has java component, along with dotnet and probably other stuff.
For the dotnet bit I could try to run it through native mono, but the
"other stuff" section of the code would probably break the app.

Don't forget that there are half-way houses too: 100% Java client applications that talk to local Windows-only servers, e.g. a DBMS with no Linux port. In that case you might run the server under WINE but use the Linux JRE for the client.

This is most likely the case and the direction that I should further
test. How can your suggestion be implemented: "Run the app under wine,
but link to native JRE for java calls coming from the wineserver"?

A lot of tools (eg winetricks and playonlinux) work by creating separate wine prefixes for indivdual apps. It is indeed a common use case, though I haven't throughly tested what happens when you run them concurrently and spawn multiple wineservers.

That observation is what led me to ask the question. Multiple /
concurrent sessions are not a problem, you just get multiple
wineserver pid's showing up.

I'll just look through the winetricks code or ask their mail list re
this question. Your answers did help with confirming for me that I had
indeed perceived the winetricks approach to the problem correctly.

Thanks Again.

[Martin Gregorie]

Post by Raif S. Berent
Yes excellent point. The app is not 100% java, it installs in windows,
and has java component, along with dotnet and probably other stuff.
For the dotnet bit I could try to run it through native mono, but the
"other stuff" section of the code would probably break the app.

OK. You could try running it with native JRE and mono, but if you do, be
prepared for quite a lot of faffing round. The simple approach of
installing the Windows JRE and .net in the same prefix may be a lot
simpler. I'd suggest you try that first and only look at using the
native JRE and mono if it doesn't work.

Post by Raif S. Berent

Don't forget that there are half-way houses too: 100% Java client applications that talk to local Windows-only servers, e.g. a DBMS with no Linux port. In that case you might run the server under WINE but use the Linux JRE for the client.

This is most likely the case and the direction that I should further
test. How can your suggestion be implemented: "Run the app under wine,
but link to native JRE for java calls coming from the wineserver"?

The main issue with that sort of mixing is most likely to be the search
paths. Don't forget that, apart from the Z drive, each prefix is set up
to imitate a complete Windows filing system and that each prefix has its
own C: drive, which maps onto $WINEPREFIX/drive_c I may be wrong about
this, but the only way the app running in a prefix is meant to talk to
programs in other prefixes or to native applications is via sockets.

As for the other drives, all defined in $WINEPREFIX/dosdevices, Z: maps
onto /, so is potentially quite dangerous while in my system A: maps
onto a floppy drive, D: and E: map onto my optical drives and K: maps
onto a removable (USB) hard drive.

Post by Raif S. Berent
That observation is what led me to ask the question. Multiple /
concurrent sessions are not a problem, you just get multiple
wineserver pid's showing up.

If you saw my later posts you'll know that I have no need to run more
than one Wine app at a time. Unless I'm using a set of apps that came
from the same source and are designed to work together, I put them in
separate prefixes because that avoids potential problems with
incompatible DLLs.

However, I started up two unrelated programs installed in separate
prefixes and both ran just fine without interfering with each other.
They are graphical programs and played nicely with each other when it
came to sharing the mouse. Neither use the keyboard so I didn't tesyt
that.

Post by Raif S. Berent
I'll just look through the winetricks code or ask their mail list re
this question. Your answers did help with confirming for me that I had
indeed perceived the winetricks approach to the problem correctly.

Glad we were able to help.


Martin