If NeTraverse can deliver on Win4Lin's promise -- that is, the ability to transfer existing "fat client" Win9x licenses to a Unix-based thin-client environment -- the future of alternative thin-client computing will become rather interesting for those who'd rather avoid Windows 2000 for Windows terminals. If you run a Unix shop on a budget and are without Terminal Server expertise in-house, this solution is a great fit. Those using Win2000's terminal services, however, will probably want to stay with it.

Multiuser Win4Lin builds on the current Win4Lin 2.0; it uses BIOS emulation to run a Windows virtual machine on top of the Linux environment. The difference between multiuser Win4Lin and Win4Lin 2.0 is that the multiuser version scales to as many sessions as you have licensed, limited only by RAM and disk space. While testing, I was pleasantly surprised at how fast the sessions ran, even when running several users on an IDE-based Pentium III, 400-MHz system with 128 MB of RAM.

I installed Win4Lin on top of our Slackware Linux server and then ran the Win4Lin system setup. The setup program prompted me for a Windows CD and then copied Windows .cab files down to the Linux file system. I ran the per-user setup for one Win4Lin user: It brought me through the standard Windows 9x installer in an X Window and installed the appropriate files in the user's $HOME path.

Because I am a staunch believer in image installs when it comes to Windows, I reasoned that using the cpio utility to copy the Windows files from one user's home directory to another would be a faster way to set up the next user. This worked just fine, and I set up several test users. Users required about 144 MB of storage for each individual Windows setup.

System memory statistics showed me that each additional Win4Lin session consumed several hundred kilobytes of RAM before applications were loaded. My testing with four simultaneous sessions showed that each session took slightly less physical RAM than the last. Although I didn't run rigorous performance tests, simultaneous access of these sessions seemed well within acceptable response time limits.

Lookin' Good, But On A Diet

Some implementers will find the 144 MB of hard drive storage to be a bit much of a per-user requirement. After all, 50 users into it, you have 7 GB -- just for the basic Windows load!

There are two saving graces: First, NeTraverse says it is working on some re-entrant code that will shrink the RAM and disk space numbers by quite a bit, but this code wasn't yet available for me to test. Second, a shared "J:" directory is available, where you can put network installs of application files. Otherwise, you'd need a copy of each application, which would really start to eat up drive space.

My goal was to test how well a typical user could be insulated from the underlying Linux environment. Instead of running a traditional X Window manager, I created a standard X session file for my test users that kicked them straight into Win4Lin at login. No problem! My users saw an X login box on their terminals, and then magically got the Windows 98 desktop they know and love. When I intentionally crashed the Windows sessions, I was able to log back on much more quickly than a user would be able to reboot a PC.

Some Roughage

The applications I tested with Win4Lin -- Microsoft Office, Novell GroupWise 5 and Rit Research Labs The Bat mail client--were well-behaved and mostly didn't notice that they were running on a Linux server. But I did run into a couple of very minor rough spots along the way.

For example, our lab is behind a Socks proxy server. Although Microsoft Internet Explorer worked great, the mail client I used requires a Socks launcher to use the proxy. The Windows-based Socks launcher failed, and I could not use Linux's native runsocks either, as Win4Lin apparently doesn't use Linux shared libraries for communication. NeTraverse says it's aware of this and is working on the problem.

Finally, as I considered how I'd roll this out to our users, I tested the product's printing capabilities. The printing works just fine, but there is no native queue control mechanism -- at least not in the beta I tested. NeTraverse says that queue control, which is essential for any office productivity rollout, should be in the released version.

I was also disappointed that Linux's native X protocol is the only available display protocol. Obviously, X is a bit long in the tooth, and is nowhere near as efficient as Citrix Systems' ICA (Independent Computer Architecture) protocol, Microsoft's RDP (Remote Desktop Protocol) or Tarantella's AIP (Adaptive Internet Protocol). Multiuser Win4Lin implementers won't even want to consider using X as the display protocol for WAN users. But in our busy switched 100-Mbps Ethernet environment, the LAN performance of X is just fine. Unfortunately, if you want more display protocol efficiency, you're going to have to add a third-party application, such as Tarantella, to the mix.

NeTraverse could also automate the addition of users a bit more, by giving admins some menus to do what I did manually. But this is a minor quibble: Once you're used to the manual methods, the product scales easily and, most important, performs admirably.