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?
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?
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
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!
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
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
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@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@hishome.net > To Sent by: Hans Leidekker hans@it.vu.nl wine-devel-admin@ cc winehq.org wine-devel@winehq.org, Jakob Eriksson jakov@vmlinux.org, Andrew Quigley 11/01/2004 10:27 andrew.quigley@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
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
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@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
-
Andrew Quigley -
Boaz Harrosh -
Hans Leidekker -
Jakob Eriksson -
Jeremy White -
Markus Amsler -
Simon.Tyler＠ddscanada.com