Home Page

All the Graphics
Update Notes



Windows Clients for Linux Servers
By Thiravudh Khoman

These past few months I've been playing with Linux quite a bit. But since I'm also a Windows user, my mind is never far from stuff that tries to bridge the two operating systems. For this article, I'm going to look at programs that allow Windows machines to act as clients to Linux servers (hereafter, whenever I mention "Linux", the more general "Unix" should also apply). My plan is to focus on ssh, NFS and X clients, although I'll touch on a few other clients as well.

Already Bundled Stuff

Ever since Windows 95, Windows has come bundled with a few client-side programs that may be used to access Linux resources at a very basic level. First of all, there's telnet, a DOS-based remote terminal program that can be used to connect to a Linux telnet server. This gives you the ability to run a "shell" session as if you were typing at the host computer itself (albeit a bit slower) or from a dumb terminal (which is essentially what telnet relegates your computer to) (figure 1).

Also available is HyperTerminal. While probably intended as a modem-based communications program, HyperTerminal can also be used as a telnet client. In fact, it makes a prettier and more intelligent client, since it is Windows-based and allows you to buffer and capture your terminal session to a file (figure 2).

Next, we have ftp, another no-frills DOS utility. ftp works pretty much like its Linux counterpart, although it probably has fewer built-in functions. But yes, it does work and in fact, I still use whenever I'm too lazy to load my GUI ftp client (figure 3). If you prefer to ftp à la GUI though, you probably have the means to do that too. Say hello to your web browser cum ftp client (figure 4).

Finally, all versions of Windows for the past ten years have come with a pre-bundled Samba client. Huh? Sure, it does - it's called the "Client for Microsoft Networks". You know, that network component that allows Windows computers to talk to each other via Microsoft Networking - which is what Samba running Linux is all about, right?

Basic Third Party Stuff

Assuming you feel the need to use third party software instead of Microsoft branded stuff, there are some obvious replacements for the above (not all though, since it's likely you'll find a replacement for the likes of the "Client for Microsoft Networks").

For example, there must be dozens of telnet clients out there for DOS and Windows. Take your pick. Or better still, forget about it completely. You should be using ssh instead of telnet anyway. I'll explain why soon.

A better third party replacement would be your ftp client. Since you already have a command line ftp utility that works like most command line ftp utilities, there's no good reason to replace that. Instead, leave it alone, leave your web browser for web browsing, and go searching for a nice GUI ftp client. Again, take your pick - there must be dozens of those as well. For the record, the one I've been using since day 1 has been Ipswitch's WS_FTP LE, currently at v5.08) (https://www.ipswitch.com/downloads) (figure 5). It may not be the most feature- laden ftp client around, but it meets my needs and it's free. Or go for the Pro version if you wish to spend money. But as mentioned, there are A LOT of these around, so shop around first.

ssh (Secure Shell)

As I previously hinted, you should use ssh instead of telnet. telnet, when it runs, sends information (including passwords) across the wire in plain text, which makes it terribly insecure. Another shortcoming is that it is not possible to telnet into a Linux box as "root" (actually, you can, but you must release the default "safeties" first; either that or telnet in as a regular user first and then do an "su").

ssh is also a terminal program, but with a big difference. Originally developed by SSH Communications of Finland (https://www.ssh.com), ssh encrypts the data that it sends. This added encryption makes remote "root" access less risky. As a result, ssh should be seen as a replacement of - rather than a complement to - telnet, at least for remote server access, even if you operate in a closed environment. The only possible exception to this would be for hardware device configuration where telnet is still needed.

For this article, I tried my hand at two ssh clients for Windows: a) PuTTY at version 0.53 beta (https://www.chiark.greenend.org.uk/~sgtatham/putty), a freeware program written by Simon Tatham of the U.K., and b) Axessh at version 2.2 (https://www.labf.com/axessh), a product of Finland's LabF. Axessh costs $20 to buy, but can actually be used free of charge for a maximum of 30 minutes per session. (By the way, additional ssh clients can be found on OpenSSH's website at https://www.openssh.com.)

Both programs installed easily and the only real choice you have to make is whether to operate it in regular telnet mode or in ssh mode. Overall, my preference was for PuTTY (figure 6) (figure 7). The fact that it's a free program has something to do with this, but I also found its operation smoother and faster than Axessh's (figure 8) (figure 9). But on the other hand, if you're also using LabF's other programs (such as nfsAxe - see below), you might prefer to keep it all in the family.

NFS (Network File System)

NFS was originally developed by Sun Microsystems to permit the grafting of remote file systems onto your local file system. It is a standard component that's found on all Unix/Linux systems, but has never caught on with DOS/Windows. Microsoft's presumed lack of interest in supporting NFS may be one reason for this. But so was Sun's presumed indifference and attitude that PC's were no better than toys (at least compared to the "iron" they were selling). Another explanation is that third-party companies that WERE interested in providing NFS support invariably priced their TCP/IP suites at such high prices (i.e. several hundred Dollars apiece) as to limit their widespread use.

The result is that there is a only a limited offering of Windows-based NFS products today, and in fact, many of those third-party companies that used to offer it are gone. Add to this the fact that anyone who really needs to do NFS on a PC these days will probably be better served by using Linux on their desktop instead.

To the best of my knowledge, NetManage (one of those oldtime TCP/IP companies), still offers an NFS product as part of their ViewNow Unix suite (which sells for $1000+), although you'd be hard pressed to find it when you visit their home page (https://www.netmanage.com). Meanwhile, Hummingbird (https://www.hummingbird.com) sells a product called "NFS Maestro" which consists of an NFS client only for $245 or a server for $395.

The above prices feel unreasonable to me. As a result, I tested only one Windows NFS proudct, called nfsAxe, a product of LabF, the same company that produces the aforementioned Axessh. Like Axessh, the software is not freeware (costing $40), but it can be tried/used for the same 1/2 hour/session time limit.

In actual fact, nfsAxe is an NFS Server, and an NFS client isn't even automatically installed, even though it is provided. There are two versions of the client - one for Windows 9x and one for Windows 2K/XP. Even the word "client" is somewhat of a misnomer, since there is no separate program to run after everything is installed.

To access your Linux server's NFS mount points, you take the following path:

  • My Network Places > Entire Network > XwpNTrdr (figure 10) > Remote NFS Servers (figure 11), and then click on the host you want ( in my case - figure 12), choose the shared folder (pubdir in my case - figure 13), login if necessary, and you should now see the files/folders in the NFS shared folder (figure 14).
  • Or if you prefer, start from Windows Explorer and then follow the same path as above. While you're there, it's a good idea to map the shared folder to a network drive because it will speed things up the next time you need to access the share.

Of course, what you will or will not be able to do in the shared folder depends on the permissions set at the NFS server. This has nothing to do with the client.

* * * * * * * * * *

Since nfxAxe can also act as an NFS server, I took a quick detour and peeked at how the server portion works also. For this test, I configured a minimum number of things: I only set up the drive/folder to be shared (J:\) and gave all users read/write permissions (figure 15). Here's what the NFS system console looks like when it's running (figure 16), and here's what it looks like when I'm mounting the Windows folders via NFS from the Linux end (figure 17).

All in all, I was quite pleased with the performance of nfsaXe. Even the price tag wasn't too bad, especially given the fact that you get both an NFS client AND a server, not to mention a few other freebies too, such as telnet, FTP, TFTP, LPR and LPD.

X (X Window System)

X or the X Window System (never, ever say "X Windows") was born out of the Masschusetts Institute of Technology's "Athena Project". It employs a client/server architecture that allows the graphics processing to be performed on a "server" with the resulting display sent to a "client". More often than not, both the server and the client exist on the same physical machine, but this is by no means a necessity. The X server could easily serve displays to physically separate X clients. In a pure Linux environment, this is easy to accomplish: simply ssh from one Linux box to another and then run any X application you wish from the command line.

Most versions of Linux employ XFree86, an open source version of the X Window System (https://www.xfree86.org). But non-free implementations also exist, notably Xi Graphics' (https://www.xig.com) Accelerated-X line of products.

XFree86.org itself doesn't provide an X server/client for DOS/Windows, but several third party vendors do. These include:

(Note: MicroImages' website lists a number of its X providers/competitors for comparison purposes. Vide: https://www.microimages.com/mix/prices.htm.)

Hands on X: Mi/X

Given that Mi/X's price was the lowest, of course it was the first program I wanted to try. Unfortunately, MicroImages' website warned that the trial version of Mi/X was only configured to be used with their TNT series of geospatial analysis programs. Not deterred, I tried it anyway, and here's what happened:

  • I installed the trial version of Mi/X v4.0 on my Windows machine.
  • I telnet'ed (I know, I know, but I removed ssh already) into my Linux box.
  • I issued the following command: export DISPLAY= (this being the IP address of my Windows machine, the one that's running Mi/X).
  • I ran kedit (KDE's editor).
  • A few errors appeared on the telnet screen about missing extensions, but guess what showed up (figure 18)?

Hands on X: WinaXe

Having partaken of LabF's Axeshh and nfsAxe programs, I was looking forward to putting WinaXe through its paces as well. The fact too that LabF had a substantial manual for me to read also swayed me (with Mi/X, I was flying by the seat of my pants, with the help of only a single FAQ file).

(By the way, if you're wondering what the difference between WinaXe and WinaXe+ is - the latter bundles in *ALL* of LabF's programs for a mere $10 more. You get WinaXe, Axessh, nfsAxe and an ftp client, ftpAxe at a $70 savings. In my opinion though, the ftp client is uninteresting and not worth the $20 asking price.

Like LabF's other programs, WinaXe version 7.2's installation was effortless. Here are the steps I took next in search of X nirvana:

  • There's an XSettings configuration utility with a whole bunch of settings that can be tweaked (figure 19). Except for enabling the wheel mouse, I left everything else unchanged (there's a time and place for such things).
  • Next, I ran the XSession program. After a copyright splash screen displayed, another window barely appeared before quickly minimizing itself.
  • I then remembered that I had to login to the remote Linux box first before anything would show up on the X display. I used ssh this time instead of telnet since Axessh also gets installed with WinaXe+. (By the way, using ssh means never having to export any DISPLAY environments variables like you do with telnet.)
  • At the ssh terminal prompt, I ran kedit again and voilà, this is what I got (figure 20).
  • The problem about running X apps this way is that you have to remember the exact names of the apps you want. I prefer to have a desktop similar to what I get when I run KDE. Thus, I decided to try running Konqueror from the terminal screen (which I did with a lower case "k"). This is what appeared (figure 21).
  • Notice what we have here: a) a Windows 2000 Start menu is popped up at the bottom left, b) the grey bar at the bottom is a Windows launch bar, c) a Windows system tray can be found at the bottom right, while d) the rest of the screen is occupied by KDE's Konqueror.
  • From here, I can browse to any application represented by an icon and run it by pointing and clicking.

All was not perfect though:

  • As with Mi/X, I received a few errors regarding missing GLX and RENDER extensions, but nothing crashed.
  • I also noticed some incorrect font usage/substitutions in certain programs.

Clearly, some tweaking, not mention more careful manual reading, will be required for a perfect "off-world" rendering, but again, none of the problems I encountered were fatal.

I must admit that I was impressed. Being able to run practically any Linux program as well as any Windows program in this manner makes for a pretty clean solution. In my opinion, it's far preferable to dual booting, and is simpler and cheaper to implement than complex solutions like VMware (https://www.vmware.com) - assuming, of course, that you have a second machine to act as a server. I must also commend LabF for their suite of programs. They've performed well and they're relatively affordable.

What I Missed

  • There's an ssh for DOS called SSHDOS (https://www.sshdos.sourceforge.net), but it requires a packet driver to operate. Unfortunately, I couldn't find one for my NetGear FA311 network card. (Grumble, grumble. I suppose I'll have to swap network cards ...)
  • Cygwin, an open source Unix-like environment that runs on top of Windows, also has an XFree86 implementation (https://www.cygwin.com/xfree). Unfortunately, I couldn't get the setup program for the base package to run properly - it kept hanging regardless of how I tried to install it. Thus, I missed an opportunity here as well.

Keep an eye out for my update notes in case I get either of these working.


Ashton Mills, "The Wonders of X", APC Magazine, December 2001
Ashton Mills, "Windows onto Linux", APC Magazine, January 2002
Richard Sharpe, "Accessing xterms from Windows", LinuxWorld, September 2000

Copyright © 2003, Thiravudh Khoman