Move Apps from UNIX to Windows with SUA

Microsoft has provided support for UNIX applications on its flagship OSs since the release of Windows NT 3.1, which shipped with a POSIXcompliant subsystem. Assistance for UNIX applications and interoperability has gradually evolved, and Microsoft has invested in features such as networking support, daemons, and even X Windows. With the release of Windows Server 2008 and Windows Vista, now might be the time for enterprises to consider moving some of their legacy lineof- business applications from UNIX to Windows using the Subsystem for UNIX-based Applications (SUA). It’s easy to learn some of the features of the subsystem and how to install it, find download support tools and add-ons, assess the kind of support SUA offers for traditional UNIX applications, and build a UNIX application to run on Windows.

Install SUA
Before you can use SUA, which is included in Server 2008 and Vista, you must install and activate the feature. In the Control Panel Programs and Features applet, click Turn Windows features on or off in the left-hand pane. On Vista, in the Windows Features dialog box, select the Subsystem for UNIX-based Applications check box, as Figure 1 shows, and click OK. If you’re using Server 2008, start Server Manager, right-click Features, select Add Features from the menu, and select the Subsystem for UNIX-based Applications check box. (The necessary system files were installed when you installed Server 2008 or Vista.)

In the Subsystem for UNIX-based Applications folder that subsequently appears in your All Programs menu, you’ll see two shortcuts. The Help file shortcut takes you to details about new features in the subsystem. The Download Utilities for Subsystem for UNIX-based Applications shortcut takes you to the Microsoft Download Center, where you can download utilities and the software development kit (SDK) for SUA. Both 32-bit and 64-bit editions of SUA are available for Server 2008 and Vista. Download and install the combined package containing the utilities and the SDK—which is from 193MB to 210MB in size, depending on the version and target OS—on any system to which you’ll port or on which you’ll compile UNIX-based applications or use utilities such as UNIX-style shells. The download is a self-extracting executable. You must select a location to which to extract the files before setup can proceed.

Setup is a simple wizard that prompts you for your name, consent to the licensing agreement, and whether you want to perform a standard or custom installation. A standard installation places the most commonly used files in C:\Windows\SUA and configures your system accordingly. However, I recommend that you choose to do a custom installation and install only the components you actually need, such as support for BSD and UNIX System V–based utilities, GNU utilities and SDKs, and the Visual Studio plug-in. If you elect to install the GNU SDK, you need to accept an additional license agreement called the GNU Lesser General Public License, a copy of which is installed along with the SDK.

One step in the wizard that you must pay special attention to is security settings, which you can see in Figure 2. The options that appear (for standard or custom installations) depend on the choices you’ve made during the installation. The Enable Su ToRoot behavior for SUA programs option lets applications impersonate the root user (which is similar to Administrator on Windows systems) when User Account Control (UAC) is enabled. In many cases system applications and processes such as daemons on UNIX systems require this functionality; end-user processes such as data entry or customer maintenance programs rarely need it. The second option lets you enable setuid behavior, which refers to a UNIX application’s ability to impersonate the owner of the program. A common scenario on UNIX systems, this option lets users who wouldn’t ordinarily have access to databases or files run an application as the owner of the resource and gain access controlled by the application. Whenever possible, you should disable this option.

The third option is whether to switch Windows to case-sensitive behavior. By default, Windows is not case sensitive—for example, you can access a file called README.TXT by opening readme.txt. By making Windows case sensitive, you can allow multiple files in the same folder whose names differ only by their case, such as README.TXT, Readme.Txt, and readme.txt. A hacker with sufficient knowledge of how files are accessed can exploit this behavior. I recommend that you do not make Windows case sensitive and instead tackle case-sensitivity issues when porting applications. You can read details of the security implications of these choices in the Install.htm file in C:\Windows\SUA.

Explore SUA
After you install the utilities and SDK for the subsystem, additional items join the SUA program group, including (depending on installation options) a C shell, a Korn shell, release notes, and a link to check for critical updates. The simplest way to explore the subsystem is to launch one of the installed shells. From there you can explore the subsystem’s file system by using the UNIX cd and ls commands, which Figure 3 shows.

The root of the file system is mapped to the SUA installation directory, shown in Figure 4. To break out of the file system and access Windows local and network drives, you use the file system devices under /dev/fs. For example, /dev/fs/C accesses the root or the C drive, /dev/ fs/Z accesses a mapped network drive mounted as drive Z, and /dev/fs/C/Windows accesses the Windows folder.

When using the cd command or supplying paths to commands, remember to use UNIX’s forward slash (/) instead of the Windows backslash (\). Exploring common locations for executable files such as /bin, /usr/bin (which is a symbolic link to /bin), /usr/local/bin, and /usr/sbin reveals many command-line utilities that UNIX users will understand (e.g., cp, rm, mkdir, find, size, join, sort). In other directories you can find support for the X Windows subsystem, sendmail, and network services, aka daemons. I describe daemons later.

You can examine running subsystem processes by using the ps command. On its own, the ps command returns only the processes run by the user and launched from the shell. If you’re using multiple shells or want to view both subsystem and Windows processes that are running, you can use the ps command with the –x option (for information about all processes that belong to a user) or the –A option (for information about all processes on the system).

To learn about the options supported for each command in the subsystem, you can use the man command in a shell. The shells themselves are rich in features, and you can use them just as you would on a UNIX system. Figure 5 shows an interactive Korn shell script being used to unpack the zipped and tar’ed XFree86 UNIX distribution, which comes in several files. The Korn shell is a UNIX command-line interpreter like cmd .exe in Windows, but is much more flexible. Tar is a command that you can use to create archives of files and extract files from existing archives. It used to be a common means of backing up files to or restoring files from tape, but is now a utility most commonly used to create software distributions consisting of many files.

SUA Startup, Daemons, and Network Services
When Vista starts, so does the UNIX subsystem. Like UNIX, the subsystem has an init process that reads startup files from the /etc/rc2.d folder, which contains symbolic links to files in the /etc/init.d directory. On a UNIX system, you would ordinarily have additional folders, such as rc3.d and rc4.d, representing each runlevel and state the system could be in, such as single-user, no network connectivity, or fully up and running. Unlike UNIX, SUA operates only at runlevel 2. The names of the scripts in rc2.d begin either with Snn (for scripts called at startup) or Knn (for scripts called at shutdown), where nn is a two-digit number that’s used to control the order in which the script is called. A script that ends in 00 is called first; one that ends in 99 is called last. This support for daemon startup and shutdown makes it easy to port daemons to Windows Vista.

The subsystem provides support for services launched by inetd (a service dispatcher that manages Internet services), such as Telnet, FTP, and TFTP servers. SUA supports both IPv4 and IPv6. To enable a network service, edit the /etc/inetd.conf file to uncomment a standard service or to add your own. If you have an existing UNIX network service launched by inetd, SUA should be able to support the service after you port it.

X Windows Support
As I mentioned earlier, SUA supports X Windows. However, the subsystem doesn’t include an X server—you need to purchase and install either a commercial X server, such as Exceed from Hummingbird (www.hummingbird.com), or a lowcost or free X server, such as SourceForge .net’s Xming (www.sourceforge.net).

With an X server installed and running, you can operate the X Windows programs that ship with the subsystem, including such favorites as xeyes (a graphical program that displays two googly eyes that follow your cursor), a system clock called xclock, and xterm (the standard terminal emulator for X Windows). The subsystem ships with one X Windows manager: twm. In addition, SUA’s support for X Windows includes the header files and libraries necessary to build X Windows applications.

Continue to page 2

   Previous  [1]  2  Next