X Windows display

Hello Folks,

Have X-Win 32 installed on my desktop.

Earlier when it used to be XP, ran the following commands on unix system:

export DISPLAY=<desktop ip>:0.0
xterm

Above used to work like charm

Now it got upgraded to Windows 7
Setting the display & triggering xterm doesn't work. It error's out saying:

Error: Can't open display: <desktop id>:0.0

Is there anything specific that needs to be done for Windows 7.
Advice please.

Update:
Just tried on a friend's system running Windows XP.
It worked perfect.

Thoughts what additional things do I need to do for Windows 7?

---------- Post updated at 02:45 PM ---------- Previous update was at 11:47 AM ----------

Had to enable X11 forwarding in putty.

Query:
Thoughts on why this X11 forwarding is required with Windows 7 & not earlier in XP?

It sounds like the Windows 7 firewall killed the x11 direct connections. You can test with telnet on other hosts, as 0.0 is port 6000: telnet desktop_id 6000 should connect. It may be windows firewall, or a Norton or Mcafee one, or both.

The putty makes it more secure, as the X goes through the putty SSH tunnel.

I prefer VNC for X, so the desktop is not on the PC, it is local to the apps, and you just run a vncviewer. You can run it through a tunnel, too: port 5900 supports remote 0:0 port 6000, 5901 for 6001, etc. You do not lose all X apps every time the PC is rebooted or network breaks.

Hmm, that will require some digging into Windows 7 firewall with respect to XP.
Let's see if we find something.

Please share more thoughts on your preference of VNC for X thing.
Couldn't get it.

VNC can display any desktop on any host. VNC can remote control windows, MAC or X. In X, Xvnc runs as a daemon on the box providing XServices to write a virtual, in memory desktop that a viewer can see. I usually run one per UNIX box, so any X on that box does not play tcp ping pong on the lan; it is all local.

Some complex X apps then load and run much more quickly. The app writers might have had a local console as X screen, never having to deal with long and latent tcp connections.

To operate the X desktop, you connect with vncviewer, using port 59xx tcp. VNC has many compressions and tricks to allow the desktop to display well even on low bandwidth. If you kill the vncviewer or tcp connection, all the X apps are still connected to Xvnc, awaiting your return on a new viewer connection. Some versions of vnc are free. There are many vnc viewers, like ultravnc and now I use the java tightvnc, so my XP shortcuts look like this:

C:\WINNT\system32\javaw.exe -jar "C:\Documents and Settings\myid\My Apps\tvnjviewer-2.6\tightvnc-jviewer.jar"  ....

You can set up vnc to allow multiple viewers for mentoring and training. By default, any new viewer disconnects old ones, so you can change locations and pick up where you left off, or fire up a new vncviewer if it hangs.

Another possible reason is access control. If you start a process on system A and this process wants to display a window on the display of system B then system B has to allow this access for system A first.

On a UNIX system this is usually done with the xhost command, the most common form being:

xhost +

which simply disables access control (allows every host to display windows).

It might be that XP lacked (had deconfigured) such an access control whereas Windows 7 has this enabled.

I hope this helps.

bakunin

Thanks everybody

PS: The xhost command can take host ids in place of + so it is not wide open.

try opening your x-server and with from your shell client, type ssh -X hostname_of_remote.
make sure you have xauth installed on the remote machine. If debian based.. apt-get install xauth. if red hat/cent base... yum install xauth.

Tunneling X via ssh is fine, but the performance drops both with remote desktops and with ssh encryption delays. SSH might help by allowing -C compression on slow paths, but generally it adds noticable latency, often a bigger problem than bandwidth. That is why the local Xvnc outperforms other remote X solutions. Attachmate has something similar that they call the remote server, but VNC is free. With high latency, xterms may work OK but GUI apps may take forever to present a window.