Different X Displays and Wine
boaz at hishome.net
Wed Aug 11 07:35:48 CDT 2004
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
What about the todo page is that on the todo for 1.0? Is it on any
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:
 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
(something like> ln -s .wine .wine$DISPLAY ;WINEPREFIX=.wine$DISPLAY
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.
 If yes for 1 would the Linux Kernel share my code segments across
wineservers? (Probably yes).
 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.
 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)
 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?
More information about the wine-devel