Different X Displays and Wine

[Boaz Harrosh]

I'm trying to connect and run a remote X session from 2 different 
machines and I fail to run Wine applications.
- I connect from Machine M1 using ssh -X (or -Y) run a wine app all is 
very well.
- I connect from another Machine M2 using ssh -X using the same user.  
The second instance fails with:
<message>
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  15 (X_QueryTree)
  Resource id in failed request:  0xa0002b
  Serial number of failed request:  137
  Current serial number in output stream:  137
</message>

Needless to say that if I exit the Wine application on M1 than M2 will 
run with out any problems.

[Q] Is it at-all possible to run Wine on 2 different $DISPLAY s, or is 
the X-Server a Wine-Server resource. Will using a different user help? 
Will using desktop mode help? Has any one been successful with letting 
different network users connect and run Windows Apps under wine? How did 
they Setup wine? How does Codeweavers do it with their Server Product?

Thanks in advance for any help (or failure reports) any one can give me.

Free Life
Boaz

[Alexandre Julliard]

Boaz Harrosh  writes:
> [Q] Is it at-all possible to run Wine on 2 different $DISPLAY s, or is
> the X-Server a Wine-Server resource. Will using a different user help?
> Will using desktop mode help? Has any one been successful with letting
> different network users connect and run Windows Apps under wine? How
> did they Setup wine? How does Codeweavers do it with their Server
> Product?

That's not supported at the moment. You can run apps on two different
displays by using a different WINEPREFIX for each, so that they don't
share the same wineserver. Using different users would work too.

[Boaz Harrosh]

Alexandre Julliard wrote:
> That's not supported at the moment. You can run apps on two different
> displays by using a different WINEPREFIX for each, so that they don't
> share the same wineserver. Using different users would work too.

Since I started to research this I was terrified this would be the answer.

I Thinks It should be stated, in bold letters, at the beginning of the 
user guide. I kind of have my neck on the line here. The reason I was 
contracted for this job was so we can run 100s of users off of a modest 
Linux Server room. With cheap x-terminals and old Win98 machines running 
an X-Server.
  What about the todo page is that on the todo for 1.0? Is it on any 
todo List?

Back to business: What you are saying is that I need to run a separate 
wineserver instance for each different $DISPLAY I want to support. This 
can only be done with WINEPREFIX or with a different user. Now, I need 
this to have the minimum Impact on the server so I have some questions 
if any one can help me I will most appreciate it:

[1] Can I Just "ln -s" the .wine folder and than point WINEPREFIX to the 
new link so a new wineserver Instance will be lunched? Or do I need a 
separate copy.
(something like> ln -s .wine .wine$DISPLAY ;WINEPREFIX=.wine$DISPLAY 
wine ...)
OK, I tried, this does not work! what does work is (# mkdir 
.wine$DISPLAY ;ln -s .wine/*  .wine$DISPLAY/) have a real directory with 
every thing there linked to the real thing.

[2] If yes for 1 would the Linux Kernel share my code segments across 
wineservers? (Probably yes).

[3] When is the $DISPLAY sampled by the wineserver. On first application 
startup, on first window created, or on server load? If I make the 
wineserver stay in memory (-p) will it re sample the $DISPLAY when a new 
app is started after all the old ones exit.

[4] Can I pre-run a wineserver and than on connection point wine to use 
a specific (next) wineserver Instance? IF not will it be hard to 
implement and will it be accepted into the tree? If yes and it is 
accepted can it be made automatic when ever $DISPLAY is changed 
(different). (Instead of bailing out a few moments later)

[5] How much effort is it to Implement such a support? Where do I start? 
Did any one have any thoughts on how this should be implemented? I was 
always in the notion that the x11drv was an In-process implementation 
creating a relationship between the wine-process and the x subsystem it 
is running under, only registering information under the server. Proof 
of that, I thought, was the current lack of cross process windowing. 
Well I was wrong. What is the basic flaw in Windows API that prevents it?

[(DWORD)-1] What does Codweavers do on their Server product. How do they 
server concurrent Office users?

Free Life
Boaz

[Alexandre Julliard]

Boaz Harrosh  writes:
> [1] Can I Just "ln -s" the .wine folder and than point WINEPREFIX to
> the new link so a new wineserver Instance will be lunched? Or do I
> need a separate copy.
> (something like> ln -s .wine .wine$DISPLAY ;WINEPREFIX=.wine$DISPLAY
> wine ...)
> OK, I tried, this does not work! what does work is (# mkdir
> .wine$DISPLAY ;ln -s .wine/*  .wine$DISPLAY/) have a real directory
> with every thing there linked to the real thing.

You need a full copy with different registry files, you can't use
symlinks.
> [2] If yes for 1 would the Linux Kernel share my code segments across
> wineservers? (Probably yes).

Of course.
> [3] When is the $DISPLAY sampled by the wineserver. On first
> application startup, on first window created, or on server load? If I
> make the wineserver stay in memory (-p) will it re sample the $DISPLAY
> when a new app is started after all the old ones exit.

wineserver doesn't care about $DISPLAY at all. If you mean $WINEPREFIX
it is evaluated at server startup.
> [4] Can I pre-run a wineserver and than on connection point wine to
> use a specific (next) wineserver Instance? IF not will it be hard to
> implement and will it be accepted into the tree? If yes and it is
> accepted can it be made automatic when ever $DISPLAY is changed
> (different). (Instead of bailing out a few moments later)

I don't see how you would do that. The right fix is to make the
windowing code support windows created on different displays.
> [(DWORD)-1] What does Codweavers do on their Server product. How do
> they server concurrent Office users?

We don't support having the same user run from different displays at
the same time. I don't think that's a common setup at all.