Source for vncviewer.exe?

[ivanfitenko]

File vncviewer.exe, as supplied with openxenmanager , seems to be a modified TightVNC viewer (command 'strings vncviewer.exe' yields some mentions of TightVNC). However, there are no sources for this modified version on git tree.

Any ideas where those sources can be obtained from?

[TwoWheelDev]

Hi!

The vncviewer.exe that is present in the repo still, was the one I inherited with the project when it was imported from Sourceforge.

I know it is TightVNC viewer, but do not know if it was modified at all by the old authors of OpenXenManager... as such I have no sources for the executable (and I will be removing it from the tree at some point as part of my efforts to clean up OpenXenManager.

As you are probably aware tightvnc is available from http://www.tightvnc.com/download.php incuding source code.

[ivanfitenko]

At least two modifications are definitely present:

1. vncviewer.exe is able to connect to something like http://our.server/Opaqueref=...... (this is needed to be able to connect to vnc display through xenserver), while original TightVNC does not have such feature
2. When vncviewer.exe is launched, it is launched as a sepatate window (opposite to the behavior we have in linux), and the window has no border. So the users are not able to move the window to another position on their desktops. This definitely seems a bug to me (at least, my users say the viewer is 'unusable until fixed').

So, I wanted to fix the bug from point 2, but still have the functionality from # 1 (i.e. connecting via opaqueref). Hence the source question.

[TwoWheelDev]

1. The VNC doesn't connect directly to the VNC link e.g http://our.server/Opaqueref=...... as we create a tunnel connection to the XenServer, which is terminated locally on the machine running OXM. So the VNC Viewer actaully connects to localhost::. This is implemented here: https://github.com/OpenXenManager/openxenmanager/blob/master/src/OXM/window.py#L1013
2. The VNC viewer in Windows is very much a hack implemented by the original authors, as gtk-vnc (which is used on linux) doesn't have python bindings available for Windows, so as you say it opens in a separate Window... which is positioned over where youd expect to see the VNC output in Linux.
   .
   I can't think that there is anything preventing a user from moving the VNC window, but I will need to investigate further to confirm this.

I believe I was able to simply drop in the lastest version of TightVNC Viewer and it functioned as expected (this is something I intend to make configuarable by a user so they can optionally use any VNC viewer they desire)

[ivanfitenko]

Aha, I see. Maybe I did something wrong last time I tried replacing TightVNC with vanilla copy, I'll try again when I get to that windows host again.

But in such case, the present vncviewer.exe file should be dropped or replaced quite soon, because it does more harm than good, I mean that it contains a definitely modified copy and there are no sources, while the whole OpenXenServer is GPL.

[TwoWheelDev]

I shall also double check it myself.

I couldn't agree more with that... Embeded code copies and binaries are something that in my mind should be avoided at all cost, and cleaning this up in OXM is a big part of my plan for getting it release worthy

[TwoWheelDev]

I've just verified the latest version of TightVNC Viewer and it does work okay.

You'll have to copy the viewer exe to folder containing the current viewer exe, and rename it match (I shall be implementing an option to allow this path to be set, from OXM)

After you've installed TightVNC, you can set the path to the viewer exe in the oxc.conf file - https://github.com/OpenXenManager/openxenmanager/blob/master/src/OXM/oxc.conf

I shall be implementing an options dialog to allow this to be set via OXM

[ivanfitenko]

Well, then the old binary needs to be removed or replaced, at least temporarily.
If you are too lazy to thoroughly read through the binary, just do strings vncviewer.exe | grep -n OpenXenCenter on the command line to have an evidence that the binary is modified and thus cannot be redistributed.