VNC Client

An RDP server for RISC OS might be good!

An up to date RDP Client would be nice! Andrew Sellors’ one still works but has no sound and is a bit long in the tooth. Attempts at rebuilding seem to break things, but the source is available if anyone wants a go!

Perhaps it’s linked to the fact that I have also some RDPClient session running.

I confirm: it happens when both are running.

An up to date RDP Client would be nice!

Yep. rdesktop source is old, but an up to date version with more optimizations would be great.

I confirm: it happens when both are running.

I also have problems when using both RDPclient an Avalanche at the same time. Some cut and paste actions in the RDP window cause Avalanche to crash out.

I am not using RDPclient, but do have random issues with Avalance v0.25 controlling a Win10Pro desktop or a Win10 pro Laptop, one of them uses UltraVNC and the other uses TightVNC, makes no difference and made sure by updating both the latest releases. Seems to be an issue with using a web browser (Chrome usually) dragging the slider bar to scroll down or expanding the window, Avalance will suddenly at random disappear, but no error message and nothing I can see in the log files as to why. Oddly It seemed more stable with the older v0.22 of Avalance. Odd.

I also have problems when using both RDPclient an Avalanche at the same time. Some cut and paste actions in the RDP window cause Avalanche to crash out.

We’re not into this territory by any chance?

If both Avalanche and something (anything) else on the system are doing clipboard tracking by asking to claim the clipboard as soon as anything else does, then as soon as either one of them follows through on that request, there’s a 50% chance that some applications will complain about protocol violations.

That’s well written apps, too. Those that don’t bother to check the message references could do almost anything…

Other possible sources of conflict include Clipper (unless you have the latest test build), UniServe (when not on Select), The Clipboard Holder (on Select) and ClipMan. All of these are employing some form of clipboard following technique, and only one thing can do that at once on a system unless they do what Clipper now does in that test build that I mentioned (see here for details).

I have encoutered the issues Steve F has highlighted with the Clipboard while using Avalance v0.25 and the VNC server on the PC. IIRC it was a fight between UniServe and the clipboard being used by the VNC server/client. I note in Avalance choices there are some options relating to Clipboard use. Also the help file for Avalance warns there is limit on maximum transmitted text size.

I think there are definitely some fun things going on when there are multiple things which want to immediately request the clipboard as soon as anything claims (copies to) it. Locally I was able to reproduce the “Message protocol failed” error from Schema2 by running two copies of Avalanche, with open connections. If RDPClient, or anything else also immediately requests clipboard contents, which I could believe then this may well be a reproduction case.

What looks to be happening is that there are two Wimp data transfer protocol processes which are interleaved and one of them is failing. Removing either of the “pasting” applications would prevent this.

I need to go through the message trace in detail to confirm.

We’re not into this territory by any chance?

Yes, I believe we are…

On receiving a Message_ClaimEntity for the clipboard, version 0.26 delays sending Message_DataRequest until the next poll, which should stop Avalanche contributing to the problem. Since this bug is a team effort, see the link in Steve’s post for a good description, depending on what else you are running it won’t necessarily eliminate it.

https://github.com/effarig/ro_avalanche/releases/download/v0.26/avalanche.zip

If Avalanche was “crashing out” then I suspect there is another bug in there somewhere.

The message is (almost) completely gone now!
Next bug, the “I open sessions in small windows” (and not full size).

A bit more information would be useful so I can reproduce it.

One thing I noticed is that if you have a session with the auto-scroll option enabled and an unmaximised window. Then start a drag and move outside the window into a different (toolbox?) window below the Avalanche window and wait for auto-scroll to scroll as far as it can vertically, then a wimp error box pops up with and “Not a toolbox task” and Avalanche exits.

I’ve noticed this happening if the auto-scroll pointer is moved into Avalanche’s own status bar, or !Configure, but not with !Zap, the Pinboard etc.

This is very reproducible, but I’ve yet to workout what is happening.

@James: Thanks for updating Avalanche – v0.26 working here with the new vncserv v0.22. One small suggestion: please could the ‘Toggle Size’ icon toggle between the minimum size and the maximum please? Currently it just always reduces to the minimum size for me, and never enlarges.

One small suggestion: please could the ‘Toggle Size’ icon toggle between the minimum size and the maximum please? Currently it just always reduces to the minimum size for me, and never enlarges.

Strange. It works for me. (same versions 0.26 and 0.22)

Toggle Size’ icon toggle between the minimum size and the maximum please?

There have been a couple of requests along these lines, I’ve not forgotten but I’m still focusing on stability.

It would be useful to get more precise use cases though, in particular is this when scaling to the window size, or a fixed scale factor (100%, 67%, etc…)?

These are two very different cases as in the case of scaling to the window size, at present the window is always in effect maximised which means the toggle size icon doesn’t really work in any useful way by default.

Usefully, the Wimp informs tasks when toggle size was used which makes it easy to alter the behaviour and I’ve been playing this a little. My initial idea is that when scaling the view to the window, the toggle size icon would toggle between 100% and the previous scale factor/position.

If the scale factor is fixed, i.e. not fitting to the window, then the normal Wimp toggle size behavior would remain.

What do people think?

These are two very different cases as in the case of scaling to the window size

Who doesn’t work here (the window is never maximized when I open a connection).
Nota: I use a very big screen mode (2540×1440).

Re: Togglesize not working

Strange. It works for me. (same versions 0.26 and 0.22)

Very strange. Here, using RO5.29 and 1920×1080, it seems to open a session at 12% (regardless of the View config). It can be dragged larger, but the toggle-size icon is always a downwards arrowhead (ie reduce), and indeed whenever it is clicked it reduces back to 12% again.

…but the toggle-size icon is always a downwards arrowhead (ie reduce), and indeed whenever it is clicked it reduces back to 12% again.

Yes, so what happens when scaling to fit the window is that when you resize the window, the extent of the window is set to the visible area, so you can’t scroll.

This means that from the Wimp’s point of view the window is always maximised, which is why the toggle size icon always “shows reduce”.

This isn’t the normal way a window would behave, but it sort of makes sense in this case as we are scaling the content of the window to fit the visible area. As I mentioned above, it looks to be relatively simple to redefine what the toggle size icon does in this case, so this could be improved. Exactly what should happen however probably depends on your use case.

From my use case, I sometimes have a couple of sessions open but scaled right down. If I want to use one then clicking toggle size to set it to 100% and open up the window accordingly would be useful. Then once finished, clicking again could return the window to its previous scaled down size and position.

There are other possibilities.

The initial size and placement of a new window is a completely different issue. That’s not really a bug, more an oversight. It would be nice to fix though.

Apologies for any mistakes as this is from memory from over 10 years ago!

Windows on the RDP Server end needs to know if anything is in the client end clipboard, what it is and when it has changed. The changed part is important as data is only transferred from the client to the server if the content of the clipboard on the client is different to the server. For example, if you copy something on the client (RISC OS) and then paste twice on the server (in Windows), the data is only transferred once to the server and the second paste is from the local clipboard. If the server isn’t informed when the client clipboard contents change, the server will either think the clipboard is empty all the time (as it was empty when the session started) so there is nothing to paste or the contents are “stuck” at their initial state as no updates are required to be transferred from the client as nothing has changed (even when it has).

RISC OS doesn’t explicitly have a changed notification message, but this does happen as a side effect of the RISC OS Select “Clipboard Holder” task (as an example). The purpose of this task is to always “own” any clipboard data. One benefit of this is that the clipboard contents can always be pasted, even after the originating task has quit. For this, whenever a “copy” operation is performed in a task, it broadcasts the message informing other tasks that it now has clipboard data. This is such that only one task can “own” the current clipboard data and any other task which previously did have data should forget this. Whenever a task “owns” the clipboard that is not itself, the “Clipboard Holder” requests this data and then takes ownership away from the original. As the “Clipboard Holder” then always takes ownership on every “copy” operation, this can be used to indicate when the clipboard contents have been modified. If the “Clipboard Holder” wasn’t there to take ownership of the clipboard data from another task, repeated copy operations would not trigger any Wimp messages. From my testing at the time, after an application has taken “ownership” of the clipboard, subsequent copy operations in the same application would not cause any Wimp messages to be sent as that application already “owns” the clipboard so there is no need to tell any other applications that it now has (new) clipboard data. On RISC OS the contents of the clipboard are only checked when a paste happens so an application which has clipboard data doesn’t need to divulge what it knows until you paste and request the data.

To make the RDP clipboard work on versions of RISC OS which don’t have the Select “Clipboard Holder” I wrote another application, “Clipboard Manager”, which is bundled with the RDPClient software. This is effectively my clone of the functionality of the Select “Clipboard Holder” and a single instance of this is loaded automatically when “Clipboard Holder” is not present. It is important that only one instance of an application which wants to “own” any clipboard data is loaded at the same time as otherwise there will be a fight between each of these applications which will probably end badly!

I haven’t checked Avalanche VNC sources but if that is implementing a kind of “clipboard owner” to trigger clipboard owner change messages on a copy operation, that would cause problems with RDPClient when its bundled “Clipboard Manager” task is loaded.

It would be good if RISC OS 5 included its own equivalent of the Select “Clipboard Holder” as other than its primary purpose would as a side effect implement change notification as standard and prevent clashes between applications attempting to duplicate this functionality.

James: Thanks for the explanation of Toggle Size & Scaling.

I was being confused partly because I had been changing the settings in Choices … but I now see those do not affect connections set up in the hotlist. Now I have edited the hotlist entry, I can see that un-selecting settings does have an effect, and Toggle Size works as expected!

I understand why it does not work with scaling, but it would be nice if you can find a way.

Andrew: Avalanche doesn’t claim ownership of the clipboard unless a VNC server sends it a selection.

Until version 0.26 however it was responding immediately (in the same wimp_poll) to the message sent when another application claimed the clipboard in order to pass the clipboard contents to the VNC server.

If more than one application did this immediate paste then the clipboard owner needs to support handling multiple concurrent (interleaved) data transfer operations and not all do.

Interesting point about clipboard holder though. Avalanche doesn’t take any special measures to deal with clipboard owners not announcing later clipboard changes, so such updates would not get passed to the server. It seems many applications just send Message_ClaimEntity anyway which is probably why I never noticed it, but not all.

I’d certainly prefer a system wide fix, rather than having each application which wants to know reliably when the clipboard is updated having to come up with its own workaround.

As for the auto-scroll crash, it look very odd. What seems to be happening is that Avalanche is calling XWimp_PollIdle which never returns.

It appears that the Avalanche’s _kernel_ExitHandler is called, which runs the atexit() registrants and then kills Avalanche. The ZeroPain log shows the trigger being an LDR in the toolbox module, in filters_prefilter. I can’t catch or report this error in Avalanche itself, but haven’t looked into this yet in detail.

This problem was masked as Avalanche was doing more than it needs on its atexit() handler, which itself was generating an error. Really it just needs to ensure any open sockets and files are closed.

Made a bit more progress tracking this down. There appears to be an address exception coming out of Wimp_PollIdle when auto-scroll is enabled, the window can no longer scroll and the pointer is outside of the auto-scrolling window. This results in Avalanche getting ungracefully killed.

From the debugger dump, disassembling the WindowManager and looking at the Wimp03 sources:

;------------------------------------------------------------------------------------------
; Error block: 80000002 Internal error: abort on data transfer at &FC15AC70
;------------------------------------------------------------------------------------------
; R0 = 000004d2
; R1 = 0000035e
; R2 = 00000004  mouse button state
; R3 = 201cb9b9
; R4 = 00000000  icon handle
; R5 = 0000000f
; R6 = 000003e2
; R7 = 00000000
; R8 = 00000644
; R9 = 000004aa
; R10 = 201cb1f8
; R11 = 0002b14c
; R12 = 2001e1f4
; R13 = fa207fb0
; R14 = fc15ac44
; R15 = fc15ac78
; CPSR = 00000113
; SPSR = 40000193
;------------------------------------------------------------------------------------------
; cantchange (Wimp03)
;------------------------------------------------------------------------------------------
; R0,R1 = mouse coords (absolute)
;    R2 = mouse button state
;    R3 = window handle
;    R4 = icon handle; not forced to -1 for background.
;------------------------------------------------------------------------------------------
FC15AC2C : Àà.å : E59CE0C0 : LDR     R14,[R12,#192]     ; dragtype
FC15AC30 : ..>ã : E33E0000 : TEQ     R14,#0
FC15AC34 : ..>. : 133E000A : TEQNE   R14,#&0A           ; drag_subr_posn2 (10)
FC15AC38 : ..>. : 133E000B : TEQNE   R14,#&0B           ; drag_subr_size2 (11)
FC15AC3C : ð... : 1A0001F0 : BNE     &FC15B404          ; trykeys
FC15AC40 > ü&.ë > EB0026FC > BL      &FC164838          ; scanmenus; no menu, only corrupts LR
FC15AC44 : á..j : 6A002EE1 X BVS     &FC1667D0          ; ExitPoll (assumed not taken)
FC15AC48 : ..sã : E3730001 : CMN     R3,#1              ; nullptr (-1)
FC15AC4C : ì... : 0A0001EC X BEQ     &FC15B404          ; trykeys
FC15AC50 : ..tã : E3740002 : CMN     R4,#2              ; nullptr2 (-2)
FC15AC54 > .... > 1A000001 > BNE     &FC15AC60          ; *** branch taken *** >----+
FC15AC58 : 6..ë : EB000336 X BL      &FC15B938          ; setwimpicon               |
FC15AC5C : ...ê : EA000004 X B       &FC15AC74          ; gotbttype                 |
FC15AC60 : ..tã : E3740001 : CMN     R4,#1              ; nullptr (-1)         <----+
FC15AC64 :  Q.. : 059A5120 X LDREQ   R5,[R10,#288]      ; [handle,#w_workflags] (workarea)
FC15AC68 : .P.. : 159A5010 : LDRNE   R5,[R10,#16]       ; R5,[handle,#w_icons]  (icon)
FC15AC6C : .P.. : 12855010 : ADDNE   R5,R5,#&10         ;   = 16 (i_flags)
FC15AC70 * .R.. * 17955284 * LDRNE   R5,[R5,R4,LSL #5]  ;   = icon flagword *** BOOM ***
FC15AC74 : ..tã : E3740002 : CMN     R4,#2
FC15AC78 : ...Ú : DA000004 : BLE     &FC15AC90          ; PSR
FC15AC7C : ¼â.å : E59CE2BC : LDR     R14,[R12,#700]

What I suspect is that R10 refers to the Avalanche window, which has no icons and R3/R4 refer to the window/icon under the pointer. If [R10,#16] can be zero or some other invalid pointer for windows with no icons, then that could explain it the observed behavior.

There are a lot of assumptions there, which I’m not sure how to validate.

Did a quick test by adding an icon to the Avalanche window, which did indeed seem to stop the problem from happening.

Further investigation:

• Looking at the source for Wimp_CreateIcon, the icon array pointer in the Wimp’s window structure can be -1 as the logic there checks for this value.
• R10 is the handle of the Avalanche view window which is performing the auto-scroll, but with bit 0 clear.
• Before triggering the crash, the value in (view-window-handle -1 + 16) is -1.
• R4 is the handle of an icon in R3 which is the window under the pointer when the exception occurs.

So this looks like a bug in the WindowManager and perhaps the logic here should be using (R3-1) rather than R10 to look up the iconflags.

It does look as if the code ought to check the number of icons before ploughing in, assuming that there will be at least one.

But it reinforces my dislike of using assembly language for this kind of stuff.

It’s using the icon handle from one window with the window structure of a different window.
Admittedly, I don’t fully understand the context this code is called in but that doesn’t look right.