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/
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.
How is it going to handle DIB drawing without a DIB engine? Is there some offscreen bitmap support in RDP which this driver could offload to like x11drv?
On Tue, Mar 10, 2009 at 1:08 PM, Stefan Dösinger stefandoesinger@gmx.at wrote:
How is it going to handle DIB drawing without a DIB engine? Is there some offscreen bitmap support in RDP which this driver could offload to like x11drv?
I believe there is, see:
http://msdn.microsoft.com/en-us/library/ms861202.aspx
This client side bitmap caching seems to be along the same line but I am not sure. This is not really an area of expertise for me, which is why I propose it for a SoC student. Hopefully even if we run in to a few problems, we could make use of the existing DIB engine from the last summer of code.
-
Stefan Dösinger -
Steven Edwards