1.2.1.7

1.2.1.7

Postby Rudi De Vos » 2017-09-25 18:56

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/ultravnc1217.zip
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5442
Joined: 2004-04-23 10:21

Re: 1.2.1.7

Postby AnotherUVNCuser » 2017-10-01 13:20

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
AnotherUVNCuser
8
8
 
Posts: 31
Joined: 2017-09-13 00:40

Re: 1.2.1.7

Postby Rudi De Vos » 2017-10-01 14:42

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...
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5442
Joined: 2004-04-23 10:21

Re: 1.2.1.7

Postby AnotherUVNCuser » 2017-10-01 16:23

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 :wink: (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.
AnotherUVNCuser
8
8
 
Posts: 31
Joined: 2017-09-13 00:40

Re: 1.2.1.7

Postby Rudi De Vos » 2017-10-01 18:00

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.
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5442
Joined: 2004-04-23 10:21

Re: 1.2.1.7

Postby AnotherUVNCuser » 2017-10-01 18:28

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?
Last edited by AnotherUVNCuser on 2017-10-01 19:20, edited 3 times in total.
AnotherUVNCuser
8
8
 
Posts: 31
Joined: 2017-09-13 00:40

Re: 1.2.1.7

Postby Rudi De Vos » 2017-10-01 19:16

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
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5442
Joined: 2004-04-23 10:21

Re: 1.2.1.7

Postby AnotherUVNCuser » 2017-10-01 19:28

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

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).


Rudi De Vos wrote: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".
AnotherUVNCuser
8
8
 
Posts: 31
Joined: 2017-09-13 00:40

Re: 1.2.1.7

Postby Rudi De Vos » 2017-10-01 20:04

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
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5442
Joined: 2004-04-23 10:21

Re: 1.2.1.7

Postby AnotherUVNCuser » 2017-10-01 22:46

Rudi De Vos wrote: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 :|

Rudi De Vos wrote: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? :(
AnotherUVNCuser
8
8
 
Posts: 31
Joined: 2017-09-13 00:40


Return to 1.2.1.x

Who is online

Users browsing this forum: No registered users and 2 guests