There are various ways to give your user community access to Linux applications, without wiping the hard disks of their PCs. The most commonly used ones are to give a user a second PC which runs Linux, to install a dual-boot environment with Windows and Linux, or to install Linux into a virtual PC environment such as VMware. But none of these methods provide a smooth and transparent mixed environment because the user will need to explicitly switch between the Windows and Linux environments.

Back in the old days, I managed mixed VMS and Unix environments. Although these two are very different platforms, both supported X Windows. Using the network capabilities of X, I was always able to create transparent mixed environments, where users would have only one workstation, but with access to applications running on both platforms simultaneously.

I decided to investigate whether the same would be possible with Windows and Linux. The goal was to leave the users' PCs still running Windows, but give them access to applications running on a remote Linux machine using X Windows. Linux GUI applications are all based around X Windows. When the graphical environment starts on a Linux machine, an X server is started, serving the keyboard, mouse, and screen to X client applications. The clients communicate with the server over pipes, or a TCP/IP connection to the local host, with a protocol called X11.

X11 is also suitable to run over a network connection to/from another host. Client applications look at the DISPLAY environment variable to find the X server that they need to display to. Many programs also accept a -display command-line qualifier to redirect X11 to another X server. X11 is a platform-independent protocol, so the X server can just as easily run on a machine with an operating system that is different from that on the client. I set out to run applications on a Linux machine with an X connection back to a Windows PC.

The client applications are there, and need no modification, so the quest was on for an X server for Windows. There are a number of commercial packages on the market that achieve this. I looked for a port of the open source X system (XFree86), but found that it would only work with Cygwin, which is a complete Unix-like environment for Windows. That seemed somewhat complex, so I tried the commercial packages first.

I got evaluation copies of X-SecurePro from Lab-Tam, and Exceed from Hummingbird. The latter is much better known, but is also far more expensive. Both packages provide an X server and a variety of other Unix-like tools such as NFS, telnet, and so on. Both also provide a GUI starter program that will connect to a remote machine using rsh, rexec, or telnet and execute a command to start an application that connects back to the Windows PC for its X server.

The X server in both products can be run in two modes: full-screen or multiwindow. In full-screen mode, a single large window is displayed on the Windows PC, which is an entire desktop in which the X client applications will create their windows. This is great to run an entire Linux desktop under Windows, but this wasn't what I was looking for for my mixed environment. In multiwindow mode, each X client application is displayed in its own window, with a standard Windows title bar with the normal Windows buttons on it. For a mixed environment this is what's required.

For my tests, I wanted to run a standard xterm window, the GNOME Terminal, OpenOffice.org, and Evolution. I found neither of the X packages working satisfactorily out of the box. xterm worked without problems, as this is a very basic X11 program that does not require any unusual fonts or extensions. The GNOME Terminal was not so good. The terminal window was displayed using a font that was too small, making it very difficult to read, and the menu items were badly rendered, making it all very ugly (see Figure 1). OpenOffice.org and Evolution were treated with some double-spaced font that takes up so much space that it becomes completely unusable (see Figure 2).

To be fair to these products, it's very likely that these problems can be resolved. X11 is a base protocol for getting requests and responses over the network from a client to a server and vice versa. To display a string of text on the screen, the X client simply requests the string to be displayed with certain font parameters in a certain position on the screen. The X server then looks for an appropriate font file and renders the text for display on the screen. In addition, many extensions have been created, mainly for graphics-intense applications, aimed at reducing the bandwidth usage of X and offloading complex actions from the client to the X server. But for this all to work, there needs to be a match between what the X client requires and what the X server has to offer. In my case the right fonts were not supplied with the X server, and the applications also complained about certain extension modules not being available in the server. If you can find the fonts and the required extension DLLs, then both products can probably be made to work in the scenario described above.

But as this was a no-budget project to see how easy (or difficult) it was, I couldn't afford the time to look into these. Instead, I decided to try the XFree86 Cygwin port. Cygwin is a Unix-like environment for Windows that consists of a DLL that implements most Unix system calls and maps them to existing Windows API calls, and a set of tools and commands ported within this environment. With Cygwin it is possible to take Unix/Linux source code, compile it on Windows against the Cygwin DLL, and then run it as Windows applications. Some of the tools ported in this manner by Cygnus are the gcc compiler and the XFree86 system, as well as various shells and shell commands.

All Cygwin modules are installed with a single installer. The setup program is downloadable over the Web. When started it asks which packages you want to download and/or install. XFree86 is simply one of the options available from this setup program.

It took a wee while to download the packages, but they were untarred in no time, and my system was ready to go. There is no need to configure X as is required on Linux. There is no need to select a graphics driver and such, as XFree86 on Windows simply works with the generic Windows Graphics API. Therefore it uses whatever graphics card driver is installed for Windows itself. Older versions of XFree86/Cygwin supported only full-screen mode, but earlier this year an option was added to support multiwindow mode.

The X server is started by a batch file called startxwin.bat. As an entire Unix-like environment (based on GNU), Cygwin also provides a bash shell and a good set of Unix commands. The default version of startxwin.bat makes use of this and also starts an xterm with a bash shell running locally. If you want to run Unix shell scripts on Windows, then Cygwin is also useful just for that.

Next, I telneted to a Linux machine and typed:

xterm -display eno:0 &

('eno' is the name of my Windows desktop machine). First, I got an "access denied" message. The default security in XFree86 does not allow remote applications to display on the server. A simple

xhost +

in the locally running bash shell fixed that. The xhost program adds entries for remote machines to the allowed list, and the "+" simply allows everything under the sun. Not a good setting for a production environment, but for my testing it was sufficient.

Back to the xterm command, and now a beautiful xterm appeared on my screen with a bash shell under Linux. Next was the GNOME Terminal application. No problems at all with this X server, as the correct fonts were used, making it look exactly the same as it does on Linux. Of course this is not much of a surprise because the applications on the Linux machine were expecting to run against an XFree86 server and all the required fonts and the extension module are available in the Windows port.

I then set out to run OpenOffice.org and Evolution. As far as graphics were concerned both ran fine, but I found that not all windows were appearing on my Windows machine. After a bit of investigation I figured out that if I started Evolution from my telnet session using the -display command-line parameter, then some of the windows were still appearing on the remote machine where the program was running. Evolution starts a number of subprocesses, and the display parameter was not passed on to these.

However, when running Evolution from my remote xterm window everything worked fine. When you run xterm with the -display parameter, a bash shell is started inside it, and the DISPLAY environment variable is set to point to the server and screen specified on the command line. Evolution looks at this and connects to the right server. All its subprocesses inherit the variable and now also display to the same screen.

Using XFree86/Cygwin I am able to create an environment in which I can run local Windows applications and remote Linux applications that all display in their own window on the PC (see Figure 3). That part of the transparency is achieved quite easily. The only missing bit is a simple tool to start a remote application, as provided by the commercial packages. Using telnet and xterms is not quite the mechanism I want to give to users. I'll need to do a bit more searching on the Net for this, or if that fails I'll write one and publish it under the GPL.

Once that is achieved, I will be able to give users access to Linux applications to let them see for themselves how beautifully they work. Once they are used to those, I can start thinking about giving them the full Linux operating system on their desktop machines. By then, they will be familiar with the applications and the change to a complete open source environment will be a lot less scary.

Client vs Server
Newcomers to X11 often get confused by the fact that the concept of "client and server" appears to be the wrong way round. In fact, it is not. Let me explain.

The concept of client-server technology is shown in a very basic diagram (see Figure 4). The yellow box on the left is a server process, running on one machine, serving a resource to a number of client processes running on the computers on the right. I've shown three computers running a total of four client processes, two red ones and two blue ones.

In the case of database client-server technology, the computer on the left is a server-class computer with large amounts of disk space and probably hardware RAID, which provides a database resource to applications running on the machines on the right, which are most often workstations or PCs. The database server on the left serves its database to the client applications on the right. In this picture the user will usually sit at the machines on the right.

In the case of X11, the computer on the left is again running the server process, but the resources served are a keyboard, a mouse, and one or more screens. It serves these resources to client applications running on the computers on the right. The concept of client and server is the same, but the nature of the resource being served now means that the user sits at the computer on the left. The X server runs on a machine with keyboard, mouse, and screen(s), such as a workstation or PC (or even a diskless thin client), while the X client applications run on other machines on the network, which may be other PCs, or server-class machines without graphics capability, or even blade servers.

The designations of "client" and "server" remain the same in that client applications make use of a shared resource provided by a server process. It is still a case of multiple clients accessing a single server. The difference is that the user sits on the "other end" of the client-server division, because it is the keyboard, mouse, and screen that are the served resource.

• Cygwin/XFree86
• Hummingbird Exceed
• Lab-Tam X-SecurePro
• X11
• The XFree86 Project