1.2.1.7

[Rudi De Vos]

The new jpeg-tubo library behave bad when compiled with VS2010, but this compiler is required for a stable XP versions.

Updating all to 1217
-with older jpeg lib
-XP build with VS2010 all other with VS2017

This thread contain the links to the 1217 releases, to be tested before updating all to 1217
I have been testing this builds and all seems to be stable

please test, special with encoders that use jpeg ( tight/ultra2) and the folder filetransfer

Downloads XP ( only winvnc.exe and vncviewer.exe) works on all OS's but are specific build to support this older OS.
To test rename old exe and replace.

https://www.uvnc.eu/download/1217/ultra ... 7_2611.zip

[AnotherUVNCuser]

Hi Rudi,

Thank you for the new version, i'll do some testing

And before updating everything to 1.2.1.7 i would like to notify you about a problem/bug i found in both 1.2.1.6 and 1.2.1.7, that is related to the Windows task scheduler:

Thread: http://forum.ultravnc.info/viewtopic.php?f=3&t=33322
Video: https://www.youtube.com/watch?v=P4tpjXDbGX8

[Rudi De Vos]

Perhaps this is what you want to say.

1) winvnc.exe -connect host: inject himself in a running winvnc
2) winvnc.exe -connect host -run: start winvnc and make an outgoing connection
3)ultravnc.ini
service_commandline = -autoreconnect -connect host

If you net start uvnc_service, then the service execute the service_commandline from the ini file.
The service makes an outgoing connection. The autoreconnect just keep trying...

[AnotherUVNCuser]

Not quite..

I will be using WINVC as service, but when using Windows's task scheduler you can set other options too.

Only, i'm uncertain if those options (which i'll explain below) can be set in ultravnc.ini => service_commandline=:


1. Run UVNC service at system startup without logged on users
2. Check hourly if a connection/session is active (i use my self compiled .exe for this which does a netstat -n | FINDSTR ESTABLISHED | FINDSTR PORT#)
3. If no active connection/session is found, do a reverse connect, otherwise wait for another hour and do a new check

Can all this be done from service_commandline =? I (highly) doubt it (which is why i decided to create an .exe)

Since winvnc seems to ignore the commands from my .exe, i'm assuming this is caused by a bug.
(with TightVNC it works, but i prefer to use UltraVNC because of the better/more options it has)

Hopefully you can take a look at it, since i can't program/code myself. Though i'll have a peek at the source later on.

[Rudi De Vos]

That's indeed what the service command does.
-autoreconnect -connect host

The service start in an endless loop a reverse connection to viewer, and when the connection breaks it's auto restarted.

[AnotherUVNCuser]

I know that.. but is it possible to set a delay between the connection attempts? e.g. -autoreconnect 3600s or 60m or 1h for 3600 seconds, 60 minutes or 1 hour.

I would like to be able to set a delay, if possible.. If this can't be done, hopefully you'll consider implementing it for both service_commandline= and as standalone .ini option (i.e. autoreconnect_delay=60m).

ps: Is the problem with the .exe i mentioned earlier a bug?

[Rudi De Vos]

There is no delay option.
It use the socket timeout or direct reconnect after viewer is closed.

This option was made to connect to a repeater ( both server and viewer do an outgoing connection)
server connect to repeater and wait for viewer connection
In that case you want to be continuous connected to the repeater so you can view in when you want.

cmd viewer -listen
test 1
winvnc.exe start manual
cmd
winvnc.exe -connect localhost
OK
test 2
winvnc.exe installed as service
net start uvnc_service
cmd
winvnc.exe -connect localhost
OK
Both connect
tested with and without trayicon

I tried to understand what the scheduler is doing different.
-Does it run as service, in what session is winvnc started, wht security context is used

[AnotherUVNCuser]

Via commandline it all works correctly yes, but i prefer to do it via task scheduler and ultravnc.ini

Do you know if the selfcompiled .exe is failing because of a bug in UltraVNC, or aren't you sure?
I really want to find out but i'm lacking the developer skills...

(i'm sorry if i'm bothering you with this question too much, i'm trying to understand why it doesn't work).

I tried to understand what the scheduler is doing different.
-Does it run as service, in what session is winvnc started, wht security context is used

The Scheduler is executing the task as SYSTEM user (session 0 i believe), winvnc is running as service and is started automatically by the Windows Services menu (services.msc).
I don't know what you mean by "what security context is used".

[Rudi De Vos]

Just tested and code is ok

Code: Select all

#include "stdafx.h"
#include "windows.h"


int main()
{
   system("C:\\Users\\rudi\\Desktop\\UltraVNC\\winvnc\\Release\\winvnc.exe -connect localhost");
    return 0;
}

Winvnc.exe running in session0 is the service and messages are blocked
WInvnc.exe running is the desktop is the app and can receive sendmessages

When you execute winvnc.exe -connect host then winvnc does a findwindow( vnc class) and
a sendmessage ( code, ip , port) to the running winvnc.

The problem is that the schedular does winvnc.exe -connect in session0 and never reach the running winvnc app.

This is not a bug,

A solution todo what you more or less want
ultravnc.ini
service_commandline = -connect yourhost

Code: Select all

int main()
{
   system("net stop uvnc_service");
Sleep(5000);
system("net startstop uvnc_service");
    return 0;
}

You schedular restart the uvnc service and the service try to connect one time to your viewer

[AnotherUVNCuser]

Just tested and code is ok

The problem is that the schedular does winvnc.exe -connect in session0 and never reach the running winvnc app.[/b]

This is not a bug,

Even not when winvnc is running as service? This makes me wonder why TightVNC works without problem, when we're still using the same code

A solution todo what you more or less want
ultravnc.ini
service_commandline = -connect yourhost

Code: Select all

int main()
{
   system("net stop uvnc_service");
Sleep(5000);
system("net startstop uvnc_service");
    return 0;
}

You schedular restart the uvnc service and the service try to connect one time to your viewer

I was thinking of almost the same workaround, and this indeed works, but do you have ANY idea why TightVNC (as service) has no problem executing a -connect, that is issued by the task scheduler, as SYSTEM (session 0) user/account?
The .exe of mine works with the new code, but i still consider it a workaround, because there's (currently) no other way of doing it.

Call me stubborn, but... if TightVNC can do it, why can't UltraVNC do it as well?

[Tki2001]

Maybe TightVNC is not trying to locate its settings via the account it is installed upon. If a program does something, another one may, very well, do not do the same thing!.
Some special accounts on Windows have special folders on system, and SYSTEM is one of them. That's why if you try to run a program under the SYSTEM account won't find its configuration files on the normal folder, they will be located under the SYSTEM special folder.
If you try to run ultravnc under the SYSTEM account, then try to find a method to install UltraVNC under the SYSTEM account, and surely it will be fine to run, but truly not advisable.
Or run the task under the same user, ultravnc was installed with.

[AnotherUVNCuser]

Maybe TightVNC is not trying to locate its settings via the account it is installed upon. If a program does something, another one may, very well, do not do the same thing!.
Some special accounts on Windows have special folders on system, and SYSTEM is one of them. That's why if you try to run a program under the SYSTEM account won't find its configuration files on the normal folder, they will be located under the SYSTEM special folder.
If you try to run ultravnc under the SYSTEM account, then try to find a method to install UltraVNC under the SYSTEM account, and surely it will be fine to run, but truly not advisable.
Or run the task under the same user, ultravnc was installed with.

Interesting read. Thanks

Updated server to avoid viewer timeouts

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

That's wonderful! I'll test this ASAP
I'm grateful for your contineous dedication/efforts to improve the program, after all these years. Much admiration/respect Rudi

edit: Will you compile/release a 64-bit binary too? (because i'm deploying files to architecture specific folder locations and prefer to run 64-bit binaries on 64-bit systems)

Best regards,
AnotherUVNCuser

[nzsolt]

Hi,

with this latest exe the compressed folder put/get is not working on XP,
and the folder get from remote server to viewer is not working on Win10.

[Rudi De Vos]

The problem is that we need to use diffrent compilers for different OS's and test are made fast...

To avoid confusing, i gonna add some OS check based on the used compiler, so at least you get a message that this exe
was not made for XP

[nzsolt]

It's ok why xp is not working, but on Win10 it should be working, not?
The folder putting is working but the folder getting is not working.

[Rudi De Vos]

Test bins all
XP x86
WIN7 x86 and X64
WIN8 x86 and X64

WIN7 use standard capture method, also run on win8 and win10
win8 user desktop duplication capturing ( faster, but require wdm 1.2> drivers) win8 and win8
XP run on all OS's

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

[nzsolt]

Thanks for builds!

I have tested the folder file transfer with the X86 builds
- the xp version works fine on XP,
- but all other exe (W7 and W8, and XP too) have problem with the folder sending on vnc server side on Win10.
Maybe the folder compression is not working in winvnc.exe? (except in XP version on XP)
The folder getting is working, the winvnc.exe can decompress and create the folder with files what was sent by viewer.

[Rudi De Vos]

just tested on win10 and folder transfer seems to work.
Fast tested in loopback mode, copy folder from c: to d:

server win10 (win8 build) viewer win10 win8 build
server win10 (xp build) viewer win 10 xp build

copy viewer to server OK
copy server to viewer OK

win 10 1703
os build 15063.726

Can you test on another server

[nzsolt]

If the winvnc,exe runs as app, it uses the APPDATA folder for creating the temp zip file and everything is working.
But if winvnc.exe runs as a service, it uses the c:\windows\temp dir, the zip is created,
but the vnc server says it's size is -1.
Maybe it can not read after compressing or the path is wrong somewhere?
This was tested on 2 different Win10 (Home32, Prof64) with same result.

[Rudi De Vos]

ok, tested as appliaction, wil do it again as service

[Rudi De Vos]

As service i get an error
Transfer folder from server to viewer

#impersonate ON
c:\windows\temp\... is not acessible...
#impersonate OFF
ok

Looks like the impersonated desktop user has no access to the temp.
Perhpas in old days this was an open folder, but now it seems to be restricted to the system

Looks like we need a temp folder to create the folder zip that's global writable.

[nzsolt]

Usually we use a custom folder in //CSIDL_COMMON_APPDATA = $0023; { All Users\Application Data }

[Rudi De Vos]

I was using GetTempPath(), but this seems to be unaware of the impersonation...
It return the correct path for the system, but it should return it for the imperonated desktop user
c\windows\temp

ExpandEnvironmentStringsForUser(hPToken, "%TEMP%", m_szTempDir, MAX_PATH);
it return the correct path of the desktop user
c:\users\rudi\appdata\local\temp

Made changes

[Rudi De Vos]

server win32 win8>=
Test version seems to work on my pc, please verify as service

https://www.uvnc.eu/download/1217/winvn ... ertest.zip

[nzsolt]

It seems it is working

[ddbivens]

I had tested file transfers with the 11/21/2017 update with folders/files from my Windows 7 64bit PC from/to Windows XP, Windows 7 64bit, and Windows 10 64bit systems. All worked except receiving a folder from a Windows 10 64bit system. Nothing would come through.
Tonight I tested the 11/22/2017 winvnc.exe update (on the Windows 10 system) with folder "UltraVnc_1217" from my Windows 7 64bit PC desktop from/to Windows 10 64 bit system desktop. The folder would send to the Win10 system desktop as expected. I renamed the folder to "UltraVnc_1217 rep" on the Windows 10 desktop. When I did a receive of the folder from the Windows 10 system, I would end up with a Zip file on the Windows 7 desktop named "Temp!UVNCDIR-UltraVnc_1217 rep.zip". I tried this several times and got the same results.
As always, just trying to help.
[Edited to correct zip name]

[Rudi De Vos]

forgot to a \ after the path, now it use tempfilename intsead of ..temp\filename.zip

[ddbivens]

Thank you.
I will be glad to test the new update when released...

[Rudi De Vos]

Once confirmed working i will build all version, current it's win 10 32bit

https://www.uvnc.eu/download/1217/winvn ... rtest2.zip

[ddbivens]

(Sorry, looks like I double posted the following message.)