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

[Stephen Hoffman]

On 2015-03-23 10:35:31 +0000, Dirk Munk said:

> 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.

X is an RPC protocol.   For the flexibility of remote displays, X adds 
substantial complexity to the software design (and vulnerabilities, in 
various cases), and this slows the display performance.  When you don't 
have to marshall and transfer your client display requests to a 
separate display server and then unmarshall and display the requests at 
the display server, while also maintaining a path to get keyboard and 
mouse responses back, you can go faster.   As an example of this, 
VWS/UIS was far more responsive and far lighter-weight than was X on 
the same hardware.  With the local-only design, you're dealing with 
getting stuff into the frame buffer, not with a very complex 
intermediate RPC layer.

If you've not already done so, please watch that Wayland video for some 
background on the X RPC.

For Microsoft Windows and Apple OS X, the complexity of the RPC and the 
rest of the network transport is largely avoided with RDP/VNC/ARD.  
Local users get an optimized display, and better performance — yes, in 
general getting to at least 60 fpm is getting easier as the hardware 
improves and the software is optimized.  But vendors of 
graphics-intensive servers and products don't want to add impediments 
to applications getting to what is the generally-accepted minimal frame 
rate, with enough headroom left for whatever the application is doing.

Vendors also tend to use display APIs as application lock-ins, 
WindowsAPI with its various display-related frameworks, and Apple with 
UIKit and AppKit for iOS and OS X.  Or with the (few) private 
DECwindows calls, for OpenVMS.  (About the only one of those 
OpenVMS-private DECwindows-related bits that was notable was the SVN 
stuff.  OpenVMS locked folks in with clustering and system services and 
RTL calls, much as Microsoft used its APIs.  But I digress.)

More portable code tends to use GTK+ or Qt 
<http://www.wikivs.com/wiki/GTK_vs_Qt>.

There are various less- and more-portable frameworks or whatever you're 
working on, too.  Game developers often seek a common cross-platform 
framework, maybe selecting <http://www.appcelerator.com/titanium/> or 
Unity or Unreal Engine, for instance.  (n.b. I do not expect to see any 
of the more advanced frameworks available on OpenVMS.)


>> 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.

No?  Neither X remote displays nor RDP/VNC/ARD remote displays are 
overtly visible — latencies aside — to the applications.  Yes, X has 
advantages in some areas, but the innards of X are accreted — various 
folks are simply bypassing more and more of what X was and is, and 
largely using it as an RPC.

In more general terms...  Much like a recent new friend here in 
comp.os.vms has ably demonstrated, getting tied to one technology or 
one solution or one approach can be... problematic.  Use what works for 
your environment, but expect changes, expect requirements to evolve, 
and expect the costs of various options to drive more than a few 
decisions, and to drive the appearance of new platforms and tools, and 
the decline and extinction of others.  Know what your risks and 
alternatives are — if you're tied to OpenVMS tightly and a port is 
impractical, then VSI had better succeed for you.  Right now, local 
graphics displays and RDP and x86-64 do pretty well, though some folks 
will always have different needs.   In a few years, who knows what 
we'll be using?  (If VSI really gets rolling, they — like VMS once did 
— might just be able to drive some of these changes.  Rather than 
reacting to and "just" following the changes.  But VSI needs to get to 
viable revenues, first.)


-- 
Pure Personal Opinion | HoffmanLabs LLC