RFC: Summer of Code Proposal: WINE XRDP Driver

[Steven Edwards]

Abstract:

The goal of this project is to implement rdpservice support in Wine
 by converting XRDP in to a Winelib application allowing the execution
 of Wine based applications over the RDP protocol, without the need of
a X11 Session/Driver
. RDP protocol offers significantly faster performance than X11 or VNC
for network applications. Currently if you want to run a Wine
application over XRDP you tend to run in to performance problems due
to the overhead of the Win32↔X11↔VNC ↔ RDP translation.


Workflow:

    Current Design Using XRDP and Wine (Bad)
    RDPClient ↔ XRDP ↔ VNC ↔ X11 ↔ X11DRIVER/Wine ↔ Win32 Application

    Proposed Design (Good)
    RDPClient ↔ Wine XRDP Daemon ↔ XRDPDriver/Wine ↔ Win32application


Details:

1.I believe the most simple route will be to convert XRDP to a Winelib
application. Alternatively XRDP will
 need to be modified to allow direct execution of Wine processes. The
current design of XRDP session involves loading selected unix
libraries
 such as a libvnc redirector or librdp redirector. Given that Wine processes
 tend to want to manage all of their own resources, I believe a Winelib port
 of XRDP is the most simple route. (I have actually built XRDP as a Winelib
 process in the past)
. This gives us the ability to directly call Win32 functions like
CreateProcess from the xrdp_wm to get a proof of concept up and going
in short order.

2.a wine libXRDP driver will need to be developed to encapsulate the
 raw XRDP bitmaps and primitives to related Win32 functions
. This of course means that it won't be feature complete for a long
time, but as the Quartzdrv showed, it is possible to write a driver
that works for simple Winelib applications in short order.

3.Similar to x11driver in Desktop mode, Wine is going to do all of its
own Window management. Much like the idea of the SugaredWine, this
session would always run explorer.exe


Issues:

1.writing a Wine driver is hard. Really hard. Alexandre does not like
new ones because he does not want to end up being the only one
maintaining them. Also the current XRDP graphic support is very
primitive. It's really going to need a DIB engine and all sorts of
other magic. I expect given the speed of the RDP protocol, even
without the DIB engine, its still going to be faster than running the
standard X11->VNC->RDP bridge just due to the removal of many layers
of redirection.

2.There are licensing issues. XRDP being based on rdesktop is GPL
rather than LGPL. The xrdp_wm code is all orginal to the XRDP project
and is really its own library. Based upon my discussions with the XRDP
maintainer in the past, I expect we should be able to get some sort of
license exception for us linking to this code. Alternatively it could
be maintained out of tree by certain parties interested in this
support. I know in the past CodeWeavers has expressed interest in a
RDP driver and its possible there are other parties that would be
willing to help maintain it once a proof of concept was developed and
a business case proven.

Links:
http://wiki.winehq.org/SugaredWine
http://wiki.winehq.org/WineExplorer
http://wiki.winehq.org/DesktopWindow
http://xrdp.sourceforge.net/
http://www.rdesktop.org/


-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo