[Info-vax] Could XRDP be the next graphical interface for VMS?

[John E. Malmberg]

On 3/23/2015 5:35 AM, Dirk Munk wrote:
> Jan-Erik Soderholm wrote:
>> Dirk Munk skrev den 2015-03-22 13:32:
>>
>>> I agree. My first impression was that it was a kind of X-Windows
>>> variant. I
>>> had no idea it would be this primitive. With an X-Windows server you can
>>> run applications on several clients (in X-Windowa terminology), and that
>>> will be impossible with RDP I guess.
>>>
>> The big difference is that a X-window client application are specificaly
>> written with X-windows in mind. You can not run anything that is not
>> written for X-windows in the first place.
>
> I get that, but Windows has its own way of doing something similar on
> the local screen. A Windows applications will issue some instructions to
> draw a window on a screen. It would have been nice if Microsoft had
> thought of a way to issue those instructions on a remote PC/terminal,
> just like with X-Windows.

The Microsoft design equivalent was to break up the application into a 
GUI and backend portion.  The GUI runs on the desktop and the rest of 
the logic runs on the server.

This is detailed in public design documents and possibly in Helen 
Custer's book, along with the discovery that the existing common RPC 
implementations took too long to execute on then current hardware when 
running on the local system and the original RPC design had to be changed.

Anything like SMBCLIENT that knows the protocol to communicate with the 
server can front-end most applications on Windows.

>> Applications that are displayed over RDP does not know they are
>> displayed using RDP. There are no "RDP-applications".
>
> No, but with a Unix or VMS system, applications with a GUI interface
> don't know if they are run locally using a graphics card, or remotely on
> a X-Windows server.

RDP redirects at the graphics/screen library level to catch updates to 
the screen, not the framebuffer like VNC, which makes RDP more efficient.

Applications can detect that they are running over RDP and adjust their 
behavior.  The screen properties of the RDP screen are more limited than 
an actual SVGA.

Running an application that expects that it can operate on the 
framebuffer directly over RDP does not work well because the operation 
is caught and attempted to be simulated, and usually makes it too slow 
to be usable.

There are also two Microsoft RDP clients.  The default one installed on 
the desktop operating systems is the limited version.

For an efficient xRDP server implementation, it may have to intercept at 
the GTK+ and XLIB level and not simply relay the framebuffer as a 
bitmap.  I have not seen the internals of xRDP so I do know know what 
was actually implemented.

>> And you can of course have several RDP sessions open, if you like,
>> against multiple servers. But each session is a full "desktop".
>> Not the "D" for "Desktop" in RDP...

That is the old RDP protocol, not the latest version.  The latest 
version is design so that a client tell the server to run an application 
and send the output to a special RDP window on the client.

Done correctly the user does not realize that they are running the 
application over RDP.

>> Primitive? No, not really. The big advantage is that you do not have
>> to have specificaly written applications (like X-windows does),
>> anything you can run localy on the server can also run over RDP.

The major issue that I see with X-windows is that it depends on the 
client and network being continuously available.

With RDP/VNC I can have the client sleep or have the network interrupted 
and reconnect back to the same session.

This issue is somewhat addressed with Wayland.

Wayland has current design issues that may cause problems down the road. 
  Wayland assumes that the server has at least one SVGA graphics chip 
that Wayland can access the GPU on to render the framebuffers.  This is 
the way that Wayland can offer fast enough rendering of the screens to 
the desktops.  How many desktops can that scale to?

If Wayland can not find that, it falls back to a slower mode of 
operation, which may not be fast enough.

Regards,
-John