A nod toward Unix

OPERATING SYSTEM VENDORS talk a good game in terms of interoperability, but their objective is to get you off competitors’ software and onto theirs. As such, transparent interoperability is not a high priority for the likes of Microsoft, Sun, and IBM. But It is a priority for companies that constantly struggle to improve connections between old assets and new and to tie together solutions from different providers.

With this in mind, Microsoft SFU (Services for Unix) 3.0 is a pleasant surprise. First of all, it’s dirt cheap: $99 per machine, be it client or server. SFU installs a POSIX (Portable Operating System Interface) — an IEEE standardized Unix, if you will — subsystem, tools, and utilities into Windows, not quite turning it into Unix but coming as close as Windows can get. The SFU package includes the compilers, header files, and libraries you need to compile a healthy selection of Unix software, including (gasp!) open source.

Unix on Windows

SFU 3.0 adds relatively little to the products that were Services for Unix and Interix. The unified install makes quick work of moving the POSIX layer and tools into place. The POSIX layer, an API that communicates with the Windows kernel, occupies the same level as Win32. The POSIX subsystem is invisible to applications that don’t use it.

Unix file-sharing is accomplished through SFU’s NFS (Network File System) client, server, and gateway services. These facilities do for Windows what Samba does for Linux and Unix: The NFS services give Windows hosts access to files stored on Unix and Linux systems, and vice versa. NFS file-sharing is seamlessly integrated into Windows. Release 3.0 adds support for Unix symbolic links, enhanced file permissions, international character sets, and improved performance.

Cross-platform authentication is a challenge that SFU attempts to meet. The new release features a two-way password synchronization facility that, by itself, might be worth the product’s price. Users can log in once and access resources on both Unix and Windows networks. SFU also can access user credentials hosted on Unix NIS (Sun’s Network Information System) or PCNFS, Sun’s PC edition of NFS. SFU loses points for its lack of a secure remote terminal. Only an unencrypted telnet client and server is provided.

The advantage of User Name Mapping is that users needn’t have a matching log-in name on Windows and Unix. They don’t even have to know that their Windows log-on has NIS credentials associated with it.

Talking code

The development tools include the GNU C, C++, and Fortran 77 compilers. All the tools and libraries are old by Linux standards. For example, SFU’s included version of the GNU C compiler is 2.7.2, whereas GNU’s current release is 3.0.4. Included POSIX libraries cover everything from ANSI C to the X Window System GUI. Unfortunately, SFU 3.0 does not include an X Window server, so it’s not possible to run remote graphical Unix clients on your Windows desktop.

Compiling an application using the SFU tools produces a native Windows executable or shared library. SFU applications cannot intersperse Unix and Windows system calls. You can create a COM (Component Object Model) wrapper around an SFU program or expose an SFU app as a .Net Web service. But for performance and portability reasons, most SFU code has to be 100 percent Unix.

The hundreds of command-line utilities on the SFU CD handle everything that might be called from typical C shell, Korn shell, and Perl scripts. The simulation of a Unix environment is convincing. The fragmented Windows file system, with its idiotic drive letters, looks unified when accessed from a Unix shell or application. SFU’s version of the ps (process status) command lists non-POSIX Windows processes, and you may use SFU’s kill command to terminate them. The simulation of the Unix environment wouldn’t fool an expert, but most Unix developers and administrators will feel right at home.

The catch

It’s hard to find fault with SFU 3.0; its price and capabilities make it an exceptional value. However, SFU’s primary competition comes from Linux and BSD, which can be had for free. Those environments can’t match SFU’s mature and transparent ability to run recompiled Unix applications in a Windows environment.

However, a Windows machine running SFU doesn’t come close to the Unix capabilities of a server or workstation running Solaris, AIX, BSD, or Linux. For example, the SFU libraries support only the most basic X Window interfaces. Clients that use the KDE or GNOME graphics libraries won’t port, at least not without enormous effort.

With SFU, Microsoft can argue that virtually every Unix/Linux/BSD server or client in the building requires a Windows CAL (client access license). Even if you only use SFU’s telnet server to run a Windows terminal session on a Solaris workstation, you’re accessing Windows services and therefore need a CAL for that machine. We dare not imagine how complicated and contentious a license audit would be if SFU were in use. There are many non-Microsoft interoperability scenarios that don’t call for per-seat vendor licenses.

The jaundiced take on SFU is that it’s Microsoft’s effort to stem the loss of CAL revenues to open software. That might be accurate, but it obscures SFU’s worth as an interoperability solution. A company that buys CALs in bulk and has plenty to spare won’t mind reserving a few for the Unix boxes in the building.

Developers working on cross-platform software will really appreciate SFU’s blending of Windows with Unix. It feels strange the first time you fire up Visual Studio to hack Unix code, but it quickly grows on you. Developers and administrators can use SFU without creating license quandaries, and they should. Services for Unix bring just enough of what’s good about Unix — albeit a somewhat dated kind of Unix — to Windows.