update 1.1.9.4 ( tests )

[Rudi De Vos]

Before webpage are updated, versions are in test.
Please notify us if something doesn't work, a urgent feature request etc.

vncviewer: mod for vmware ( wrong colors)
server+viewers: update libjpeg-turbo update from 1.1.0 to 1.3.0
w8hook mod + server mode to increase FPS for win8

http://www.uvnc.eu/1194/

[twagner]

if i start a ultravnc session normal without any codingoption (both win xp sp3 x86 - securevncplugin - mirrordriver) it works,
but i can`t change the coding to tight.
if i start the session in the option with tight coding the vncviewer crashes

twagner

[Rudi De Vos]

Thanks for the feedback
There is indeed a change how the viewer handle tight encoding as vmware seems to use tight encoding
as soon as the viewer notify the server that he support it.

Perhaps i need to make changes as you can't switch to tight onces initialized.
Add vmware as encoding so it exclude tight only in this case...

[twagner]

than good luck to find a little place on the option windows

[Rudi De Vos]

seems the new jpeglibcrash...

[Rudi De Vos]

files reuploaded, error in new lib fixed

[twagner]

the new (uploaded) viewer (20131016) don`t crash, thanks
But.....
i can`t find the vm-tight option, you have written, because i have al lot of vm`s or have i something overlooked .....
i can start with the tight-coding and change to ZRLE or hextile, but i can`t change back to tight-coding-option, too
and what is the different between ultra and ultra2, both produce more than 150 KB/s (1280x1024, your mirrordriver installed, xp sp3, both) in the eval-pc in my company LAN,
so i need the option to switch (back) to tight or back to the tight-coding in a running vnc-session

twagner

[Rudi De Vos]

Just fixed the jpeg lib, tight encoding still need a review.
Tight can only be tested by setting it fixed.

ultra= use lzo encoding, this is a very fast compressor, but compression ratio is low (10-50/100)
ultra2= use jpeg, this allow you to show HD video's with a 20FPS.
compression/decompression use mmx/sse/sse2 accelerated codecs
compression ratio is high ( depend on the jpeg quality factor you set in the option).
Images are compressed to 2-5% of there size. But indeed, when you show a fullscreen
video it can use several MB/S

[Rudi De Vos]

reuploaded the viewer

tight is also fixed
i just reactivate it when you open the options, it seems to work even with vmware.

[twagner]

viewer work normal, tight coding can be changed in both way`s
vmware (6.5.5 with vmware tools = @home) don`t work, but can be that the mistake are on my side, ping OK, port 5900 free, no dsm plugin used but no connect ==> "Failed to connect to server !", uvnc on port 5910 inside the vm work...
ultravnc looks good and stable how ever!!!! great work

[Rudi De Vos]

reuploaded with modified viewer.
This viewer handle a lowbandwidth issue where the viewer locked after sending
the password and before getting the first screen

viewer can also be downloaded as seperated zip
http://www.uvnc.eu/1194/vncviewer_test_lowband.zip

[hobo12]

When I try to connect to a Win8 or 2012er host running the newest test version 1.1.9.4 and Win8 HookDll, then WinCNC.exe crashes imediately. I have tested on three different systems - 2 virtual and 1 physical one, all with same result. Disabling the HooDll support fixes this as workaround.

For now I returned back to 1.1.9.3 on these systems which is working correctly again.

[Rudi De Vos]

Thanks for the feedback.
Newest X64 win8 bins are compiled using the new VS2013 compiler.
It looks like some optimization options are not 100% compatible.

I need to check the dll's again, only tested the exe.
Did you used the hookdll from the new download or you just replaced the exe for testing ?

[hobo12]

As requested I did some further tests with replacing individual exe files etc.

The result was an issue with the new compiled w8hook64.dll. Finally after installing newest Version 1.1.9.4 I just replaced the new w8hook64.dll by the old one from 1.1.9.3 and all is working fine.

[Rudi De Vos]

Addons64 updated , pointer error

[Rudi De Vos]

Some options are being removed from 1.1.9.4
Capture alphablending: This should always be on when the OS has semitransparent windows.
Based on the OS and aero settings it's better to auto set this and removed it as user options.
Screen blanking: The powsersave/layered window options seems to be complex and they don't work in all cases.
trying to automate it.

[Prisma]

I'm not completely sure, but haven't some AV scanners used semi transparent windows for their systemtray popups and configuration, have they? Even under XP? Switching off capture alphablending for OS lower than Vista would mean these windows are unvisible. Or am I wrong, and semi transparency is a Vista+ only feature?

[Rudi De Vos]

That's how it's implemented for the upcoming 1194 version.

transparent window support

w2K -> always off, doesn't exist
xp -> always on
Vista/win7 -> on if aero is disabled, no layers with aero on
win8 -> always off, layers are absoluted

screen blanking

w2k -> power saving, this doesn't work 100%
xp -> use the bmp screen as overlay
Vista/win7 -> use the bmp screen as overlay ( aero is disabled to support layered windows)
win8 -> no supported, still looking for a proper way

[Prisma]

THX for info.

[plants]

Hi Rudi,
A quick note following a test this evening, once again using the server-initiated reverse connection method

Working Parameters:
Win7x86 Server 1.1.9.4, Ethernet Connection, Recent Integrated AMD Radeon, 1920x1080 viewport -> Win7x86 Viewer 1.1.9.5 Wifi Conn. (v. near router) - basically the latest test versions
Note: Using only vnchooks.dll, not schook and no encryption, as it's not working anymore (that's a separate issue which I want to test exhaustively before reporting it as a definite problem )

Active server settings were PollFullScreen and EnableHook under Poll section and DisableEffects and RemoveWallpaper. All those = 1, other visual settings = 0

During the first moments of the session, Windows reported that the desktop window manager had exceeded the allowed memory and was to be closed; the remainder of this part of the session continued with Aero disabled
About 5 mins later, the viewer locked up for no obvious reason and had to be forced quit, however the server detected the loss of connection and closed normally. When resumed, the next session appeared to be completely stable, average bandwidth was in excess of 1300 kbps. Aero still disabled

At this point, I wanted to reproduce the excessive memory usage seen earlier in the DWM process. The server settings were changed to DisableEffects=0, and the server was stopped and restarted, in the hope that Windows might re-enable Aero of its own accord. No change. However, I was able to reactivate Aero by choosing an Aero theme from the Personalize panel...

Once Aero was enabled, the DWM process' memory usage went mad, swinging between 30Mb to in excess of 500Mb and constantly changing, despite a relatively static screen (just a ProcessHacker window and the DWM process' Performance graphs. No alert messages were seen, even after 2 minutes of crazy numbers, and Aero persisted

I inspected the memory usage readout for the server after the session, no unusual behaviour and typical memory usage for the screen size and the encoding method (Auto=u2)

I hope this helps
T

[Rudi De Vos]

The screen detection and data transmission happen simultanious and independed.
You can influence the detection frequency by lowering the max cpu ( polling server option, default this is set to 40)

Try to set it to 5, vnc make internal changes to try to keep the cpu below 5% this can take 60 sec as parameters are slightly changed /update cycle.

The visual effect of aero create lots display changes and all need to be send to the viewer.
Aero off while connected makes it 4x faster, but on is a good way to stress test the system.

500MB for wdm isn't that big during graphic intens application, it keep buffering if it can follow.
Vnc is copy several times a second screendata from video to system buffer.

[Prisma]

Excuse the inappropriate question: Is there a time line for 1.1.9.4 to become stable and to be released?
(we plan an update for the next days and the question is, whether we take 1.1.9.3 or 4 to ship with)

[Rudi De Vos]

Website release december, it wil be released as 1.1.9.5

1.1.9.4 server and viewer are stable but i still need to make
changes to the buildin java viewer.

Also the X64 builds win8 (support Vista-win8)
are now compiled with parallel processing ON.
New option in VS 2013.

I prefer to wait a month to be sure no unexpected crashes happen.
New compilers and options sometimes behave a little different.

[Prisma]

We always take only the x86 builds, and the winvnc build for win2000 only. So... x86 1.1.9.4 should be OK because stable, right? Or should we also wait until December or better take 1.1.9.3?

[Rudi De Vos]

Test server
http://www.uvnc.eu/1194/winvnc_java_singleport.zip

1)single port: The rfb is also the java port
you do not use 5900 and 5800, but the same port is used for both
Sample= if you set rfb to 80, you can connect with the browser to port 80
2) Java not signed and missing manifest should be corrected

[Rudi De Vos]

1194, better wait a few days then i will build a 1195 w2K server and viewer to include, else you have back an old version in a few weeks

[plants]

The screen detection and data transmission happen simultanious and independed.
You can influence the detection frequency by lowering the max cpu ( polling server option, default this is set to 40)

Try to set it to 5, vnc make internal changes to try to keep the cpu below 5% this can take 60 sec as parameters are slightly changed /update cycle.

Hi, what is this max cpu of which you speak?!
I seem to remember a setting, in the poll section? What's the exact parameter name, please?

[Rudi De Vos]

Max Cpu: gui
MaxCpu ultravnc.ini

[egal8888]

Using the latest 1.1.9.4 you cannot login to a windows 7 x64 pc that is running a screen resolution of 2550 x 1440 px.
The UltraVNC client closes immediately after having logged in and trying the same in a browser window using the Java Client results in the following error message:
Error: Width (0) and height (0) cannot be <= 0

You already fixed this bug in previous versions but in 1.1.9.4 it is there again.

Could you please provide a fix for it.

Thanks in advance


edit:
If you use winvnc.exe 1.1.9.3 as Server service and vncviewer.exe 1.1.9.4 aka 1.1.9.5 as client, everything works fine.
So the bug is only related to winvnc.exe 1.1.9.4

[Rudi De Vos]

Can't find anything "code differences" that could cause it
what settings you are using
ultravnc.ini
viewer options
But some bugs are cause by timings, multiple program parts run simultanious... some bug could be that we didn't
added some correct sync code.

2550*1140 is that a dual display do you see desktop 1 and 2 or a single desktop ?
Are you using primary=1 and secondary=1