How difficult would it be to make the equivalent of Windows Terminal Server with Wine?

[Andrew Quigley]

What I would like to be able to deploy would be a system which runs 
multiple Win32 compatible desktops and multiple logins on a server, with 
the clients accessing the desktops via RDP or ICA protocols.  How many 
of the pieces required to accomplish that already exist, and what pieces 
have yet to be built? A quick search on freshmeat shows me a few 
different rdp clients, so it looks like the protocol spec is known. What 
would be involved in creating a RDP server that shows up as a video 
driver as far as the win32 programs are concerned?

[Jeremy White]

Hey Andrew,

That's something we've investigated fairly closely, as it seems
like a Good Idea (TM).

First, as far as I know, there is no public implementation around
the ICA protocol, so that doesn't seem like a good option.

Now RDP is based on an IETF protocol spec, so implementing that
looks like a good, clean option.

So, in theory, writing a rdpdrv that is parallel to x11drv
should be straightforward (and that's the task, just replace
x11drv with rdpdrv).

Unfortunately, the reality is that it will be a lot of work.
Although the architectural design that the x11 driver is
supposed to be separated out, that separation isn't that
clean, and then there are a lot of underlying OS resources
(e.g. sound etc) that are not so clearly isolated.
So we felt it would be more work than we could afford to
bite off in the near term (which is not to say we won't
contemplate doing this in the medium term future).

As an fyi, we chose to follow an alternate course in the
interim.  Specifically, by examining the use of the X protocol
that Wine uses, and working to optimize that, we should be able
to make Wine work decently well over an ssh -C compressed X link.
This was the consensus we came to after long discussions
with Keith Packard and Alexandre Julliard.  So, Alexandre
has been steadily  (if slowly :-/) working to reduce round
trips to the X server within Wine, with the hopes that we'll get there.

Further, there are protocol proxies, like that of nomachine.com,
that try to take some of that sting out (last I knew, NX
helped, but still wasn't in ICA or RDP class with Wine).

Hope that helps, feel free to contact me further on or off list
if you'd like to pursue it further.

Cheers,

Jeremy

Andrew Quigley wrote:
> What I would like to be able to deploy would be a system which runs 
> multiple Win32 compatible desktops and multiple logins on a server, with 
> the clients accessing the desktops via RDP or ICA protocols.  How many 
> of the pieces required to accomplish that already exist, and what pieces 
> have yet to be built? A quick search on freshmeat shows me a few 
> different rdp clients, so it looks like the protocol spec is known. What 
> would be involved in creating a RDP server that shows up as a video 
> driver as far as the win32 programs are concerned?

[Boaz Harrosh]

Andrew Quigley wrote:
> What I would like to be able to deploy would be a system which runs 
> multiple Win32 compatible desktops and multiple logins on a server, 
> with the clients accessing the desktops via RDP or ICA protocols.  How 
> many of the pieces required to accomplish that already exist, and what 
> pieces have yet to be built? A quick search on freshmeat shows me a 
> few different rdp clients, so it looks like the protocol spec is 
> known. What would be involved in creating a RDP server that shows up 
> as a video driver as far as the win32 programs are concerned?

I did something similar.

I used X, and have written an IE embeddable OCX that automatically 
Installs X-Server and connects to the X applications on the server, in 
my case they are Windows apps running under wine. So basically you set 
up a web server on your Linux machine. You put a page with the different 
apps you want to serve. The user uses IE to navigate to that page. When 
clicking, the App comes up as a window in his/her machine. First time 
visit Installs a 12M  Cygwin/X server.

I do intend to publish the OCX project as GPL. And the wise-script to 
package the Cygwin/X installation. And also have available the binary 
package.

Hope that can help
Free Life
Boaz

[Jakob Eriksson]

Boaz Harrosh wrote:
> I did something similar.
>
> I used X, and have written an IE embeddable OCX that automatically 
> Installs X-Server and connects to the X applications on the server, in 
> my case they are Windows apps running under wine. So basically you set 
> up a web server on your Linux machine. You put a page with the 
> different apps you want to serve. The user uses IE to navigate to that 
> page. When clicking, the App comes up as a window in his/her machine. 
> First time visit Installs a 12M  Cygwin/X server.
>
> I do intend to publish the OCX project as GPL. And the wise-script to 
> package the Cygwin/X installation. And also have available the binary 
> package.
>
> Hope that can help
> Free Life
> Boaz

Wow!  That's just plain cool and useful!

[Hans Leidekker]

> > different apps you want to serve. The user uses IE to navigate to that 
> > page. When clicking, the App comes up as a window in his/her machine. 
> > First time visit Installs a 12M  Cygwin/X server.

I really like the concept but your approach seems to limit publishing of apps
to Windows boxes. Theoretically you could run the OCX (Internet Explorer) on
Wine and the Cygwin/X as well but not practically though, if only from a 
performance point of view.

It would be more interesting if Mac/Linux/Unix users could use their browser
of choice and their native X server, which is usually already installed on
those platforms. How exactly is this approach dependent on the use of an OCX?

 -Hans

[Boaz Harrosh]

Hans Leidekker wrote:
> I really like the concept but your approach seems to limit publishing of apps
> to Windows boxes. Theoretically you could run the OCX (Internet Explorer) on
> Wine and the Cygwin/X as well but not practically though, if only from a 
> performance point of view.
>
> It would be more interesting if Mac/Linux/Unix users could use their browser
> of choice and their native X server, which is usually already installed on
> those platforms. How exactly is this approach dependent on the use of an OCX?
>
> -Hans

Very good question!
Once I de-wrinkle all details with my boss, I want to publish the source 
for the OCX. The first "todo" it will have is the:
How to port to other platforms/browsers.?

On the Server html page I have the <object> tag with the 
CODEBASE="path2cab/xwidget.CAB" attribute
(xwidget is what I called the OCX)

I have read that there is a way to have platform/browser specific 
installation packages. But than how to do it with each platform?
I don't know? any Mozilla guru out there that can help. On Linux all you 
need is a client side access to the shell. And also on Mac OSX.

Actually all it is on windows is a shell access with an invocation of 
ssh -X, And the regular IE's safe-for-scripting stuff.
(ssh is installed along side with the cygwin/X server)

It is all very Client un-safe and should probably be confined to the 
IntraNet only. Server safety can be kept.
Maybe the best would be to embed the ssh inside the Object and not let 
the server have a shell access on the client. I'll see how it goes and 
if client safety is requested at all.

Free Life
Boaz

[Hans Leidekker]

On Monday 1 November 2004 16:27, Boaz Harrosh wrote:
> Actually all it is on windows is a shell access with an invocation of 
> ssh -X, And the regular IE's safe-for-scripting stuff.
> (ssh is installed along side with the cygwin/X server)

I think the use of ssh is a good choice because it let's you transparently
encrypt the X connection as well as restrict the use of the connection. For
example with ssh you can tie an authorized key to a single command, which
in this situation would be the command to start the windows app. So you
don't give away full shell access (not immediatley at least) and with the
exchange of keys you can also achieve a non-interactive login.

I do this all the time when I run cross compiled Wine tests. I have a Win2k
VMWare instance on my laptop (could be a machine anywhere else on the network)
which has Cygwin + sshd installed and the Wine source tree mounted on drive w:
over SMB. A session then looks like this:

 $ ssh -t hans(a)win2k 'w:/dlls/kernel/tests/kernel32_crosstest.exe change'
 change: 88 tests executed, 0 marked as todo, 0 failures.
 Connection to win2k closed.

Saves you a lot of mouse moving and clicking before you can run the binary
on Windows. This gives me a very fast 'change source -> compile -> run on
Wine and Windows' cycle because I essentially don't have to leave my shell.

Sorry for getting off-topic. I just thought others might find this interesting
as well.

 -Hans

Hi Boaz,

Not sure if this is relevant/useful, but I have been playing with using
Wine to deliver apps to Mac users over the LAN. Using scripts, I start X11
on the Mac, copy the X cookie into the terminal variable on the Mac side,
telnet to the Linux server, start the Wine app, and send the display back
to the Mac. Probably you have discarded this option for security reasons,
however we find this runs much faster using pure X11 over the LAN than
tunnelling X11 over SSH; there's less work on both ends. As long as
security is not a concern, and it's LAN only it's a nice solution.
Passwords are simply disabled on the Linux box; the users can't tell the
difference between a locally installed app, and one running on the Linux
box. In fact, on slow Macs, the linux server executes and displays faster
than a local app ever could.

Each Mac user has their own Linux account. I setup one Linux account the
way I need and then copy it for how ever many Mac users there will be. It
looks to me as if hardware requirements are better than Citrix, even though
each user has their own instance of Wine.

Have experimented with varying results over WAN with combinations of SSH,
lbx proxy etc. When I get a chance I'll look at FreeN/X; it sounds
promising.

By the way, this solution works for Windows/Mac/Linux equally well, of
course you need an X server installed.

Simon Tyler


                                                                           
             Boaz Harrosh                                                  
             <boaz(a)hishome.net                                             
             >                                                          To 
             Sent by:                  Hans Leidekker <hans(a)it.vu.nl>      
             wine-devel-admin@                                          cc 
             winehq.org                wine-devel(a)winehq.org, Jakob        
                                       Eriksson <jakov(a)vmlinux.org>,       
                                       Andrew Quigley                      
             11/01/2004 10:27          <andrew.quigley(a)multitek.com>       
             AM                                                    Subject 
                                       Re: How difficult would it be to    
                                       make the equivalent of Windows      
                                       Terminal Server with Wine?          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hans Leidekker wrote:
> I really like the concept but your approach seems to limit publishing of
> apps
> to Windows boxes. Theoretically you could run the OCX (Internet Explorer)
> on
> Wine and the Cygwin/X as well but not practically though, if only from a
> performance point of view.
>
> It would be more interesting if Mac/Linux/Unix users could use their
> browser
> of choice and their native X server, which is usually already installed on
> those platforms. How exactly is this approach dependent on the use of an
> OCX?
>
> -Hans

Very good question!
Once I de-wrinkle all details with my boss, I want to publish the source
for the OCX. The first "todo" it will have is the:
How to port to other platforms/browsers.?

On the Server html page I have the <object> tag with the
CODEBASE="path2cab/xwidget.CAB" attribute
(xwidget is what I called the OCX)

I have read that there is a way to have platform/browser specific
installation packages. But than how to do it with each platform?
I don't know? any Mozilla guru out there that can help. On Linux all you
need is a client side access to the shell. And also on Mac OSX.

Actually all it is on windows is a shell access with an invocation of
ssh -X, And the regular IE's safe-for-scripting stuff.
(ssh is installed along side with the cygwin/X server)

It is all very Client un-safe and should probably be confined to the
IntraNet only. Server safety can be kept.
Maybe the best would be to embed the ssh inside the Object and not let
the server have a shell access on the client. I'll see how it goes and
if client safety is requested at all.

Free Life
Boaz

[Markus Amsler]

Hans Leidekker wrote:
> > > different apps you want to serve. The user uses IE to navigate to that 
> > > page. When clicking, the App comes up as a window in his/her machine. 
> > > First time visit Installs a 12M  Cygwin/X server.
>
> I really like the concept but your approach seems to limit publishing of apps
> to Windows boxes. Theoretically you could run the OCX (Internet Explorer) on
> Wine and the Cygwin/X as well but not practically though, if only from a 
> performance point of view.
>
> It would be more interesting if Mac/Linux/Unix users could use their browser
> of choice and their native X server, which is usually already installed on
> those platforms. How exactly is this approach dependent on the use of an OCX?
>
> -Hans

I really like the idea invoking a X-session from your browser. Some time 
ago working on some complex php/dhtml web site administration  scripts, 
I had the feeling programming a real app instead of a web app would be 
much easier. I never got concrete, but made some ideas.
My approach was the following:
Server side:
  - defining a mime-type application/x11-control (or something similar)
  - a x control file, with all the information to connect to the 
X-client over ssh (app-name, host, ports, [ssh username,password], ...). 
(say tst.x11)
  - a link to the tst.x11 file in the webpage.
  - the app itself
  - a unix user (anonymous or autorized)
Client side:
  - A x invoking script
  - Map application/x11-control type to the x-script

When you click on the link, your x-script gets invoked with the tst.x11 
files, which then connects to the x-client. You could also (optionally) 
specify an anonymous user/password setting for the ssh tunnel.

This approach would be completly platform independant. But it would 
require the web-client to install the x-script and map the mime-type 
(well the x-script installation could do that). I googled a little 
around, but found nothing similiar, although the approach seems to me 
pretty obvious.

This may be a little off-topic, but the idea combining http and x is 
really fascinating.

Markus

[Hans Leidekker]

On Monday 1 November 2004 17:38, Markus Amsler wrote:
> My approach was the following:
> Server side:
>   - defining a mime-type application/x11-control (or something similar)
>   - a x control file, with all the information to connect to the

Defining your your own mime-type has a disadvantage in that nobody but
you knows about it (yet). In Boaz's approach it's not needed because it's
not an X session that's started from the browser (OCX) but an ssh session
that then starts the the remote app and tunnels the X session in case it's
a graphical app. So what would be needed is a tiny shell script that goes
like:

 #!/bin/sh
 ssh -X user(a)apphost '/path/to/wine/app.exe'

A mime-type for shell scripts already exists: application/x-sh
> This may be a little off-topic, but the idea combining http and x is 
> really fascinating.

Funny how we were independently getting off-topic within the same thread.

 -Hans