[Info-vax] Could XRDP be the next graphical interface for VMS?
Bill Gunshannon
bill at server3.cs.scranton.edu
Mon Mar 23 08:53:35 EDT 2015
In article <d434$550eb674$5ed4324a$62587 at news.ziggo.nl>,
Dirk Munk <munk at home.nl> writes:
> Stephen Hoffman wrote:
>> On 2015-03-21 14:59:18 +0000, Dirk Munk said:
>>
>> TL;DR: It'd be nice to have, but as an add-on and not as the sole path
>> into an OpenVMS graphical display environment. Whether RDP solves some
>> particular problem here does depends on what problem you think RDP might
>> address â and I don't yet understand which problem(s) you are seeking to
>> address with RDP.
>>
>>> Recently there was some discussion about X-Windows, Motif etc. in this
>>> group.
>>
>> There was a discussion of the rather limited graphics driver support and
>> the need to deal with graphics hardware â graphics hardware which tends
>> to have the product shelf life of a fruit-fly, and where new device
>> generations require reworked or wholly new device drivers, and which is
>> work that can require potentially-restricted access to detailed device
>> interface specifications if and as those are available â and also
>> discussion around whether or not certain applications and certain
>> applications did or did not require graphical displays â some folks here
>> will emphatically never require a graphics display associated with
>> OpenVMS â and there was the usual debate and disagreement over exactly
>> what a desktop environment is, and what a desktop environment might
>> provide folks. The opinions and requirements and potential usages of
>> what various participants refer to as a "desktop" do of course vary very
>> widely, and â for clarity â the chances of OpenVMS ever hosting what
>> most folks would consider useful home or office applications approaches
>> zero.
>>
>>> I'm not an expert on these matters,
Some comments from someone who uses (and has used for a long time) both
X and RDP.
>>
>> Some of these discussions can require substantial effort to explain the
>> associated technical details to an inexperienced or inexpert user, which
>> can require a willingness to gather and present the associated
>> background information and lints to associated resources and
>> discussions. Time and effort and research. Put another way, it can be
>> much easier to ignore some of these discussions. The astute reader will
>> note that more than various folks familiar with X and RDP technologies
>> can and do ignore some of these threads, of course.
>>
>>> but it doesn't stop me thinking about good solutions for these problems.
>>
>> Which particular problems would you be proposing "good solutions" for,
>> in this case? Whether inexperienced or expert, some background
>> information and a summary can help readers better understand the
>> suggestion, or the proposal, or â if you were asking one â the question.
>
> Like I explained before, if you can make these kind of graphical
> connections from a PC without the need for extra software packages, and
> having to install and pay for them, that in itself would be beneficial.
OK, both Xming (not the only option but one of the better) and RDP
are costless initially (nothing is actually costless, but you don't
have to "buy" either). They both need to be installed, one as a
third party product and the other as a Windows feature which may
or may not be installed by your default install.
> So I wanted to know if this would also be a viable solution from a
> technical point of view, but it clearly is not.
Why not? What technical problem do you see with it? Unless you mean
on the VMS end.
>
>>
>> For this RDP discussion, this "good solution" is a reasonable approach
>> in support of those Windows clients or other systems that cannot or do
>> not have an X Windows server package installed, and that require viewing
>> the OpenVMS graphical display from the physical or virtual frame
>> buffer. That's probably not a very big market, right now.
>>
>> RDP can certainly be handy for some specific application cases and I do
>> use it for various operations, but I wouldn't presume providing a
>> somewhat better OpenVMS graphics experience for Windows users would be
>> at the top of the work list over at VSI â there isn't all that much
>> graphical application software for OpenVMS, and what is available can â
>> in the absence of RDP â be displayed remotely via X. Unlike the
>> experience and the tools that most Windows or OS X users are presented,
>> OpenVMS is still centrally managed from the command line.
>>
>> OpenVMS on Integrity servers can also have RDP vKVM support via the
>> management processor iLO, which means this solution is already available
>> for those users â no RDP server needed. There are also various vendors
>> which offer hardware network KVMs
>> <http://www.blackbox.com/Store/Results.aspx/KVM/n-4294964384/p-0> â no
>> software required. Not the cheapest way of doing this, but functional
>> for those that really need it.
>>
>> RDP is a reasonable solution that Microsoft uses, and Microsoft uses RDP
>> because the Microsoft GUI does not have remote-display capabilities. OS
>> X has similar GUI display limitations, as do some other windowing
>> systems. The old VWS/UIS system was local, as well. Both Windows and OS
>> X have functional, free, add-on X Window servers.
>>
>> Beyond the effects of the network connection and ignoring the lack of a
>> viable RDP server for OpenVMS servers lacking vKVM support, local
>> experience finds RDP rather slow when working with virtual frame
>> buffers. But I digress.
>>
>> Note that Windows and OS X still have graphics driver support, and
>> extensive application frameworks for accessing and managing the display.
>>
>> Running DECterm via X or via RDP is reminiscent of hunting fleas with
>> anvils. It works, but...
>>
>>> But what is your opinion, could XRDP or a similar OpenVMS package be
>>> the way for a new graphical interface?
>>
>> RDP is a software-implemented network-remote KVM. RDP is useful for
>> some cases and a common protocol for an RDP client box that needs to
>> access a remote RDP server box, but it is not what most folks would
>> consider a "new graphical interface". RDP is nothing of the sort. It's
>> far too primitive to be considered a graphical interface.
>
> I agree. My first impression was that it was a kind of X-Windows
> variant. I had no idea it would be this primitive.
Primitivie? I would think people would see X as the more 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.
They are two differnt products with two different audiences and two very
different things they wish to accomplish. To be honest, I think the RDP
paradigm is much more in line with what people wold want on VMS. Think
VMS desktops without VMS hardware physically on the desktop.
>
>> Try doing
>> some X programming on OpenVMS or Unix (whether Motif or CDE or Wayland
>> or otherwise), or Xcode and the now-integrated Interface Builder on OS
>> X, or the Visual tools over on Windows, or GTK+, or whatever. These
>> tools can control and manage displays, and applications can use these
>> tools for displays. RDP? Not so much. If VSI wants to go entirely
>> virtual, then they probably would use RDP â but I suspect there'll be
>> customers that want a local graphics display of some ilk, which will
>> require a graphics device driver.
>>
>> Read up on X and Motif and CDE and Wayland and particularly watch the
>> Wayland video referenced at <http://labs.hoffmanlabs.com/node/1680> as a
>> starting point, and read up on RDP
>> <http://en.wikipedia.org/wiki/Remote_Desktop_Protocol>.
>>
>
So, who is going to write the RDP server for VMS? :-)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999 at cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
More information about the Info-vax
mailing list