UltraVNC 1.5.0.4-dev - Feedbacks

[Rudi De Vos]

Feedbacks for UltraVNC 1.5.0.4-dev in this topic.

UltraVNC 1.5.0.4-dev:
- https://uvnc.eu/download/1504/UltraVNC_1504-dev.zip
- https://uvnc.eu/download/1504/UltraVNC_ ... _Setup.exe
- https://uvnc.eu/download/1504/UltraVNC_ ... _Setup.exe

UltraVNC 1.5.0.4-dev - December 2024:
- UI update
- Moved ini file to programdata
- Bug fixes... see git
- Administration password

UltraVNC 1.5.0.3-dev:
- UI corrections

UltraVNC 1.5.0.2-dev:
- Merged IPv4 and IPv6 as single EXE with switch using a property setting
- Fix RealVNC udp port usage
- UI better layoput, icons

UltraVNC 1.5.0.1-dev:
- Revert fonts for FileTransfer
- Fullscreen add Chat FileTransfer to the topbar

UltraVNC 1.5.0.0-dev:
- Directx Reconnect fix
- Extra links added
- Text/version info fixes
- Replaced libs with vcpkg manager for easy maintenance and upgrades
- Stack corruption (#185)

UltraVNC 1.4.4.0-dev:
- Code cleanup
- Spellcheck UI
- Standardization of UI
- Use CertVerifyCertificateChainPolicy API to verify TLS certificate chain (#144)
- Use Ariel font
- VeNCrypt authentication with TLS encrypted transport (#142)
- WIP: RSA-AES authentication and encryption (#139)
- Fix typo: 'Repetear' -> 'Repeater' (#138)
- Fix Windows Recovery Environment (WinRE) 10 detected as unsupported
- Change name snapshot, so you can easy sort on date
- Use same omnithread for Server and Viewer
- Re-init D3D device in pre-update if invalid (#130)
- SC, added an try/catch to restore UAC if used.
- Add scrollbar to properties
- Fix: set groups defaults before loading, not after
- SC UAC reset fix
- Able to connect to Debian v12=bookworm (by WayVNC protocol) #133

Files are updated on change, check upload dates.
Please provide feedback on bugs, many things changed and we need to get it ready for release.

--------------------------
UltraVNC links (join us on social networks):
- Website: https://uvnc.com/
- Forum: https://forum.uvnc.com/
- GitHub sourcecode: https://github.com/ultravnc/UltraVNC
- Mastodon: https://mastodon.social/@ultravnc
- Bluesky/AT Protocol: https://bsky.app/profile/ultravnc.bsky.social
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc

[ddbivens]

Initial testing... The first build did not seem to copy (or create) the .ini file in the ProgramData\UltraVNC folder. I updated my batch program that runs the install to take care of this by creating the folder and coping the .ini file before it runs the UltraVNC setup program.

The current build does copy the .ini file, but if the .ini file already exist in the ProgramData folder, the installer does a hard stop with the window saying the file already exists, OK button. It seems the silent install still works, so it must bypass the window with the OK button.

I just disabled my batch code that created the folder and copied the ini file and did an install over an older version with the new build. The installer correctly created the folder in ProgramData and copied the .ini file.
I don't currently have any PCs without UltraVNC installed for testing.

I noticed the new version does not honor the .ini settings:

QuerySetting=4
QueryTimeout=6
QueryAccept=1
QueryIfNoLogon=0

to prompt to allow the connection. I have not actually tested any settings, I just noticed this one because I use it on my PC to give me a few seconds to reject an incoming connection.

Hope this feedback helps a little.
Thank you for all your hard work!!!

[Rudi De Vos]

Thanks for the feedback, the installer popups are temporal to now what the installer does in the background.
Will be removed in final release.

I will check the
QuerySetting QueryTimeout QueryAccept QueryIfNoLogon
parameters

[Rudi De Vos]

Found, the default action was not set, updated so in case no rule is set Query is added
Files updated

[SkyBeam]

Can de path to ultravnc.ini be adjusted? E.g. by command-line parameter?

Reason I am asking for is that I am running multiple VNC configurations in multiple folders. Up to now it was easy to separate the configuration as it was reading ultravnc.ini from the program folder.

[ddbivens]

I downloaded the 12/21/2024 release and installed it at home and on my work PC.
I was not prompted to allow the UltraVNC connection.

I ran uvnc_settings.exe to find the settings shown in your reply above and attempted to make two changes. I changed the Max CPU to 50 and I added a Query Message. The changes would not save. I thought this might be because I keep my .ini marked as Read Only to preserve my settings. But then I found out that uvnc_settings.exe is trying to save to the .ini file located in the Program Files\UltraVNC folder and not in the ProgramData\UltraVNC folder.
I removed the read only attribute from Program Files\UltraVNC\UltraVNC.ini file and the changes were saved to the Program Files\UltraVNC\UltraVNC.ini file. I copied that .ini file to the ProgramData\UltraVNC folder, stopped and started the service and I still was not prompted to allow the connection.

[Ludovic]

@SkyBeam: In this special case, I have proposed to Rudi, a new command line feature "-portable" to force ultravnc.ini in the same UltraVNC Server folder.

Important, since several years, Microsoft rules are to have not setting/log files in "Program Files" or "Program Files (x86)":
%ProgramData%
%AppData%
%LocalAppData%
%Temp%

[Rudi De Vos]

uvnc_settings.exe still require an update it need to become the same as the current tabbed settings from the systray.

For the query settings you have a test button (systray settings) you can enter an ip or hostname and check what the result would be with the added rules
see previous screenshot
Check Rules [ ] Check Button Result

[SkyBeam]

@SkyBeam: In this special case, I have proposed to Rudi, a new command line feature "-portable" to force ultravnc.ini in the same UltraVNC Server folder.

Important, since several years, Microsoft rules are to have not setting/log files in "Program Files" or "Program Files (x86)":
%ProgramData%
%AppData%
%LocalAppData%
%Temp%

Fully understood and absolutely agree that storing settings in program folder is the wrong approach. For system services only %ProgramData% is the right location actually. %AppData% and %LocalAppData% is suitable for user instances only.

UltraVNC up to now perfectly allowed to have multiple services registered and simply locate them in multiple installation folders to use separate settings. A command-line parameter to specify location of ultravnc.ini would even allow to register multiple services with different configuration but keep the binaries installed only in single location.
Not sure if "-portable" is better here was a more generic "-settingsLocation %ProgramData%\UltraVNC" parameter would be more flexible and generic so it would allow to specify the folder in which UltraVNC will have to look for settings (currently only ultravnc.ini but might be additional ones in the future). This would also cover the portable use case where simply settings '-settingsLocation "%~dp0"' in launch script could redirect path to the local installation folder. Or just any path where you want to store the settings. Not just limiting to either %ProgramData% or the winvnc.exe folder.

Sure this parameter is require for WinVNC.exe as well as for uvnc_settings.exe to assure the correct settings are edited.

[Rudi De Vos]

Mutiple services registerd: Is this how the multple instances are used, not manual starting several servers with the -multi option?

[SkyBeam]

Mutiple services registerd: Is this how the multple instances are used, not manual starting several servers with the -multi option?

In my case I do have a use-case where I do create a dedicated "Support" service which is configured to use a reverse connection to allow connections from behind NAT. This support service is configured to allow users without admin privileges to run it.

Some of the machines still have UltraVNC server or client installed, some don't. If the server component is installed in parallel to this support service it just works fine unless both services are active at the same time.

Essentially this Support service is a complete copy of UltraVNC installation folder with a specific ultravnc.ini and a service registered dedicated to this instance. So this illustrates how those two instances (might be even different versions) require different ultravnc.ini. If the path would be hard-coded it would be impossible to use different configuration in terms of relay and ID configuration in "service_commandline" options.
Allowing to specify the path to configuration (ultravnc.ini) would in contrast offer the option to use a shared installation for multiple services. So depending on the service command line another INI could be read.

[Rudi De Vos]

There are 2 different cases:

Multiple apps
This can be solved using winvnc.exe -config filename ( filename need to entered c:\xxx\yyy\abc.ini)

Multiple service
In this case we could use the "special_service_name" without the need to add extra parameters, a service is unique
%programdata%UltraVNC\ultravnc.ini
%programdata%UltraVNC\special_service_name.ini
Then each service can have his own ini file

[SkyBeam]

There are 2 different cases:

Multiple apps
This can be solved using winvnc.exe -config filename ( filename need to entered c:\xxx\yyy\abc.ini)

Multiple service
In this case we could use the "special_service_name" without the need to add extra parameters, a service is unique
%programdata%UltraVNC\ultravnc.ini
%programdata%UltraVNC\special_service_name.ini
Then each service can have his own ini file

Yes. a service name is unique. However users might not want to be enforced to store the configuration files in %ProgramData%\UltraVNC due to reasons like branding or also I might imagine use-cases where ProgramData might not exist or hard to pre-provision like in Windows PE environments.

Though a possibility might be to implement a fallback scenario:

• look for %ProgramData%\UltraVNC\<service-name>.ini
• look for WorkingDir\<service-name>.ini
• look for WorkingDir\ultravnc.ini

However I think it's perhaps more complex than just using a parameter to specify the location of configuration files and default to %ProgramData%\UltraVNC.

[ddbivens]

I use "uvnc_settings.exe" because I keep the tray icon hidden so I look forward to "uvnc_settings.exe still require an update".

I unhid my tray icon and rebooted my PC and Restarted UltraVNC service then the "Setting" button would work.
I clicked on Rules, checked the Popup a timed messagebox.... added 6 seconds and delayed 1 second, changed to Accept and APPLIED.
I disconnected UltraVNC and reconnected UltraVNC and was not prompted to allow the connection. I was also connected to my PC via TeamViewer and was watching the screen.

[Rudi De Vos]

service will be changed like this

%programdata%\UltraVNC\ultravnc.ini
but when you install it with another name sample: "myvnc_service"
%programdata%\UltraVNC\myvnc_service.ini
is used

When not found it fallback to current folder

This should do the trick for multiple installed services

[SkyBeam]

service will be changed like this

%programdata%\UltraVNC\ultravnc.ini
but when you install it with another name sample: "myvnc_service"
%programdata%\UltraVNC\myvnc_service.ini
is used

When not found it fallback to current folder

This should do the trick for multiple installed services

Yes I think that should do it. Assuming "myvnc_service" is installed in "%ProgramFiles%\myvnc_service" it could still bring its own configuration inside the folder. Your answer however does not clearly state if the fallback in this case is "%ProgramFiles%\myvnc_service\ultravnc.ini" (as I assume) or "%ProgramFiles%\myvnc_service\my_service.ini".

If ultravnce.ini is searched in installation folder this would be fine and also not break any existing implementations.

Howerver I still see a questionmark how uvnc_settings.exe would then edit the right settings if there is no parameter here. As uvnc_settings.exe does not know about the service name it would not know which settings file to edit - would it?

Well, in my special case it wouldn't matter so much as ultravnc.ini is static for the service. And if I would have to edit it I could use ultravnc_settings.exe and then copy over the ultravnc.ini it is modifying. It's pretty rare I have to do this on a client without shipping a new client installer updating the service. So for me the algorithm above is not a problem. For others however it might if they want to use ultravnc_settings.exe in a custom service folder.

[ddbivens]

Update: I downloaded the latest dev and retried the Rules to setup my query. It works just like it is supposed to work. I had Apply(ed) the settings but I had not clicked the Add button. My bad. Thank you!

Also, I wanted to thank you for another change in 1.5.0.4 where the viewer remembers the screen options and after a disconnect/reconnect. This change means I am still looking at the same view (3 monitors on my monitor) that I was looking at before the disconnect. This helps a lot like when I am remoting into PCs, installing updates, rebooting, reconnecting, repeating. Thank you!

[ddbivens]

I have some new information. I am getting a new PC at work. An i9, 14th gen, 32Gb, and 24 core, 32 logical core. The reason I mention the specs is because they might be related to the problem I am having connecting to the new PC. I have tried to connect from an older, low end laptop, Win10, an i7, earlier gen, 32Gb, Win10, desktop, and an i7, later gen, 16 Gb, Win11, desktop. They are all having the same problem connecting to the new PC. The initial connection is showing a gray screen for minutes. Even after the desktop icons show, nothing works. Clicking on anything on the viewer, even the local menu, will get "not responding" every click or every other click. Even trying to close the viewer fails. I can minimize the viewer and come back to it in 10 to 30 minutes and everything works great. I can connect to any other PC or number of PCs, before, during or after and that/those viewer(s) works just as expected.

After waiting for a length of time, I used the VNCViewer and worked on the new PC for about 1 to 1.5 hours and suddently the the viewer changed to 'not responding'. I minimized the viewer and came back in a half hour or so and everthing was fine again. Anytime the new PC reboots or if the viewer disconnects and reconnects to the new PC, I get the same results.

The only other i9 in the office can connect to the new PC and everthing connects perfectly and there are no delays or issues.
Is it possible that the i7 and older PCs are having a handshake or syncing problem with the very fast, new PC?

BTW, I tried the newest dev release and older Ultravnc releases on both the old PCs and new PC and I got the same results.