UltraVNC 1.2.1.7 - Download links

ddbivens · Post by **ddbivens** » 2017-11-24 22:02

[Thank you. Downloading now...]
I just tested the 11/24/2017 updated winvnc.exe on a Windows 10 64bit PC. I can send the test folder without an issue. When I try to receive the folder, I can see the Zip file is created on the desktop during the transfer, however the Zip file is deleted immediately after the transfer, but the folder is never created on the Windows 7 PC desktop. I can tell you that C:\Temp does exist on the PC, but since the file is actually being created on the desktop during the transfer, is it possible that during the Zip file creation, you might have left out the '\' after the folder name, before the Zip file name? If so, then the Zip file is not in the expected location and can't be unzipped properly. Just a thought.
Thanks for all the work.

ddbivens · Post by **ddbivens** » 2017-11-24 22:34

OK, after a little more testing...
I used a larger folder so it would take more time to transfer so I could see what was happening during the transfer.
During the transfer a file is created on the Windows 7 desktop name:
!UVNCPFT-Temp!UVNCDIR-Rec Desktop Icons New.zip
After the transfer is completed, I ended up with a file on the desktop named:
Temp!UVNCDIR-Rec Desktop Icons New.zip

AnotherUVNCuser · Post by **AnotherUVNCuser** » 2017-11-25 03:56

Hello guys. I've once again returned after a busy period and i see that you guys are working on something

Since this is related to file transfers, could you (Rudi and/or ddbivens) look into the issue where you can't abort/stop an ongoing filetransfer right away?
Because it only aborts the filetransfer *after* it has completed transfering the file, not when you click the "Stop" button.

(this isn't fun when transfering a big file that takes really long to send/receive)

I'm using Windows 10 Pro x64 (version 1709)

Thanks for the good work!

Post by **Rudi De Vos** » 2017-11-25 09:39

Extra info
Folder Transfer
server to viewer
Server
1) Create a folder.zip in the %TEMP% of the desktop user
Viewer
1) Create a VNC..., this is the delta file, this file is used to continue after a break.
If 500MB is broeken at 400MB, the next try you only send 100MB, the first 400MB are only verified
2) then the zip is extracted in the selected folder

I remember adding a [force stop] button to abort while transfering.
I need to verify if it's in this test.
Can't check anything before tomorrow... beer festival.

Post by **Rudi De Vos** » 2017-11-26 20:36

Rebuild
xp/win/win8 (32/64)
https://www.uvnc.eu/download/1217/ultra ... 7_2611.zip

ddbivens · Post by **ddbivens** » 2017-11-27 00:38

I have tested the 11/26/2017 update between a Windows 7 64bit viewer and Windows 10 64bit server. I used the Windows 8 64bit and also the Windows 7 64bit files on the Windows 10 system. I only tested sending and receiving a folder, fairly large, with multiple files and subfolders. It took about 45-60 seconds to compress the folder to a Zip file (when compression completed). I got mixed results, but most of it not good.
I named a unique folder "sent" and sent the folder from the Windows 7 desktop to the Windows 10 desktop. Sometimes it would send, but only the first try during the same connection. If I closed the File Transfer window, renamed the "Sent" folder on the Windows 10 desktop to "Receivedd" (typo intended) then opened FTW again and started the file transfer to send "Sent" folder again, many times it would never start, sometimes it would start but never seem to finish (The Stop and Force Stop button would go away, but the FTW would not close with the "X" or Force Close button). Sometimes after using End Task then reconnecting to the Windows 10 system, I would actually find the "Sent" folder was on the Windows 10 desktop. I was never able to receive a folder from the Windows 10 system. At most. when it transfered anything, I would get the Zip file on the local desktop. The "Stop" "Force Stop", "Forced Close" buttons never seemed to work. When it hung, which was often, I had to use Task Manager to close the VNC window.
Sorry to have to give these negative reports.

AnotherUVNCuser · Post by **AnotherUVNCuser** » 2017-11-27 03:51

@ddbivens: That type of behaviour is known to me too and it has been like that for a fairly long time. It doesn't happen all the time ("Stop" mostly works but only when the transfer finishes/completes), but i've experienced "Stop" to not work (disappear) and keeping the filetransfer windows open (in use), making it impossible to reopen it or even exit the remote client.

Its also a pitty that uVNC doesn't have its own github repository. It surely would make code (change) digging a lot more efficient.
I know most (if not all) work comes from Rudi, and he also has other things to do in life that require more attention/priority.

But uVNC could become so much better if (more) people could join in, gather their knowledge and commit fixes to a platform such as github.
Judging by the amount of people i see making topics on here and responding to ongoing issues, i think its safe to believe there's still a lot of interest/love for uVNC.

As for myself: I've been using TightVNC in the past, besides it being less buggy it also lacks a lot of good features uVNC has.
That's why i put my trust/hope in UltraVNC.

Hopefully Rudi shares the same vision as me and is willing to accept people's help to improve uVNC, and making it better than ever imaginable.

~Peace (and love)

Post by **Rudi De Vos** » 2017-11-27 13:18

We have a code revision system online from the start of the project.
https://sourceforge.net/p/ultravnc/code/HEAD/tree/

I also wish other people would contribute, but having people testing and pinpointing
bugs already help a lot.

Post by **Rudi De Vos** » 2017-11-27 19:14

Looks to me that we need to break down the problem in seperated issue's and isolate a case that's easy repeatable.

Compressing
1) XP and winzip not working when compiled with VS2017
This is fixed, by compiling VS2010 and using older libs
2) WIN10 temp folder no longer writable for all users.
Before the windows/temp was writable, now it's only the system that has access.
This is fixed by using the current desktop user temp folder, that's writable by the user and the system
decompressing
1) XP, same issue has with compressing, we need to use VS2010 and older libs

Now it looks like there is another issue the connection breaks or hang after a while.
This is harder to find, then a permission denied...

Does it also happen with a big file ?
Slow network, fast network.
On what size does it manifest the fastest
Service or manual: I hope it's service independed so we can it in a debugger

Post by **Rudi De Vos** » 2017-11-28 21:02

I found something.
Server on a hyper-v win10, with limited cpu set, so zipping takes long.
The viewer has autoreconnect set
Now, i send a folder with a lot of files, so the zipping takes long.

*viewer timeout, FT stay open
*viewer autoreconnect to server

Now i get more or less the same, FT is broken, you can't list remote folder...

It looks like i need to anable keepalives during zipping /unzipping to avoid that the viewer close the connection.

AnotherUVNCuser · Post by **AnotherUVNCuser** » 2017-11-29 10:07

@ Rudi De Vos: Ah, Sourceforge is known yes, though Github seems more matured/complete (but perhaps that's just me).

If you don't mind me adding another problem to the list (perhaps it has something in common with keepalives and/or multi threading).

I have a few computers that automatically reverse connect to me, but it often happens that when i close one of the windows, it makes the viewer hang/freeze/not respond, and then i have to end the vncviewer process/task and start all over again if i was working on something.

The problem often occurs when there are multiple incoming connections being made in a row and closing one of the active sessions.

If you want i can demonstrate it with a YouTube video, but perhaps you already know what is going on

ddbivens · Post by **ddbivens** » 2017-12-03 15:32

For this test I am testing the 20171203 Winvnc.exe files on Windows 7 and 10 only. I placed these new files on the Win7 and Win10 PCs. I am transferring a medium sized folder and a large folder from/to the viewer PC, a Win7 64bit and the server PCs Win7 64bit and Win10 64bit.
The medium sized folder transferred from and to the Windows 10 PC.
Once the large sized folder did not receive from a Win7 PC. The File Transfer program reported "Transfer Complete". The File Transfer window would not close. All buttons in the center had vanished except two buttons, one being the "Force Close" button. The Force Close button did not work. I was able to right click the task bar icon and Close Window then the Viewer would close. I reconnected to the PC and the folder was there. I renamed the folder and transferred the folder back to my PC. The transfer seemed to work just fine, except that there was no received folder when I closed the File Transfer window.
I conducted a second round of tests from/to Win 7 and Win 10 computers. These medium and large size folder transfers went both way without an issue.

ddbivens · Post by **ddbivens** » 2017-12-03 21:03

More testing... Win7/64 to Win7/64... Send three large folders... The transfer hung. Stop and Force Stop button did not work. I force closed the Transfer Window. I closed the viewer window normally. I reconnected the viewer and found two folders and one Zip file. I deleted these and tried to send the small and medium size folder. It hung. Stop failed. I force closed the FT window then closed the Viewer. When I reopened the viewer I found one folder and one zip file. I retried sending the 3 folders, medium, large and larger folder (55.08 Mb). The FT window reports Sending file... and never finished. The buttons "Stop", "Forced Stop", Minimize" and "Forced Close" are still visible. None worked except "Minimize". I closed and opened the viewer and found one Zip file and two folders. Note: Our office PCs are set to lock the desktop after 5 minutes of non-use. Is it possible that you need to send a key (like F15) every 59 seconds??? Just a thought.
[Edit] More testing Win7/64 from/to Win10/64 with the same results on trying to send 55.08 Mb. Hangs with 2 folders and 1 Zip file as the result after reconnect.

Post by **Rudi De Vos** » 2017-12-05 20:59

Testing again...

All works fine until we start working with folders.
The folder zipping is, deadlocking the server, server keeps waiting for the zip file.

Change

Parts 1 receive FT command
zip folder -> moved this to a seperated thread, so that server stay responsive during zipping
Part 1 return
Now the server is back responsive and can answer other messages
Parts 2 is done when zip is finished

Using a separated thread is the way to go, but sending messages while server zip the folder
introduce possible other site effects.

testfile:
removed

test:
Start FT, and while server is zipping folder disconnect viewer ( killed from taskmgr) -> crash
Fixed
Seeems this also fixed the FT lock issue after a miss FT
test;
close viewer while zipping
Still not working

Post updated exe when this is also solved

Post by **Rudi De Vos** » 2017-12-07 21:31

This seems to behave better for FT of large folders

https://www.uvnc.eu/download/1217/winvnc_zipthread.zip

ddbivens · Post by **ddbivens** » 2017-12-08 03:46

Outstanding! I transferred two very large folders from/to my Windows 7 PC and Windows 7 and Windows 10 PCs. The transfers were super fast and completed without errors. The File Transfers went flawlessly.
I did not do any testing to try and cancel the transfers in progress. That will be for another day.
Thanks for all the super work on this!!!

AnotherUVNCuser · Post by **AnotherUVNCuser** » 2017-12-08 13:01

I haven't had the time to test it yet but apparently progress has been made (hurray)

One minor nag Rudi: Wouldn't it be better to just have one Stop button that does it all (only ending filetransfer)?
However.. if Force Stop closes the remote connection, then please leave it the way it is (two buttons with different actions

)

ddbivens · Post by **ddbivens** » 2017-12-10 01:59

I have done the mass install to all Windows 7 and Windows 10 PCs (about 600). Connectivity seems to work better with this update. The initial screen connection and refresh seems to be very good. The File Transfer issue seems to be resolved! Great Job!!! On Windows XP PCs, I am using much older versions of the vncviewer.exe and winvnc.exe for reliable connections.
I will let you know how things go next week when I get back to work.

ddbivens · Post by **ddbivens** » 2017-12-17 03:33

I am getting excellent results. The initial connection and screen redraw is very quick almost every time. On a few systems, I get disconnected as soon as it connects, but usually I get a reconnect within 15-30 seconds. It is not consistent so it would be very hard to track down. Anyway, it is rare enough not to be a real bother.
From home, I use VPN and my ISP is throttling my connection in the evening very bad so it is a choppy connection. However, UltraVNC makes a connection and keeps connected fairly good if I use the zywrle encoding.
At work we connect on a good LAN connection to almost all PCs in the local network. I use ultra or ultra2 encoding on all except a few systems where winvnc.exe crashes when I connect. On those systems I use either tight or zrle and on one system I have to use -viewonly to prevent winvnc.exe from crashing. We have a remote site where we have about 20 PCs. Most of the time we can use tight encoding to connect to those systems. I have not been able to use the latest beta's at that site. I last installed version 1.2.1.6 at that location. I will install the final release there when you update the installers.
I tested File Transfers from/to Windows 7/64 and Windows 10/64 PCs and it worked great. I still forgot to test canceling a transfer in the middle. I sent and received some very large folders (3 at once and 1 large with multiple sub folders and files). Everything went great.
Thanks for all the super work on this program and keeping up the web site and forum!!!

AnotherUVNCuser · Post by **AnotherUVNCuser** » 2017-12-18 02:38

ddbivens wrote:Thanks for all the super work on this program and keeping up the web site and forum!!!

I wholeheartedly agree!

(great to read the new build is a huge improvement)

Post by **Rudi De Vos** » 2017-12-18 10:35

Only feedback make it better.

Client/server/network/OS's... all have there influence and i can't test all cases.

Thanks

AnotherUVNCuser · Post by **AnotherUVNCuser** » 2017-12-22 05:37

And that's of course true Rudi

I also have another question for you:

When i right clicked winvnc .exe by accident, i noticed that my WinRAR could open/view the .exe.
I was curious what files would be in it so i opened the exe and noticed that it had a lot of .class files and a META-INF folder.

I didn't expect winvnc to be a java application, so i did some further investigating using Resource Hacker.

Resource Hacker showed other things as well, but then i saw this folder named JAVAARCHIVE.
It had two compressed data entries which were almost identical to each other (only the two VncViewer.class files were different).

But (and here it comes), i was wondering if WinVNC would continue to work if i deleted that JAVAARCHIVE resource, so i deleted it and recompiled the .exe.

Guess what? winvnc.exe would still run and it didn't gave an error

My question: What are those java (class) files needed for when winvnc apparently also can work without them? (are those java files part of a vnc client viewer applet, or are they also needed by the server itself?)

edit: I found this https://www.tightvnc.com/doc/java/README.txt

There are three basic ways to use TightVNC Java viewer:

1. Running applet as part of TightVNC server installation.

Both the Unix and Windows versions of TightVNC servers include small
built-in HTTP server which can serve Java viewer to Web clients. This
enables easy Web access to the shared desktop without need to install
any software on the client computer. Unix and Windows versions of
TightVNC servers are different in the way they store the .class and .jar
files: the Unix server (Xvnc) is able to serve any set of files present
in a particular directory, while the Windows server (WinVNC) has all the
.class and .jar files inside the WinVNC executable file. Therefore, for
Xvnc, it's enough to copy the files into a correct directory, but for
WinVNC, the server binaries should be rebuild if the built-in Java
viewer should be updated.

Conclusion: winvnc has a built-in HTTP server that can serve java viewer to web clients (thus, an optional function)

new edit: There's something i can't get my head around. Where does UVNC read/store its waiting-for-incoming-connections icon? Resource Hacker doesn't show it

AnotherUVNCuser · Post by **AnotherUVNCuser** » 2017-12-25 01:34

Is it true that the winvnc exe also has some debug/meta information? (c:\users\rudi\desktop\ultravnc\winvnc\winvnc\ etc.)
If so, can you possibly decide to leave out all debug/meta information when compiling a final build? (unless you already do that).

Stripping away this information usually makes the exe significantly smaller. It also looks cleaner/prettier

ddbivens · Post by **ddbivens** » 2017-12-25 20:37

Merry Christmas!

AnotherUVNCuser · Post by **AnotherUVNCuser** » 2017-12-26 03:52

^!^!^ A MeRRy ChRiStMaS To aLL of YoU/Us ^!^!^

angle11 · Post by **angle11** » 2018-01-03 18:36

Hi there .. is there a link to the 1.2.1.7 latest build to try it out ?? .. thanks

Post by **Rudi De Vos** » 2018-01-04 22:11

last test exe are from from december

https://www.uvnc.eu/download/1217/winvnc_zipthread.zip

A full installer will be shortly on the forum to testdrive

angle11 · Post by **angle11** » 2018-01-05 17:44

Thanks for getting back to me .. please let me know when you will be posting the whole exe file here ... any idea when ?? .. Thanks for all your time

Post by **Rudi De Vos** » 2018-01-10 20:35

Installer
https://www.uvnc.eu/download/1217/Ultra ... _Setup.exe
https://www.uvnc.eu/download/1217/Ultra ... _Setup.exe
All bins
https://www.uvnc.eu/download/1217/Ultra ... 17_ALL.zip

win8 = win8 and higher
If win8 version doesn't work, use the XP version. Some part of the win8 depend on the video driver and we can't check it during install

ddbivens · Post by **ddbivens** » 2018-01-11 02:50

Great!!! Thank you for the installers.
I saw the updated installers near the end of the workday and downloaded them immediately.
I put the new installers into my push folder and removed all the beta update files.
I pushed the new installers to a few PCs and began testing. Before I left for the day I had already pushed this update to about 40 PCs.
-
It seems that I am getting better performance from this version than I was getting from the latest beta updates. After the newest installers finished installing, I began connecting to the remote PCs and the initial screen draw was very fast. I did some comparison between two PCs (one with the latest betas and one with these installers) and it seems like today's updates drew the initial screen a lot faster. I installed to XP, Windows 7/64bit, Windows 8, Windows 10, Server 2003, Server 2012 and Server 2012R2. All connections to these PCs were very fast. I only did connection testing for the initial screen drawing and a few clicks. I did not do any other testing.
-
I did want to mention one thing. Don't make any changes for me because the current performance seems great. The one thing I saw was the VNCViewer.exe file date went from 12/7/2017 10:22:24 PM, 1,482,752 bytes (last beta version), to 9/25/2017 7:38:56 PM, 1,662,976 bytes (from today's installers). I am just mentioning this in case you were not aware of it. Again, please don't make any change for me.
-
Thank you for all your hard work on this program! It is truly outstanding.
[Edited to correct new file date to 9/25]

UltraVNC

UltraVNC 1.2.1.7 - Download links

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7

Re: 1.2.1.7