UltraVNC 1.2.1.2 pre-release - Download links

[Rudi De Vos]

** V1.2.1.2 Sept 2016
*grey screen on start lock
*don’t balloon incoming non rfb data
*added portrait mode windows 10
*switch w8hook corrected
*reset correct polling after w8hook failure
*dpi aware viewer

All singned with new certificat sha256

downloads
https://uvnc.eu/download/forum1212/Ultr ... _Setup.exe
https://uvnc.eu/download/forum1212/Ultr ... _Setup.exe
https://uvnc.eu/download/forum1212/Ultr ... 12_x86.msi
https://uvnc.eu/download/forum1212/Ultr ... 12_X64.msi
https://uvnc.eu/download/forum1212/ultravnc_64_1212.zip
https://uvnc.eu/download/forum1212/ultravnc_32_1212.zip

source updated in svn build version 1067 for 1.2.1.2
https://sourceforge.net/code-snapshots/ ... e-1067.zip

[UsernameIssues]

Both the client and server are using pre-release 1.2.1.2 64bit on W7 pro 64bit OS.

https://www.youtube.com/watch?v=bfWNbMfxn4I

The reason for right clicking on the VNC shortcut file is:
I wanted to show that I only started two VNC sessions...
...no issue with the mouse left clicking too many times.

Notice that the Status window still indicates "Connecting...", but the second session has already connected.

Clicking on the button named Cancel, does not cancel the connection.

[Rudi De Vos]

Thanks, for trsting with the latest....

It's strange, i can't repeat it.
But indeed it look like the window isn't connected else cancel would cancel and connect data would be added.

Let see if i can find something this weekend, have some little time left.

[UsernameIssues]

Today, several remote computers had a tray tip (balloon? notification?) message down by the clock. Creating a View Only VNC session to those computers made the tray tip go away before I could read it. These tray tips usually stay around if the computer is not disturbed (e.g. no mouse movements or keys pressed).

Something has changed between uvnc version 1.2.0.9 and 1.2.1.2. That change not only "disturbs" the remote computer in such a way that removed tray tips, but it also wakes up monitors that were set to sleep via power settings.

[Rudi De Vos]

Change between 1211 and 1212 if (m_client->m_outgoing) , we restrict the balloon to outgoing connections.
Before a port scanner could popup the balloon (incoming) now it need to be an outgoing. So we actual retrict it.

balloon:
if (m_client->m_outgoing) vncMenu::NotifyBalloon(szInfo, NULL);

VNC only give a balloon if the server makes a connection to a viewer, outgoing connection
or you use -sc_prompt commandline to start the server.

monitor wakeup happen only, after a succesfull logon.

check mslogon.log or eventviewer to see if there was a logon during that time.

[UsernameIssues]

Sorry that I was not clear: I'm not talking about a balloon that is created by the VNC app. I'm talking about a balloon that is created by some other app on the remote computer. As soon as I create a view only VNC session to the remote computer, the balloon goes away (if the balloon had been displayed for a while). I have tested this while standing in front of a "remote" computer. As soon as I created a view only VNC session to the "remote" computer, the balloon went away. This does not happen in uvnc version 1.2.0.9. With that older uvnc version, I could create a view only VNC session and read the balloon info on the remote computer.



Using uvnc version 1.2.1.2:
A view only VNC session is waking the monitor. There is no MS log on involved.

Using uvnc version 1.2.0.9:
A view only VNC session is NOT waking the monitor.

I ran a script on the remote computer that pulls GetLastInputInfo from user32.dll and GetTickCount from Kernel32.dll. With that info, I can display the idle time (via tool tip) that Windows uses for screensavers and to turn off monitor via power settings.

Using uvnc version 1.2.1.2:
Connecting to a remote computer using a view only VNC session is definitely resetting that idle timer on the remote computer.
(this wakes up the monitor, destroys old balloons and ends screensavers)

Using uvnc version 1.2.0.9:
Connecting to a remote computer using a view only VNC session does NOT reset that idle timer on the remote computer.

As a simple test, let the screensaver engage on a remote computer that is using uvnc version 1.2.0.9. Create a view only VNC session to that remote computer. The screensaver should remain engaged on the remote computer. Repeat that same test using uvnc version 1.2.1.2.

This idle timer reset only happens during the connection of the first VNC session to a remote computer that is using uvnc version 1.2.1.2. Subsequent VNC sessions do not reset that idle timer again. The screensaver on the remote computer does eventually engage again... so this idle timer reset issue is not a recurring event for a given VNC session.

[Rudi De Vos]

Are you using the same ultravnc.ini settings for both versions ?

[UsernameIssues]

Are you using the same ultravnc.ini settings for both versions ?

uvnc was completely uninstalled and any left over folders were deleted between version tests. The ultravnc.ini contains whatever the default install creates. The only thing changed was the password (test). [Password privacy is not a concern for these test installations in my virtual machines.]

This is the INI for uvnc version 1.2.0.9:

Code: Select all

[ultravnc]
passwd=2F981DC548E09EC231
passwd2=2F981DC548E09EC231
[admin]
UseRegistry=0
MSLogonRequired=0
NewMSLogon=0
DebugMode=2
Avilog=0
path=C:\Program Files\uvnc bvba\UltraVNC
kickrdp=0
service_commandline=
DebugLevel=10
DisableTrayIcon=0
LoopbackOnly=0
UseDSMPlugin=0
AllowLoopback=1
AuthRequired=1
ConnectPriority=0
DSMPlugin=No Plugin Detected
AuthHosts=
AllowShutdown=1
AllowProperties=1
AllowEditClients=1
FileTransferEnabled=1
FTUserImpersonation=1
BlankMonitorEnabled=1
BlankInputsOnly=0
DefaultScale=1
SocketConnect=1
HTTPConnect=1
AutoPortSelect=1
PortNumber=5900
HTTPPortNumber=5800
IdleTimeout=0
IdleInputTimeout=0
RemoveWallpaper=0
RemoveAero=0
QuerySetting=1
QueryTimeout=10
QueryAccept=0
QueryIfNoLogon=0
primary=1
secondary=0
InputsEnabled=1
LockSetting=0
LocalInputsDisabled=0
EnableJapInput=0
FileTransferTimeout=1
clearconsole=0
accept_reject_mesg=
KeepAliveInterval=5
[poll]
TurboMode=1
PollUnderCursor=0
PollForeground=0
PollFullScreen=1
OnlyPollConsole=0
OnlyPollOnEvent=0
EnableDriver=0
EnableHook=1
EnableVirtual=0
SingleWindow=0
SingleWindowName=
MaxCpu=40

This is the INI for uvnc version 1.2.1.2:

Code: Select all

[ultravnc]
passwd=2F981DC548E09EC231
passwd2=2F981DC548E09EC231
[admin]
UseRegistry=0
MSLogonRequired=0
NewMSLogon=0
DebugMode=2
Avilog=0
path=C:\Program Files\uvnc bvba\UltraVNC
kickrdp=0
service_commandline=
DebugLevel=10
DisableTrayIcon=0
rdpmode=0
LoopbackOnly=0
UseDSMPlugin=0
AllowLoopback=1
AuthRequired=1
ConnectPriority=0
DSMPlugin=No Plugin Detected
AuthHosts=
AllowShutdown=1
AllowProperties=1
AllowEditClients=1
FileTransferEnabled=1
FTUserImpersonation=1
BlankMonitorEnabled=1
BlankInputsOnly=0
DefaultScale=1
SocketConnect=1
HTTPConnect=1
AutoPortSelect=1
PortNumber=5900
HTTPPortNumber=5800
IdleTimeout=0
IdleInputTimeout=0
RemoveWallpaper=0
RemoveAero=0
QuerySetting=1
QueryTimeout=10
QueryAccept=0
QueryIfNoLogon=0
primary=1
secondary=0
InputsEnabled=1
LockSetting=0
LocalInputsDisabled=0
EnableJapInput=0
FileTransferTimeout=1
clearconsole=0
accept_reject_mesg=
KeepAliveInterval=5
[poll]
TurboMode=1
PollUnderCursor=0
PollForeground=0
PollFullScreen=1
OnlyPollConsole=0
OnlyPollOnEvent=0
EnableDriver=0
EnableHook=1
EnableVirtual=0
SingleWindow=0
SingleWindowName=
MaxCpu=40

The only difference is the new setting of
rdpmode=0


The VNC shortcut file used to create the uvnc session is:

Code: Select all

[Connection]
Host=10.0.2.9
password=2f981dc548e09ec2
port=5900
proxyhost=
proxyport=5900
[options]
disableclipboard=0
viewonly=1
showtoolbar=1
Scaling=1
scale_num=25
scale_den=100

It does not matter if disableclipboard=1 is used instead of disableclipboard=0. Clipboard sync does not reset the idle timer.

[Rudi De Vos]

The screensaver should be killed when you logon.

On start we execute

Code: Select all

m_desktop->KillScreenSaver();
	{
		keybd_uni_event(VK_CONTROL, 0, 0, 0);
        keybd_uni_event(VK_CONTROL, 0, KEYEVENTF_KEYUP, 0);
		Sleep(500); //Give screen some time to kill screensaver
	}

Send close to screensaver and press a key.

Code is still the same as in 2012 didn't checked older releases and it doesn't depend on the view-only status.
Code is injected by the server himself.
Yes the screensaver idle timer is reset...on injected keypress.

[UsernameIssues]

We will probably go back to version 1.2.0.9
...where this idle timer reset does not happen

I don't want to wake up more than a dozen monitors just to glance at the status of things running on remote computers.

Also, version 1.2.0.9 has the ability to re-size the viewer window by dragging the window's edges

Thanks for your time on this.

[Rudi De Vos]

1209 is from 2015, it also has the same wakening code.

re-size the viewer window by dragging the window's edges: That part didn't changed.
[v] scale the window is possible the missing option.

Are you using the same viewer settings ?

1209 viewer on a 1212 server ? same effect

[UsernameIssues]

The video below shows two virtual machines. Both VMs are running 1.2.0.9 (build Nov. 2 2015 20:50:06).

The VM on the right is the "remote" computer. Look in the lower right part of the screen where the clock is on that "remote" computer. Just above the clock is a tool tip displaying the seconds since inactivity.

https://www.youtube.com/watch?v=WLQsqiCjkdE

The video starts just before the screensaver (Blank) engages after 60 seconds of inactivity. I created a view only VNC session using the VNC/INI shortcut file shown in the left notepad window in the video. That view only VNC session will not remove the screensaver. It does not reset the timer. I get the same results even if the timer script is not running on the remote computer.

I get the same results even if I use a VNC session that is controlling the "remote" computer. I selected the VNC/INI shortcut file, moved my mouse off screen and pressed enter to start the VNC session that controlled the "remote" computer.

[UsernameIssues]

re-size the viewer window by dragging the window's edges: That part didn't changed.
[v] scale the window is possible the missing option.

uvnc 1.2.0.9 on both VMs:
https://www.youtube.com/watch?v=Sanbr1TKeq4

uvnc 1.2.1.1 on both VMs:
https://www.youtube.com/watch?v=z6FHmt82Huc

The installations use the default settings. Where is the setting that you mentioned?

[UsernameIssues]

Are you using the same viewer settings ?

Yes, the same VNC/INI shortcut file is used to start the viewer for each test. You can see those settings in the notepad window below each VNC/INI shortcut file. All other settings are default - except the password.

1209 viewer on a 1212 server ? same effect

Yes, same effect.
1.2.0.9 server does not wake the remote computer.
1.2.1.0 and above does wake the remote computer.

Here is what I see when the viewer is from 1.2.0.9 and the server is from 1.2.1.2:
https://www.youtube.com/watch?v=By0B1OSKIs0

[UsernameIssues]

We are just going to stick with 1.2.0.9.

thanks

[Rudi De Vos]

If 1209 server works better in your case then you can keep using it.

Viewer auto scale option
ON: scale
OFF: scrolbars

[Skyfighter]

Theres a small bug in the savepos/savesize-logic of the viewer and the UVNC_Launch (found them in v1.2.1.1 and just verified it is still there).
If you minimize the viewer and then close it using the context menu of taskbar icon (while the viewer is still minimized) the viewer saves bad position values in options.vnc. For example in my tests the "good values" changed from

Code: Select all

[MyHostName]
x=98
y=6
w=1724
h=1028

to these "bad values":

Code: Select all

[MyHostName]
x=-32000
y=-32000
w=160
h=28

All following attempts to connect to [MyHostName] don't show a viewer window anymore -> there's only the viewer taskbar icon (while the remote-machine shows the yellow uvnc icon) and I can't find a way to restore the window size, so the only possibility to recover seems to be "delete bogus size values from options.vnc".
Could you please implement a check "if window is minimized, do NOT save pos/size"?

(UVNC_Launch behaves similar, but it's possible to recover from the gui: even with bogus pos/size values in uvnclaunch.ini you can resize the window from "mini-verion" to a usable size. Nevertheless the same exception before saving pos/size would be nice.)

Thank you very much!

[Rudi De Vos]

Addded if isicon(), don't save position

[Prisma]

Searched already the forum but didn't find a short clear answer:
Is it necessary to ship the w8hook.dll with the XP compliant build?
From what I understood it is not necessary. Because the DLL is only a collection of win8 tools/functions which are now in the main code.
Correct? Or are there use-cases where the DLL is still necessary?

[Rudi De Vos]

abosoluted
w8hook.ddl was the duplication engine, only used for OS >= win8

This is not longer used, we now have the duplication engine buildin in the exe and provide 2 seperate exe.
exe win7>= has the w8hook buildin
exe w2K and xp is compiled without.

Not longer needed unless you have an old versions of the server

[Skyfighter]

Addded if isicon(), don't save position

Thanks Rudi - works perfect (viewer)!
(Do you intend to implement that check into UVNC_Launch, too?)

[Rudi De Vos]

We want to release 1212 end of the month, still time to make smaler changes.
Is on the list..

[ddbivens]

I am not certain but I think there might be a bug in the routine that checks if the chat window is open when you try to close the VNC connection (I use the X in the top right of the window to close the viewer). If I have the chat window open and then try to close the Viewer without closing the chat window first, I get a warning that I must close the Chat Window first (which is what I expect). If I immediately close the chat window (on my side) then try to close the Viewer, I get the same warning (each time I try to close the viewer, again and again). I have to use task manager to close the viewer (or my batch file which uses TaskKill to close all viewer instances). I might not be using the right menu option or something. This has happened for several versions, I just had forgotten to mention it.
BTW, I am using the latest prerelease on about 500 systems and I am getting excellent results. The only place where the default does not work the best for me is when I connect to our remote location, slower internet connection, and when I connect to our local wireless systems. The "Auto" setting connects using the ZRLE mode. I end up deselecting "Auto" and manually selecting "Tight" and I get much better results. I can't remember, is there a command line switch that I can use to cause Tight to be used for specific PCs when Auto is my saved as my default setting?
Thank you for this excellent program.
I am just trying to help.
Update: The chat window closes just fine with the final release of 1212.

[Rudi De Vos]

Thanks Rudi - works perfect (viewer)!
(Do you intend to implement that check into UVNC_Launch, too?)

UVNC_Launch does not save or load the position. It's the viewer that does it.
Just make sure that the launcher has the correct path set for the new viewer.
(Default he use the viewer in the same folder as the launcher)

[Skyfighter]

UVNC_Launch does not save or load the position. It's the viewer that does it.

Sorry Rudi, we are talking past each other... you fixed the viewer-bug but UVNC_Launch has the same bug: it saves bogus w/y-values in it's uvnclaunch.ini when UVNC_Launch is closed while its window is minimized (UVNC_Launch window = the window with the tree view of all *.vnc connection files). Can you please have a look once more?

[Rudi De Vos]

ok, understand... it's the launcher control window not vncviewer.
fixed for next update

[szymon.nowak]

Hi, now after command winvnc.exe -install , ultravnc service started after 15-20 second - if you can somehow speed up this process?

2. Can you add option to ultravnc.ini
Run_after_client_coonnection=%installfolder%\script.cmd or exe file ?

[ddbivens]

I do have one request, though I don't know how feasible it would be... I don't use "View Only" mode, but my co-workers do. So my request would apply 'on initial connection when not using "View Only" mode' or when "View Only" mode is turned off. What would be the possibility to have a check box, like the "View Only" box, that would read the CAP LOCK status of the remote PC and set your PC to match. My problem is that when I connect to a remote PC (and when they turn off the View Only mode) the remote PC will change the Cap Lock state to match the controlling PC. If the remote user is in the middle of typing or data entry, this can often cause problems as our primary program is case sensitive.
Thanks for listening.

[Rudi De Vos]

WIth winvnc -install, service is install and delayed started because no 2 instances of winvnc
can run at the same time. Possible the delay can be set shorter, but then you risk that the start fails
because winvnc -install isn't stopped yet.

Once installed you can activate the service with
net start uvnc_service
net stop uvnc_service
This only take a few seconds.

script
Not in this version, we first need to see if this can be done secure.
Running as application there is no issue, bacause winvnc has the same security level as the desktop user.
But when started as service... you are actual local admin independed if the desktop user is admin or a guest.

[ddbivens]

I was talking with my coworker today. He has his viewer set to "View Only" for the initial connection. He says when he connects to a remote PC, even in "View Only" mode, the CAPS LOCK state on the remote PC will change to match his PC setting. It would seem that "View Only" would not send anything to the remote PC.