Windows Services for Unix 3.5

Microsoft wants people to use its operating systems and applications rather than anyone else's. No surprise there. Providing a toolkit to help users migrate from other platforms to Microsoft’s own isn’t exactly unprecedented either. But to provide a toolkit that makes Windows behave like Unix may sound a little far fetched, especially when it contains open-source software. When you consider that all this is given away, it sounds too good to be true. Unfortunately, in some respects this is the case.

Windows Services for Unix (SFU) is a toolkit designed to allow Unix users to integrate with and migrate to a Windows environment without having to throw away applications, scripts and other familiar tools. This typically includes shell scripts to automate various tasks, but can include running applications written for Unix on a Windows machine. Previous versions of SFU have been available, but none is as comprehensive as version 3.5. They’ve also previously been charged for: version 3.5 is a free download, or a minimal-cost CD-ROM.

What you get
SFU 3.5 consists of a POSIX-compliant subsystem, a server and a client for NFS, a Windows-to-POSIX name mapping system, an NIS server and a telnet server for those versions of Windows that don’t already come with one. The POSIX subsystem is meant to be a complete replacement for a Unix environment, and includes the GNU C compiler and libraries. The other components allow the two environments to interoperate if necessary, although if you’re happy treating them as entirely separate systems, you can get away with installing few, if any, of these other components.

Name mapping
The name mapping service manages the relationship between Windows user names and the Unix user names used for the other services provided. This is necessary because of the different models used for user names in the two systems. The service allows one-to-one or many-to-one mapping of users, so that lots of different Windows users can be mapped to the same Unix user. This service underpins all the other Unix-like services provided as part of SFU, and will need installing on most machines on which you want to use SFU if you want to use a single set of credentials for both environments.

NIS server
The NIS server allows the Windows machine on which you’ve installed SFU to act as the NIS master for all the Unix systems on your network. This isn’t the same as participating in an NIS domain using the name mapping service. Instead this uses a Windows Domain controller as the NIS domain master. You need to be using Active Directory to use the NIS server, since an AD container object is used to manage the NIS domain. NIS server supports Unix machines as backup NIS domain servers, but the Windows system has to be in charge. If you do choose to move across to the NIS server, a migration wizard is provided to move your existing user accounts across to Active Directory.

NFS client
The NFS client and server allows Windows and Unix systems to share files with natively. The server allows you to store files that were previously stored on a Unix host on a Window server without needing to install extra software on any Unix clients that need to access those files. Equally, you can use the client service to access files stored on a Unix server. There is also an NFS gateway in SFU, which allows a Windows server to serve files held on an NFS server to native Windows clients. However, you can achieve the same end either by installing the NFS client on users’ machines if there aren’t many of them, or, for more users, by migrating the files to a Windows server and installing the NFS server. One oddity of the NFS client is that since this is a Windows component, the mount command isn’t available under the POSIX subsystem, only the Windows command line. This could possibly cause some problems if your scripts involve mounting NFS volumes -- you’ll have to mount the volumes manually before running the scripts, or invoke a separate Windows batch file to do it. Either way you’ll have to rewrite your script. All the services in SFU can be administered using the Windows management console or via the Windows command line. This latter option allows you to administer the services remotely through the telnet server supplied with SFU (or the one supplied with later versions of Windows). It will also allow automated provisioning of these services on multiple machines -- you can run a batch file to install whatever components you want.

POSIX subsystem
The POSIX subsystem is a third-party product from Interop Systems, called Interix. As standard you’re supplied with Korn and C shells, the GNU C compiler and libraries. Most standard Unix utilities -- grep, awk, sed, for example -- are included with Interix. However, there’s a strange mix of GNU tools, and some provided by Interop Systems, which appear to be versions of BSD tools ported to Interix. This hybrid GNU/BSD environment causes a few minor problems. For instance, the version of tar installed doesn’t read some tar files created in other versions properly, resulting in an error, despite all the files in the archive having been unpacked correctly. This initially caused us some problems when trying to install some pre-packaged applications, but installing the GNU tar program solves this -- another alternative you have is to use a Windows archive application that understands gzipped tar files to unpack the archive. The shells run as Windows console mode applications. They don’t have QuickEdit mode enabled by default, so if you want more Unix-like copy and paste operations, you’ll need to alter the program properties for each shell or command-line application you use. Despite the libraries for X Windows applications being provided as part of Interix, there isn’t an X Server for Windows supplied with SFU. Microsoft points out the large number of free and commercial X Servers already available, and says that if you need to run X applications locally you should obtain one of them.

Filesystem
Interix emulates a single-rooted filesystem, which supports hard and symbolic links. The root of the emulated filesystem is the SFU install directory, with Windows drives being represented as devices, so that, for instance, D: is /dev/fs/D -- if you need files from separate Windows volumes to appear at more convenient points in the Interix filesystem, you’ll have to link them manually. There are some issues with paths and file names containing spaces, in that some Unix programs aren’t able to read some paths properly, even though spaces are generally allowed in Unix filenames, and the shells provided are able to work with them. Perl is the only scripting language supplied with SFU. You can install Perl under the Unix environment, and ActiveState Perl for Windows is also provided, so you can run Perl programs in either system. However, the two don’t really interoperate, so that libraries installed in one environment aren’t necessarily available in the other. Some clever tweaking of symbolic links will make this possible, but it’s not the default configuration. Interix is claimed to be fully POSIX compliant, and we can’t challenge that claim. However, it seems that this may not be enough to make it easy to move applications from your existing Unix platform to Interix. In our tests, GNU applications don’t necessarily configure, compile and install without tweaking. We couldn’t get the standard Unix distribution of Python to install, for example, despite a successful compilation. The fact that Interop Systems has made available special packages for many GNU applications is evidence that porting applications to SFU may not be as straightforward as is claimed.

Alternatives
There are alternatives available for running Unix applications on Windows, but they rarely include the other services that Microsoft is providing here. It might be possible to assemble a similar toolkit yourself from third-party components, but that’s more work than just downloading SFU. Alternatively, you could mix-and-match the components from SFU and other toolkits to get the combination you need -- in many cases, you don’t even need to install the components on the same machine to get the same facilities. Windows Services for Unix 3.5 will be useful to developers working in a mixed environment, since you’re able to run scripts on your desktop that would otherwise have to be run on a separate host. Similarly, Unix system administrators can use some of SFU’s components to perform tasks in the same way as with their Unix machines. If you depend heavily on the GNU toolkit for your work, you may be less than impressed with SFU, since you’ll have a job on getting many packages to install correctly -- it’s not impossible, but a certain amount of tweaking will be needed. SFU is interesting as a glimpse of the way Microsoft is taking Windows -- more command-line administration being one example. It’s unlikely to be the deciding factor in mass migrations from existing Unix installations to Windows, but if you’ve already made a decision to move to a purely Windows environment, SFU will ease the pain somewhat. If you want to use Windows for some jobs that would otherwise need a Unix machine, SFU is a neat toolkit, but there are others available.

Images