UltraVNC 1.5.0.X-dev - Feedbacks

[Rudi De Vos]

Feedbacks for UltraVNC 1.5.0.X-dev in this topic.

UltraVNC 1.5.0.18-dev:
- https://uvnc.eu/download/1504/UltraVNC_15018-dev.zip
- https://uvnc.eu/download/1504/UltraVNC_ ... _Setup.exe
- https://uvnc.eu/download/1504/UltraVNC_ ... _Setup.exe

UltraVNC 1.5.0.18-dev - April 2025:
- Use single DLL instead of V2 version

UltraVNC 1.5.0.17-dev - April 2025:
- International keyboard fix

UltraVNC 1.5.0.16-dev - April 2025:
- Viewer defaults were not loaded
- Possible keyboard fix... to verify (+ěščřžýáíé=´)
- Rename authSSPV2 loggingV2.dll to fix eventviewer messages x64
- Echoserver fix
- Broken sc_20 build fix

Keyboard
- Option international keyboard need to be on server
- Only tested with a virtual Czech keyboard

Vieser defaults were not loaded, causing strange things like ini viewonly, wrong encode etc.

UltraVNC 1.5.0.15-dev - March 2025:
- FileTransfer: Buffer overflow and memory leak #254 fix
- Service added to settings
- Moving log file fix

UltraVNC 1.5.0.14-dev - March 2025:
- Slider fix
- DSMPlugin settings / MS-Logon settings (running standalone settings) fix
- Move logfile bugs (own message was no longer working) fix

UltraVNC 1.5.0.13-dev - March 2025:
- Move log file to the ultravnc.ini folder

UltraVNC 1.5.0.12-dev - March 2025:
- FileTransfer window size fix
- Microsoft Windows 7 crash fix
- Installer: add "runas admin" to settings shortcut
- Installer: copy .ini to ProgramData before starting the service

UltraVNC 1.5.0.10-dev - March 2025:
- Config DSMPlugin fix
- Apply save settings fix
- Clear Admin password also clear vnc password fix
- ISOtime in about window + max size smaller

UltraVNC 1.5.0.9-dev - March 2025:
- Installer popups removed
- Some settings were not saved correctly

UltraVNC 1.5.0.8-dev - March 2025:
- Save settings fix
- Typo
- Bluesky adding

UltraVNC 1.5.0.7-dev - March 2025:
- Commandline need to overwrite default values
- Setting dialog can run standalone
- Focus on host input field(viewer)
- Bug fixes

UltraVNC 1.5.0.5-dev - February 2025:
- Fallback to old folder when ultravnc.ini not found
- Commandline option have priority (Viewer)
- Fix encryption viewonly (VNC password)
- Settingsdialog fix enable/disable SettingsDialog cosmetics
- Fix Rules
- Check plugin arch (32/64) before use
- Allow chunked messages on TLS send and allow default client certs (#250)

UltraVNC 1.5.0.4-dev - February 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
- RealVNC udp port usage fix
- 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.

[Rudi De Vos]

I don't think the cpu of the viewer can have any influence. You can connect using unix/mac/ and all implementations are different.
It looks more like a network issue.

On of the dev pc is a 128core (amd hyperthread) and as viewer i use a i7, this works without an issue. (LAN connection)

[ddbivens]

It certainly might be a network issue. Your latest dev release has made a world of difference at work.
This new dev release makes it connect immediately to my new PC about 90% of the time. However, when I tried to connect from home to my new PC via a VPN connection, I still could not connect until I changed the encoding method to XZYW. Using that encoding I can connect and use the PC about 5% of the time. Hopefully, that will get better after I get my new PC fully setup and move it to a different location/network connection.

In doing this testing, I did seem to run into an issue. I launch UltraVNC in a batch file with the command line:
Start "UltraVNC" "C:\Program Files\UltraVNC\vncviewer.exe" /autoscaling /viewonly /encodings ultra2
I type in the Name or IP then the password. After I connected I looked at the connection settings and it is still showing XZYW encryption. That is what I had set manually using the "Options" button before I typed in the PCNAME/PW on a previous connection and is not starting in viewonly mode.
Have the VNCViewer.exe command line switches changed over time? Should the command line switches like: /autoscaling /viewonly /encodings ultra2, still work?

[Rudi De Vos]

ok, will check this.

[Rudi De Vos]

updated
When commandlines are used viewer doesn't load the option file.

[proger16]

In 1.5.0.4:
If you try to resize the File transfer window, then:
The Progress bar is overlapped by the History field;
The sizes of buttons change (reduce).
The same thing happens if you simply drag the File Transfer window onto a second monitor, which has a different display scale (I have 100% and 150%, Windows 10)

[VNCHELP890]

All these changes should really be reflected in version number changes.

Also, ran this fine on one PC.

Had an issue on my home PC, and cannot get out of the notification window. Might just try a reboot to make it go away. Hope it sticks.

Is there a way to add photos to this forum?

[Rudi De Vos]

img can be added from an external server
[img]https://.../a.png[/img]

[Ludovic]

You can publish an image with https:// link directly too.

[VNCHELP890]

Those are super clunky. Should be able to just copy/paste an image right here:

(image here)

[Ludovic]

You must to publish on the web:
- https://www.google.com/search?q=image+host

[VNCHELP890]

It breaks something with passwords, and leaves a dialog on the screen which does go away. I forget if a reboot fixes it or not, but I won't install this version anywhere else with this issue.

Should roll that fix and any others into a 1.5.0.5 build.

Thank you.

[Rudi De Vos]

VNCHELP890,

I need a little more info, a how to repeat is ideal


Release wil be 1.6.0.0,
1504 was used for internal tests and code was just updated without updating the version, now it's on the forum updates will get an higher number and some change info