1.3.3 dev

[Rudi De Vos]

files
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVnc_133.zip

Changes
1.3.3 dev
*TigerVNC compatibility extClipboard extDesktop rfb protocol
* 24 depth (zrle tight encoders)
* chat bug fix
* restore window fix

[Thomas Levering]

Fullscreen with "Allow multi monitor spanning" is buggy (1.3.2 too)
*Only Monitor1
*Window not on Visible Screen
*Scroll to 3rd Monitor (Fullscreen Local and Remote 3Monitor)

[Ekscel]

When switch to fullscreen, the sliding black bar is missing "minimize icon _". I compare this version 1.3.3 or 1.3.2 with previous one 1.2.4 and the version 1.2.4 has minimize icon. See screenshot:
https://drive.google.com/file/d/1X82Ikk ... sp=sharing

[Rudi De Vos]

files
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVnc_133_dev2.zip

1.3.3 dev 2
* TigerVNC compatibility
* minimize fullscreen should only be disabled with span multi mons
* When multi mon is selected, fullscreen always span all monitors

[CPC]

Hello Rudi

So far x86 1.3.3 dev 2 has worked outstanding for my application and needs.

No negative issues to report. I've updated to x86 winvnc 1.3.3 dev 2 wrapped into my reverse connection application as well as my helpdesk running x86 vncviewer 1.3.3 dev 2. I have used it all day with dozens of PCs running both 32 and 64 bit systems, removing malware and doing all sorts of system updates. I'm glad to say no issues found so far. Stable connections, no errors, auto-reconnects as expected, good file transfers and chat worked as expected. I will continue to test and update you if I find anything in my work flow.

I have not tested the latest x64

Rudi: Thank you for your continued great work.

CPC

[Thomas Levering]

is it possible to have a different setting for "Allow multimonitor spanning" and "Allow multimonitor Fullscreen" ?
1. Allow to make a Window bigger then one Monitor (now -> Allow multimonitor spanning = on)
2. Only use One Monitor for Fullscreen (now -> Allow multimonitor spanning = off)

Fullscreen is not useable for me with "Allow multimonitor spanning = on" -> cant´t move Fullscreen to other Monitor


Other small problem:
open viewer in Window
go to Fullscreen
go back to window
try to rezize the window -> the max Size is wrong(smaller). The size of Border and Toolbar is not add to the max size.

[Rudi De Vos]

files
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVnc_133_dev3.zip

1.3.3 dev 3
* multi monitor... again

spanning -> fullscreen = all monitors
non spanning -> you can make the windows bigger then a monitor and it maximize to the nearest monitor.

[Thomas Levering]

Thank you!

Now with "Allow multi monitor spanning" off
this is OK, only a small bug.
if from Fullscreen back to Window the window size is wrong. (Size = Size - Border)
Enable Disable Toolbar Fix the size.

I Think it´s better to rename in GUI
"Allow multi monitor spanning" -> "Allow multi monitor Fullscreen"

With "Allow multi monitor spanning" on (I don't need it anymore)
there are many Bugs
If make Fullscreen on right Monitor -> right Monitor is used
If make Fullscreen on left Monitor -> all Monitors are used
if the remote screen is small -> all Monitors are used
if go back to window -> size is not restored

[Skyfighter]

After a long time of abscence I came back to see what's up...and wow there are a lot of changes and new options! I'm really happy to see it's going on!

Trying to catch up...started with an easy step, simply swaped my older viewer with a newer one (first v3.2.0.0, later v3.3.3.0-dev3) while keeping the older server-installs untouched (e.g. v1.2.4.0, v1.2.2.4b and older @ win10 with ddengine / win7 with mirrordriver ; single & two-monitor PCs). But that didn't go well: each and every uvnc-session feels slower (using ZRLE by default, but tried u2, too); most of the time the remote cursor seems to react with a delay or regularly kind of hangs for a few ms - not sure how to describe that precisely.
After a few days I went back to my previous viewer (v1.2.4.0) to compare -> sadly the older viewer-sessions feel much more fluid & snappy.
Just want to ask: is this intended/by-design (e.g. because of a profound change in the newer versions) or a bug?

(Never the less I will update the uvnc-server on one of the PCs to v3.2.0.0 or v3.3.3.0-dev3 soon and continue with my tests...)

Last but not least: Thank you very much for this essential piece of software, Rudi!

[Thomas Levering]

i Try to find problems (not many Time)
Only Viewer
VisualStudio2017 only x86 is compiling,
x64 -> LNK1104 Datei "zlibstat.lib" kann nicht geöffnet werden.



FullScreenTitleBar.cpp
Line 241
CreateToolTipForRect(SwitchMonitor, SwitchMonitorTip, "Swicth monitor");
change to
CreateToolTipForRect(SwitchMonitor, SwitchMonitorTip, "Switch monitor");


ClientConnection.cpp
Line 8657
old

Code: Select all

				case tbWM_MAXIMIZE:
					//_this->SetFullScreenMode(!_this->InFullScreenMode());				
					_this->SizeWindow();   // Thomas Levering
					_this->SetFullScreenMode(FALSE);
					return 0;

New

Code: Select all

				case tbWM_MAXIMIZE:
					//_this->SetFullScreenMode(!_this->InFullScreenMode());				
					_this->SetFullScreenMode(FALSE);
					_this->SizeWindow();   // Thomas Levering
					return 0;

[Rudi De Vos]

Code: Select all

	case tbWM_MAXIMIZE:
					_this->SetFullScreenMode(FALSE);
					_this->SizeWindow(false, false); // Thomas Levering
					_this->restoreScreenPosition();

Then the position is also restored

[Thomas Levering]

if i remove
zlibstat.lib
from vncviewer\vncviewer_VC2017.vcxproj
x64 is compiling too


New

Code: Select all

    <Link>
      <AdditionalDependencies>comctl32.lib;winmm.lib;ws2_32.lib;rdr.lib;libjpeg-turbo-win.lib;liblzma.lib;omnithread.lib;zip32.lib;unz32lib.lib;%(AdditionalDependencies)</AdditionalDependencies>

Old

Code: Select all

    <Link>
      <AdditionalDependencies>comctl32.lib;winmm.lib;ws2_32.lib;rdr.lib;libjpeg-turbo-win.lib;zlibstat.lib;liblzma.lib;omnithread.lib;zip32.lib;unz32lib.lib;%(AdditionalDependencies)</AdditionalDependencies>

[Thomas Levering]

_this->restoreScreenPosition();
results in a 10x10 small window on position 0x0 (on wrong Monitor)

without
_this->restoreScreenPosition();
the window restore to the last saved position (only saved, if connection closed)


i use only save position, and not save size.

[stefanorossetti]

I confirm the above.
The vncviewer 1.2.4 viewer is certainly more responsive and faster than the latest viewer any version of the vncserver.
maybe something has changed in the code.
doing tests
the difference is especially noticeable when the server's internet connection is slow.
even changing encoding there are no improvements, from my experience the one that works best in most cases is ZRLE

[CPC]

Hello
I'm using ZRLE... In my reverse connection scenario, I have not noticed a slow down using 1.3.3 dev-3 at both ends...yet. However, I have not tried other settings and my settings are very low demand /basic.

On the server side running only: ultravnc.ini, VNCHooks.dll (53KB) and winvnc.exe (1.3.3 dev-3)
On the viewer side ZRLE, 256 colors launched via the following command:
C:\UltraVNC\vncviewer.exe -listen -quickoption 3 -scale 6/10 -password SecureVNCdsmPwd -autoacceptnodsm -loglevel 3 -logfile vncviewer.log

Maybe this will help narrow down the slowness issue the others are experiencing in their configurations?

Cheers
CPC

[Skyfighter]

next test: updated the server-side on one pc to v3.3.3.0-dev3 @win10 x64 + using viewer v3.3.3.0-dev3
- not sure, but first impression: overall performance seems much better (than viewer v3.3.3.0-dev3 + server v1.2.2.4b/v1.2.4.0)
- cursor still behaves sluggish, remote cursor hangs/freezes (for a few ms) on regular basis

examples regarding weird cursor-problem:
1) Open context-menu of UltraVNC tray icon (on the server side) and move your cursor between the frist ("Properties") and last entry ("Close VNC Connection"). Moving the mouse with "the right speed" you can see that the remote cursor regularly stops while the small rectangle (local cursor) already moved further.
2) Instead of UltraVNC-Server context menu open windows explorer, go to a folder with many folders/files...and the same procedure: move the mouse up/down between first and last (visible) file/folder (no need to scroll the file list).
3) windows explorer: try to select multiple (5-15) single files (keeping CTRL pressed) while moving cursor over the file-list (going to the next file which has to be selected)...if you have to to this often and fast the occasionally freezing cursor may drive you crazy
-> Remote cursor seems to hang more likely when there are slow (and/or small) mouse movements.
-> Perhaps it has something to do with tip-texts of the hovered elements or changing cursor-icons (e.g. "normal cursor" <-> "window-resize-cursor")? (on the other side I see the hanging cursor while moving over an empty desktop, too)

[Skyfighter]

Additional findings to my previous post:
1) Somehow I managed to kill the remote cursor: using ZRLE it is simply gone (only small, hardly visible, local rectangle); switching to u2 cursor shows up, going back to ZRLE cursor vanish. (not sure, but this started after putting remote PC to sleep + wake it up again and/or playing with viewer checkbox "Use Zstd instead of zlib" while connected; even uvnc-server restart does not bring cursor back & there are no stalled vncviewer.exe-processes on the viewer side - WTF, I'm at loss.)
2) Viewer v1.2.4.0 + Server v1.3.3.0-dev3: NO weird cursor problem! Fast & Snappy. (=> Bug in the viewer?)

[ddbivens]

UltraVNC 1.3.3-dev3 on both ends. Local is Windows 7/64bit, 3 monitors, center is primary, right monitor is a lower resolution than left 2 monitors. Remote is Windows 10/64bit, 2 monitors, left is primary, matched resolution. I launch the viewer with command line:
c:\Program Files\UltraVNC\vncviwer.exe pcname:port /autoscaling /encoding ultra2
When I connect the vncviewer window opens on my primary, center monitor, edge to edge, with both remote monitors displayed in this window. The scaling shows Auto 49%. I click the Select Full Desktop button and the vncviewer window resizes, but shifts left of the center of my primary montior and shows the remote primary monitor. I click Select Full Desktop button and the vncviewer window expands the window and is now partly showing on my left and right monitors as well, shifts left slightly (splits the 'i' on the tool bar between my primary and left monitor) and has about 1/2 as much displaying on my right monitor. The settings now show Auto 85%.
The shifting left might be caused by my right monitor not being as high a resolution as my left two monitors.
If the viewer could remember that it was launched with /autoscaling and return to the primary monitor showing 1, 2 or 3 remote monitors, it would be better for me.

[Rudi De Vos]

ok, gonna take a look at the cursor first.
Maximize/restore/minimize is for later.

First i need to find the first version that had this problem
Can someone else also try with 1.3.1, if that's ok 1.3.2 it must be added somewere.


Added zip with all viewers (32bit)
1.3.1
1.3.2
1.3.3-dev1
https://uvnc.eu/download/133/vncviewer_1240-133.zip

The source diff with 1.2.4 should give some clues.

Thomas, update git (development branch with latest code) the restoreposition works on my site

[Skyfighter]

Using your viewer-package with server v3.3.3.0-dev3 @win10 x64...conections established one after the other in the following order (did this two times to be sure):
1) vncviewer_131.exe -> no remote cursor upon connect* ; weird cursor problem exists
2) vncviewer_132.exe -> no remote cursor upon connect* ; weird cursor problem exists
3) vncviewer_133.exe -> no remote cursor upon connect* ; weird cursor problem exists
4) vncviewer_1240.exe -> remote cursor exists upon connect ; NO cursor problem
*upon connect there is no remote cursor (only small rectangle for the local cursor); screen-refresh-button doesn't bring it back...but a single right-mouse-button-click onto empty desktop (opening the context menu) and the remote cursor shows up. (As mentioned in my previous post I'm not sure how I intially killed the remote cursor; perhaps I should reboot the server-pc. But at least the fact that v1.2.4.0 shows the remote cursor makes it questionable.)

Please let me know if there's something else I could test!

[stefanorossetti]

other viewer:

i did a test with thigvnc viewer using winvnc 1.3.3 as server without encryption. I admit that the difference in fluidity and use of the viewer is notable, I saw that on the mouse cursor they put a small circle perhaps to be more precise with the positioning of the mouse.
There is not that slight mouse flicker with this viewer.
It would be nice to have such a viewer.
On others they want to test maybe they can compare.
Thank you.

[Rudi De Vos]

I could it trace back to 20sept update.
Difficult to see on LAN, but when you take good attention the cursor is a few pixels behind, special when moving the mouse slow vertical.

Removed this code part, this was added on 20 sept, and it looks like this his has something todo with it

Code: Select all

		if ((MouseOldX == x) && (MouseOldY = y) && (keyflags == 0))
		{
			return false;
		}
		MouseOldX = x;
		MouseOldY = y;

Please test, it's hard to repeat with my PC's but it feels smoother
https://uvnc.eu/download/133/vncviewer_133_test.zip

[Skyfighter]

Yes, I guess that's it! Can't reproduce the weird cursor behaviour with this test-build.
Looks like the test-build is based on the older "v1.3.3.0-dev2"? Can you please re-apply the fix (and perhaps others from above?) to v1.3.3.0-dev3 / current development and upload x86/x64 binaries? Then we all would have a up-to-date version for further tests...
Thank you very much, Rudi!

EDIT: Had a look at the "no remote cursor upon connect"-problem, which exists in the above test-build, too. It is absolutely reproducible: upon connect the remote cursor occasionally is - if at all - visible for <= 1 second until it vanishes (= only small rectangle for the local cursor). The remote cursor stays gone and only comes back with a shape-change (e.g. window-resize-arrows, busy-shape -> this round windows 10 circle which was a hourglas long time ago), then it seems to stay. Tried ZRLE (with or without zstd), u2, tight and hextile which all showed the missing cursor upon connect.

[Rudi De Vos]

files 1_3_3_dev4
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVNC_1 ... _Setup.exe
https://uvnc.eu/download/133/UltraVnc_133_dev4.zip

[Thomas Levering]

1.

Thomas, update git (development branch with latest code) the restoreposition works on my site

OK, now only restore if savepos not active


2.

Code: Select all

      if ((MouseOldX == x) && (MouseOldY = y) && (keyflags == 0))
      {
         return false;
      }
      MouseOldX = x;
      MouseOldY = y;

This is for: 2 Viewer to one Server, and one Viewer leave the Mouse on the Screen. Not disturb the other viewer.
Other solution?

3.
Server with 3 Monitors
The Switch Monitor Button switch between Monitor 1 and 3 (not Monitor 2)

[Rudi De Vos]

3. Looks like ddengine isn't active.
With ddengine you switch to the next monitor 1-2-3-4-5... ( 2-64 monitors)
Without you can only select 1-all-all-1

2. A site effect of the change is a stuttering mouse.
I guess the code was made for
Mouse is in the middle of the screen viewer1 and viewer2 mouve the mouse.
Then the mouse move is send to viewer 1 and reset by the position of the physical mouse.
Then viewer one send his mouse position to the server, who update viewer 2

The server client thread could ignore non clicked cached mouse positions as optional ini setting.

[Thomas Levering]

Code: Select all

 
  case tbWM_MAXIMIZE:
               _this->SetFullScreenMode(FALSE);
               _this->SizeWindow(); // Thomas Levering
               _this->restoreScreenPosition();

not
_this->SizeWindow(false,false);
-> if remote screen is bigger

Code: Select all

void ClientConnection::SizeWindow(bool reconnect, bool SizeMultimon)

3.
SwitchMonitor Test was on Windows7

[SkyBeam]

1.

Code: Select all

      if ((MouseOldX == x) && (MouseOldY = y) && (keyflags == 0))
      {
         return false;
      }
      MouseOldX = x;
      MouseOldY = y;

This is for: 2 Viewer to one Server, and one Viewer leave the Mouse on the Screen. Not disturb the other viewer.
Other solution?

Wouldn't the be the use of multiple mouse cursors a proper solution?
To be honest even for remote collaboration where one user is locally on the VNC server it would be helpful having multiple cursors. One controlled by the local user at server side (visible to viewers) and one cursor for each VNC client connected (perhaps using different display color or shape).
Also collaboration tools like Teams are using this technique showing an annotated cursor for each user controlling a mouse.

There are tools like TeamPlayer, MouseMux or Dual Display Mouse Manager doing similar things.

Implementing this along with the new virtual monitor feature would even allow to use each VNC to create a terminal service where each connecting user would get its own virtual screen, mouse and keyboard and could work with its own programs on his dedicated desktop. However this would be a very specific use case. Allowing each client to control its own cursor alone would be beneficial in many cases.

[Rudi De Vos]

not
_this->SizeWindow(false,false);

Yep, changed

Virtual keyboard and mouses and display seperated... would be nice but would this not violate the MS license.
You need a call for each simultanious user.

Multiple mouses with each his own color would be nice... any opensource project that has some sample code ?
http://benjie.org/software/linux/collab ... ointers%20(Sort%20of,labelled%20with%20that%20user's%20name.

[SkyBeam]

would be nice but would this not violate the MS license.
You need a call for each simultanious user.

I don't think it would since this would be just equal to a self-made terminal server. However not even providing user separation but purely virtual desktop separation. The license you're referring to is the limitation of RDP to handle only a single connection and forcing the local users to be locked out if a remote connection is established via RDP. Windows Terminal server does not have this limitation and allows multiple simultaneous RDP connections.
Microsoft cannot prevent users implementing their own services even if they include something which looks like a virtual desktop.
As long as you're not going to hack the RDP service to allow multiple parallel RDP sessions and then provide those via VNC I don't see any issue.

Moreover the core of the statement was to allow multiple mouse pointers on the (remotely mirrored) local screens. Just as many screensharing applications are doing it. The option to just mirror a virtual screen and create some visually isolated desktop sessions would be just an added option.