DISPLAY problems
Nix N. Nix
displaying stuff on remote displays. Yet, I kept running into the
followings:
Intro:
The machine running wine and containing the Windows program I want to
run is called tux.
The machine I'm ssh-ing/telnet-ing in from is called deimos.
The program I'm trying to run is notepad.exe.
Case 1:
tux is in runlevel 5, at the [x,k,g]dm screen:
Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
err:seh:UnhandledExceptionFilter Couldn't start debugger
(debugger/winedbg 134624496 32) (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
addr 0x400cf26c
Case 2:
tux is in runlevel 3:
err:seh:UnhandledExceptionFilter Couldn't start debugger
(debugger/winedbg 134624496 32) (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
addr 0x400cf26c
Case 3:
tux is in runlevel 5, I walk over to it and log in via X.
err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for
printer 'lp'
fixme:winspool:AddPrinterW DocumentProperties fails
err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for
printer 'lp'
err:winspool:AddPrinterW DocumentPropertiesW failed!
err:winspool:PRINTCAP_ParseEntry lp not added by AddPrinterA (1797)
fixme:edit:EDIT_EM_FmtLines soft break enabled, not implemented
In Case 3, notepad ran.
This leaves me with only one conclusion:
In order to run any wine app via ssh or telnet from deimos, I must walk
over to tux and log in. This sucks, because it defeats the purpose of X.
The things I've done so far are these:
- I made sure no wine-related process was running when I ran notepad.
- I removed the entire config directory (save ~/.wine/config)
Neither helped.
Can you please help me ?
Thanks,
Gabriel
Andreas Mohr Usenet 06/01
> Many people have told me many times that wine doesn't have any problems
> displaying stuff on remote displays. Yet, I kept running into the
> followings:
> Intro:
> The machine running wine and containing the Windows program I want to
> run is called tux.
> The machine I'm ssh-ing/telnet-ing in from is called deimos.
> The program I'm trying to run is notepad.exe.
> Case 1:
> tux is in runlevel 5, at the [x,k,g]dm screen:
> Xlib: connection to ":0.0" refused by server
> Xlib: Client is not authorized to connect to Server
> Xlib: connection to ":0.0" refused by server
> Xlib: Client is not authorized to connect to Server
> err:seh:UnhandledExceptionFilter Couldn't start debugger
> (debugger/winedbg 134624496 32) (2)
> Read the Wine Developers Guide on how to set up winedbg or another debugger
> err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
> addr 0x400cf26c
man xauth
No, I won't tell you the simple, INSECURE fix ;-)
> Case 2:
> tux is in runlevel 3:
> err:seh:UnhandledExceptionFilter Couldn't start debugger
> (debugger/winedbg 134624496 32) (2)
> Read the Wine Developers Guide on how to set up winedbg or another debugger
> err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
> addr 0x400cf26c
> Case 3:
> tux is in runlevel 5, I walk over to it and log in via X.
> err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for
> printer 'lp'
> fixme:winspool:AddPrinterW DocumentProperties fails
> err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for
> printer 'lp'
> err:winspool:AddPrinterW DocumentPropertiesW failed!
> err:winspool:PRINTCAP_ParseEntry lp not added by AddPrinterA (1797)
> fixme:edit:EDIT_EM_FmtLines soft break enabled, not implemented
> In Case 3, notepad ran.
> This leaves me with only one conclusion:
> In order to run any wine app via ssh or telnet from deimos, I must walk
> over to tux and log in. This sucks, because it defeats the purpose of X.
No way.
I never have to do this in order to use Wine remotely.
> The things I've done so far are these:
> - I made sure no wine-related process was running when I ran notepad.
> - I removed the entire config directory (save ~/.wine/config)
> Neither helped.
> Can you please help me ?
The second case is a mysterious one, since there's no access stuff blocking
execution.
Could you please stop talking about "runlevels" and instead tell me what
exactly the different setup in these runlevels is ?
I'm afraid I can't really help here :-\
It always worked for me so far whenever I tried it:
ssh -luser foreign_host
export DISPLAY=myhost:0
wine XXX
(well, yeah, and make sure that myhost actually allows display from
foreign_host)
Are you *sure* that this is a Wine problem at all ??
Try running e.g. xterm or xeyes remotely, and I bet you'll soon see
that the whole problem has nothing to do with Wine.
--
Andreas Mohr, Renningen, Germany
In case you need to contact me after expiry of temporary email address:
my real address is (initial of first name).(last name)@mailto.de
Jeremy
"Andreas Mohr Usenet 06/01" <p4hi...@sneakemail.com> wrote in message
news:9g79jc$is9$1...@news.BelWue.DE...
>
> It always worked for me so far whenever I tried it:
> ssh -luser foreign_host
> export DISPLAY=myhost:0
> wine XXX
>
I've just tried this from cygwin to my RH host using Hoblink as my local X
server. I get the message
wine: warning: $DISPLAY variable ignored, using ':0'
It seems like wine doesn't want to display on a remote system. Why is this
so? How do I stop this behaviour ?
(I can display normally using programs like xterm so it is not a
communications issue)
Jeremy
Andreas Mohr Usenet 06/01
> "Andreas Mohr Usenet 06/01" <p4hi...@sneakemail.com> wrote in message
> news:9g79jc$is9$1...@news.BelWue.DE...
>>
>> It always worked for me so far whenever I tried it:
>> ssh -luser foreign_host
>> export DISPLAY=myhost:0
>> wine XXX
>>
> I've just tried this from cygwin to my RH host using Hoblink as my local X
> server. I get the message
> wine: warning: $DISPLAY variable ignored, using ':0'
> It seems like wine doesn't want to display on a remote system. Why is this
> so? How do I stop this behaviour ?
Because your Wine version is way too old ;-)
(with a newer version, you wouldn't even have asked that question at all)
> (I can display normally using programs like xterm so it is not a
> communications issue)
No, it's not. Upgrade to the latest release and you'll see.
Solution: display is configured in the wine config file instead.
Remove it or adapt it.
Lee Allen
>Many people have told me many times that wine doesn't have any problems
>displaying stuff on remote displays. Yet, I kept running into the
>followings:
>
>Intro:
>The machine running wine and containing the Windows program I want to
>run is called tux.
>The machine I'm ssh-ing/telnet-ing in from is called deimos.
>The program I'm trying to run is notepad.exe.
(SNIP)
You don't say whether you're running an X server on deimos. That's
required. Before you start wine, set envvar DISPLAY to the address of
the X server (eg, "deimos:0.0").
If you ARE running an X server on deimos, make sure it is configured
to allow connections from tux.
-Lee Allen
Jeremy
> Because your Wine version is way too old ;-)
> (with a newer version, you wouldn't even have asked that question at all)
>
I'm using wine 20010305. Surely it doesn't change *that* fast ? Even if it
does I suspect that people have run wine in remote mode before that date.
Jeremy
Lee Allen
wrote:
wine used to accept something like:
wine --display myhost:0.0
but now (at least in my experience using wine-20010510) you must
export DISPLAY=myhost:0.0
wine
And... note the :0.0, vs the :0 in the above post.
-Lee Allen
Andreas Mohr Usenet 06/01
Yes it does.
We do say that Wine is a development version, don't we ?
(well, I was slightly wrong with "way too old" - let it be "too old" instead)
And I'm rather sure that the current version works, too.
(besides 20010305)
Duane Clark
>
> "Andreas Mohr Usenet 06/01" <p4hi...@sneakemail.com> wrote in message
> news:9g79jc$is9$1...@news.BelWue.DE...
> >
> > It always worked for me so far whenever I tried it:
> > ssh -luser foreign_host
> > export DISPLAY=myhost:0
> > wine XXX
> >
SSH should already have set the display variable correctly for X11
"forwarding". By changing it to myhost:0, you are no longer taking
advantage of this security feature, but are instead making everything
you do visible to snooping. As long as your network is reasonably
secure, that is of course not a big deal, and definitely improves
performance. But if the network connection and computers are reasonably
fast, the X performance of the forwarded connection is quite reasonable.
And that goes for wine programs, too.
>
> I've just tried this from cygwin to my RH host using Hoblink as my local X
> server. I get the message
>
> wine: warning: $DISPLAY variable ignored, using ':0'
>
> It seems like wine doesn't want to display on a remote system. Why is this
> so? How do I stop this behaviour ?
In the past, the wineserver was only capable of handling a single
display. So if the server was running a wine program on the local
display (which is what the message indicates), the only way to send
something to the remote display was to kill off the wine programs, make
sure the wineserver was also dead (ps -ef | grep wine), and then rerun
the program remotely. It should now work fine. This may now have changed
due to substantial work recently in the X stuff in wine, which I think
is what Andreas is referring to. I personally am waiting for the changes
to stabilize a bit more before trying it out:-)
>
> (I can display normally using programs like xterm so it is not a
> communications issue)
Yep. It is (was) purely a wineserver issue.
Duane
Nix N. Nix
Lee Allen wrote:
> On Wed, 13 Jun 2001 08:34:03 GMT, "Nix N. Nix" <n...@go-nix.ca> wrote:
>
>
>> Many people have told me many times that wine doesn't have any problems
>> displaying stuff on remote displays. Yet, I kept running into the
>> followings:
>>
>> Intro:
>> The machine running wine and containing the Windows program I want to
>> run is called tux.
>> The machine I'm ssh-ing/telnet-ing in from is called deimos.
>> The program I'm trying to run is notepad.exe.
>
>
> (SNIP)
>
> You don't say whether you're running an X server on deimos. That's
Yes, on deimos I'm running X and I'm SSH-ed into tux. This means that I
don't need to do 'xhost +' on deimos, because ssh forwards connections
so that the X server on deimos thinks it's the local ssh process
connecting and not a remote socket.
Nix N. Nix
Andreas Mohr Usenet 06/01 wrote:
> Nix N. Nix <n...@go-nix.ca> wrote:
>
>> Many people have told me many times that wine doesn't have any problems
>> displaying stuff on remote displays. Yet, I kept running into the
>> followings:
>
>
>> Intro:
>> The machine running wine and containing the Windows program I want to
>> run is called tux.
>> The machine I'm ssh-ing/telnet-ing in from is called deimos.
>> The program I'm trying to run is notepad.exe.
>
>
>> Case 1:
>> tux is in runlevel 5, at the [x,k,g]dm screen:
>
>
>> Xlib: connection to ":0.0" refused by server
>> Xlib: Client is not authorized to connect to Server
>> Xlib: connection to ":0.0" refused by server
>> Xlib: Client is not authorized to connect to Server
>> err:seh:UnhandledExceptionFilter Couldn't start debugger
>> (debugger/winedbg 134624496 32) (2)
>> Read the Wine Developers Guide on how to set up winedbg or another debugger
>> err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
>> addr 0x400cf26c
>
> man xauth
> No, I won't tell you the simple, INSECURE fix ;-)
U mean 'xhost +' on tux ? Nono ... I /refuse/ to do /that/ :o)
Plus, if I use SSH, there should be no auth problems, because SSH
tunnels X11 connections. This means the following:
sshd on tux starts an X server to which all clients running on my tux
session connect. sshd then encrypts the sockets and forwards them to
the ssh client running on deimos. The ssh client decrypts and pretends
to the X server on deimos to be a local socket. Thus, there should be
no auth problems. xclock and so forth run fine.
Runlevel 3: X and [k,g,x]dm is not running on tux
Runlevel 5: X and [K,g,x]dm are both running on tux
>
> I'm afraid I can't really help here :-\
>
> It always worked for me so far whenever I tried it:
> ssh -luser foreign_host
> export DISPLAY=myhost:0
If you use SSH you shouldn't set the DISPLAY manually because then you forfeit the
benefits of encrypted X connection tunneling, but that's currently beside the point.
> wine XXX
>
> (well, yeah, and make sure that myhost actually allows display from
> foreign_host)
>
> Are you *sure* that this is a Wine problem at all ??
> Try running e.g. xterm or xeyes remotely, and I bet you'll soon see
> that the whole problem has nothing to do with Wine.
I did run all kinds of X apps over SSH and even over telnet (after, of
course, doing 'xhost +' on deimos, to allow incoming connections -
something I don't like doing).
Nix N. Nix
which to get wine to display remotely (on deimos), unless security is
turned off on the server (tux) ? Keep in mind:
On tux:
- I am /not/ logged in via [x,g,k]dm
- X and [x,g,k]dm are running
On deimos:
- I am logged into tux via ssh (=> X tunneling => DISPLAY set correctly)
- xclock et al. show themselves on deimos when running on tux (i.e.
all's well, except for wine)
BTW: wine version 20010510
It seems strange to me that, in the case of wine, it is a prerequisite
to be able to connect to :0.0 (event if $DISPLAY is set otherwise - may
imply a hardcoded ":0.0" somewhere, but I'm no expert), before
attempting to connect to $DISPLAY. At least, that's what it looks like.
What if I wanted to install wine on a machine that doesn't have X and
[k,g,x]dm ? If I did that, it would mean that I could /only/
run stuff over the net, right ? But if wine requires a local X socket
before it can connect to the remote DISPLAY, then it will be futile to
try to run anything via wine off this hypothetical machine.
Gabriel
Duane Clark
>
> Alright. Can I conclude from our discussion that there is no way in
> which to get wine to display remotely (on deimos), unless security is
> turned off on the server (tux) ?
Security on the server? Not sure what you mean. If you were to run
"xhost +" or even "xhost tux", you would run it on deimos, not tux. Wine
works fine over the encrypted SSH link, without running xhost. And
having just tried it out, I see that at least with wine-20010528, the
wineserver will simultaneously run programs both locally and remotely
over the encrypted link just fine. Excellent, I had not realized that
was working already:-)
Since I don't know when that was changed, I see two possibilities. First
make sure that that the wineserver is not running on tux (kill it if it
is). Then log into tux remotely via SSH, and try again. Or try a newer
version of wine. Though you might not want the newest one, as that seems
to currently be a bit unstable. I have had no significant problems with
CVS from 20010528.
Duane
Duane Clark
>
> Security on the server? Not sure what you mean. If you were to run
> "xhost +" or even "xhost tux", you would run it on deimos, not tux.
Never mind that part. That darn X. Of course, deimos is running the
server.
But wine does work fine for me remotely over the SSH encrypted link
without issuing any xhost commands on the server.
Duane
François Gouget
>
> Alright. Can I conclude from our discussion that there is no way in
> which to get wine to display remotely (on deimos), unless security is
> turned off on the server (tux) ?
No, you may not. Running Wine applications remotely with the display
going through an ssh tunnel works just fine (playing winmine over an
encrypted ssh from a machine that does not run xdm or X). And I've been
using it for almost a year and have never seen it fail.
Things you should check:
- check $DISPLAY anyway. Sometimes one has a .profile that resets it at
the wrong time. Also X forwarding may not be enabled (check the client
and server configuration files, try 'ssh -X')
- do a 'grep Display ~/.wine/config'. That line should be commented
out.
--
François Gouget
fgo...@codeweavers.com
Nix N. Nix
Duane Clark wrote:
> Duane Clark had a brain fart:
>
>> Security on the server? Not sure what you mean. If you were to run
>> "xhost +" or even "xhost tux", you would run it on deimos, not tux.
Nono. You got it right the first time ! This is the paradox I don't
understand. In order to display something on deimos, I have to run
xhost + on tux ?!
It seems that, at some point during wine's initialization, it makes a
connection to :0.0 (no matter what $DISPLAY is set to) and, if it fails,
it doesn't even bother connecting to the real $DISPLAY. Once I run
xhost + on tux (!), usually in /etc/X11/xdm/Xsetup_0, wine works just
fine when I'm logged into tux via SSH. The incomprehensible problem is
this: Why does wine require access to :0.0, even though the DISPLAY is
set correctly. Plus, I know I don't have /any/ kind of authorization
problems, because all other X apps work flawlessly.
Nix N. Nix
François Gouget wrote:
> "Nix N. Nix" wrote:
>
>> Alright. Can I conclude from our discussion that there is no way in
>> which to get wine to display remotely (on deimos), unless security is
>> turned off on the server (tux) ?
>
>
> No, you may not. Running Wine applications remotely with the display
> going through an ssh tunnel works just fine (playing winmine over an
> encrypted ssh from a machine that does not run xdm or X). And I've been
> using it for almost a year and have never seen it fail.
>
> Things you should check:
> - check $DISPLAY anyway. Sometimes one has a .profile that resets it at
> the wrong time. Also X forwarding may not be enabled (check the client
> and server configuration files, try 'ssh -X')
Done. $DISPLAY is set to tux:10.0, as it should be.
In fact, I don't have a ~/.profile .
> - do a 'grep Display ~/.wine/config'. That line should be commented
> out.
Done. ~/.wine/config does not contain such a setting.
In fact, the news client I'm using to compose this message is running
over the very SSH session in question. Since I can see this window and
therefore type into this text box, thereby composing this message, the
basic X stuff (authorization, connection forwarding, etc.) must be
working properly. Yet, when I try running notepad, I get the same
"Xlib: connection to ":0.0" refused by server". Why is wine telling
Xlib to connect to :0.0, when the DISPLAY is clearly tux:10.0 ?
Does wine perhaps not receive the env as it should ?
Does wine wipe the DISPLAY variable it receives ?
I cannot believe either of the above since, if I restart [x,g,k]dm on
tux with 'xhost +' in /etc/X11/xdm/Xsetup_0 of tux (!), it does, in
fact, display properly on deimos.
On a side note: Can any of you tell me /where/ exactly wine opens an X
Display ? By "where" I mean which file and which line. I'd like to
stick a printf in there dumping the DISPLAY string to the terminal. I
tried this once, but I'm not the expert, and it looked to me like there
was a wrapper around the function that does the actual opening. Hmmm,
man XOpenDisplay says that if its parameter is NULL, it defaults to
$DISPLAY. Now, if XOpenDisplay is being called from, say, a sub-process
which does not benefit from the environment of its parent, would it not
try to open ":0.0" ? I'm just guessing around here. I'll try to delve
into the source, but I'm not too good at it.
Gabriel
Andreas Mohr Usenet 06/01
> Duane Clark wrote:
>> Duane Clark had a brain fart:
>>
>>> Security on the server? Not sure what you mean. If you were to run
>>> "xhost +" or even "xhost tux", you would run it on deimos, not tux.
> Nono. You got it right the first time ! This is the paradox I don't
> understand. In order to display something on deimos, I have to run
> xhost + on tux ?!
> It seems that, at some point during wine's initialization, it makes a
> connection to :0.0 (no matter what $DISPLAY is set to) and, if it fails,
> it doesn't even bother connecting to the real $DISPLAY. Once I run
> xhost + on tux (!), usually in /etc/X11/xdm/Xsetup_0, wine works just
> fine when I'm logged into tux via SSH. The incomprehensible problem is
> this: Why does wine require access to :0.0, even though the DISPLAY is
> set correctly. Plus, I know I don't have /any/ kind of authorization
> problems, because all other X apps work flawlessly.
I'm pretty damn sure you have an incorrect display setting in your
wine config file.
That's why I said you should upgrade Wine, since it changed the error message
from
wine: Warning: $DISPLAY variable ignored, using '%s'
to
x11drv: Warning: $DISPLAY variable ignored, using '%s' specified in config file
Nix N. Nix
Andreas Mohr Usenet 06/01 wrote:
> Nix N. Nix <n...@go-nix.ca> wrote:
>
>
>
>> Duane Clark wrote:
>
>
>>> Duane Clark had a brain fart:
>>>
>>>
>>>> Security on the server? Not sure what you mean. If you were to run
>>>> "xhost +" or even "xhost tux", you would run it on deimos, not tux.
>>>
>
>> Nono. You got it right the first time ! This is the paradox I don't
>> understand. In order to display something on deimos, I have to run
>> xhost + on tux ?!
>> It seems that, at some point during wine's initialization, it makes a
>> connection to :0.0 (no matter what $DISPLAY is set to) and, if it fails,
>> it doesn't even bother connecting to the real $DISPLAY. Once I run
>> xhost + on tux (!), usually in /etc/X11/xdm/Xsetup_0, wine works just
>> fine when I'm logged into tux via SSH. The incomprehensible problem is
>> this: Why does wine require access to :0.0, even though the DISPLAY is
>> set correctly. Plus, I know I don't have /any/ kind of authorization
>> problems, because all other X apps work flawlessly.
>
> I'm pretty damn sure you have an incorrect display setting in your
> wine config file.
> That's why I said you should upgrade Wine, since it changed the error message
> from
> wine: Warning: $DISPLAY variable ignored, using '%s'
> to
> x11drv: Warning: $DISPLAY variable ignored, using '%s' specified in config file
a) I have mentioned in my initial post what the error messages were.
None of the lines output by wine included either of the above messages.
Please refer to my original post.
b) I have included my ~/.wine/config file for reference. It does not
have "Display" = "something" in it.
I really don't understand what the problem is. All X apps work just
fine, only wine, for some reason, tries to open ":0.0", even though
there's no mention of it in config or $DISPLAY ... weird ...
Gabriel
Michael Mauch
I'm not sure if that's related to your problem, but seems to be a
problem with the DISPLAY variable: it is not always passed down to
process_attach() and x11drv_thread_data() in x11drv_main.c, so the
TSXOpenDisplay(NULL) and XOpenDisplay(NULL) fail and the
XDisplayName(NULL) prints an empty string.
If I define the "display" in [x11drv], it says:
x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file
But if I don't set it in the config, it is not passed down to
process_attach() and x11drv_thread_data(). These functions are called
when I try to run a program from within another program.
This is on a standalone machine with DISPLAY=localhost:0.0 (or :0.0),
Wine from CVS (yesterday).
Regards...
Michael
Nix N. Nix
Michael Mauch wrote:
I have traced ts_xlib.c and I added a debugging code to the following
effect:
Display * TSXOpenDisplay(const char* a0)
{
Display * r;
wine_tsx11_lock();
if (NULL == a0)
printf ("a0 is NULL, so X will open $DISPLAY==|%s|\n", getenv
("DISPLAY")) ;
else
printf ("X will open a0: |%s|\n", a0) ;
r = XOpenDisplay(a0);
wine_tsx11_unlock();
return r;
}
Now, when I try to run wine remotely (from deimos), and it works
successfully (i.e. I had already walked over to tux and logged in via
[x,k,g]dm) the above code outputs "X will open a0: |tux:10.0|". This
means that the display is passed down correctly - or is it ?
When it doesn't work (i.e. I had /not/ walked over to tux and logged in
via [x,k,g]dm), weirdly enough, it says "Xlib: connection refused..."
before it ever gets to the line above. Once the connection refused
message is printed, it never gets to the above function. This leads me
to conclude that /somewhere/ in the code, other than the above
function,a XOpenDisplay is taking place. Maybe when the wine server
starts ?
Gabriel
gerard patel
<snip>
>to conclude that /somewhere/ in the code, other than the above
>function,a XOpenDisplay is taking place. Maybe when the wine server
>starts ?
[gerard@duron wine]$ cat ~/bat/search
find . -iname *.c -type f -print | xargs egrep -i $1
[gerard@duron wine]$ search xopendisplay
./windows/x11drv/wineclipsrv.c: if (
(g_display=XOpenDisplay(display_name)) == NULL )
./dlls/x11drv/x11drv_main.c: if (!(display = TSXOpenDisplay( NULL
)))
./dlls/x11drv/x11drv_main.c: if (!(data->display =
XOpenDisplay(NULL)))
./tsx11/ts_xlib.c:Display * TSXOpenDisplay(const char* a0)
./tsx11/ts_xlib.c: r = XOpenDisplay(a0);
[gerard@duron wine]$
And could you edit a bit the posts you reply to ? Thanks.
Gerard
Nix N. Nix
The following files are affected:
../dlls/x11drv/x11drv_main.c
../tsx11/ts_xlib.c
../windows/x11drv/wineclipsrv.c
x11drv_main.c uses TSXOpenDisplay from ts_xlib.c, so it can be
discounted. ts_xlib.c is where I added the code, so we know it works
properly. I modified wineclipsrv.c, but none of the messages showed up
when I ran notepad again.
/HOWEVER/ (emphasis only)
I re-compiled the whole thing using gcc-3.0 and now it /seems/, I
repeat, it /seems/ to work. Since the compiler in RH7.0 is notoriously
buggy (kernel fails to compile, etc.), I am eager to attribute this
error to the compiler, rather than to wine. I /could/ be mistaken,
though, and I will post to that effect if it turns out that I am.
Thanks for all the help so far, everybody.
Gabriel
Nix N. Nix
was happening during the process of the
LoadLibrary-ing of x11drv. The reason this was happening is that x11drv was loading
OpenGL (libGL.so, etc.). Since I have a NVidia
on tux, I was running NVIDIA GLX. The bug was with that. The hardcoded opening of
:0.0 (despite $DISPLAY set otherwise) was
happening somewhere in the deep, dark recesses of libGL.so. I upgraded GLX (and
NVdriver) to 1.0-1251 and all was well. Wow ! What an experience ! I traced the
execution of wine from the initial main() to the BUILTIN32_LoadLibraryExA and all
the way to the dlopen () of libx11drv.so ... wine is a very nice piece of work,
Ladies and Gentlemen !
Thanks for all the help,
Gabriel