Move Apps from UNIX to Windows with SUA - 10 Sep 2008

Executive Summary: With the release of Windows Vista and Windows Server 2008, it’s a good time for enterprises to consider moving some of their legacy line-of-business applications from UNIX to Windows using Microsoft’s Subsystem for UNIX-based Applications (SUA). Easy? Yes. Intriguing? Ditto.

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.

Problem: Since Windows NT 3.1, Windows has supported POSIX applications. However, the lack of built-in features and tools needed to port UNIX applications to Windows forced many users to purchase and use third-party tools.

Solution: Install and familiarize yourself with the Subsystem for UNIXbased Applications (SUA) for Server 2008 and Vista.

What You Need: Server 2008 or Vista, an Internet connection, an X Server package (optional)

Solution Steps:

1. Install SUA.

2. Download and install additional utilities and the SDK from the Microsoft website.

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

Port Shell Scripts With fully functional C and Korn shells along with the usual crop of data-crunching tools such as sort, uniq, and col, porting most shell scripts should be relatively easy. Good candidates are scripts that transform data files—for example, sorting or merging them, removing duplicates, or filtering out selected columns before they are loaded into or after they are retrieved from a database—and a script that uses FTP to send or receive data files. The FTP client and server that come with the subsystem are more functional than their Windows counterparts. Many organizations still rely on FTP to move vast amounts of data and depend on UNIX systems for additional features and scriptable FTP clients.

Build C and C++ Applications SUA includes support for porting UNIX C and C++ applications, but you need to know a few things. The subsystem comes with support for the GNU C and C++ compilers. However, the default is to use compiler interfaces to Microsoft Visual Studio, which must be installed. Visual Studio can be used to compile only applications that are written in C—not in C++. Figure 6 shows the contents of a Makefile—a very simple C file—and an example of what happens when you run the make command.

If you don’t have Visual Studio and you need to compile C++ source code or simply prefer to use the GNU compilers, you can do so by explicitly calling gcc or g++. When you use the GNU compilers, you have to be careful which file extensions you employ. For example, a C++ source code file in Windows usually has a .cpp file extension., but the g++ compiler expects C++ source code files to have a .cc file extension. If your file has the wrong extension, you might encounter apparently random errors, especially on 64-bit hardware platforms. I recommend that you check SUA’s Help files and release notes; these documents contain useful information that can help you avoid some pitfalls.

In the /usr/examples directory, you’ll find sample source code that demonstrates how to use the Oracle Call Interface (APIs for using an Oracle database) and ODBC APIs. The sample code included shows you how to use the Open Network Computing remote procedure call client to make calls to remote systems.

In porting packaged applications to SUA, you might come across configure shell scripts, which you can use to analyze your system and create the makefiles necessary to build applications. Older configure scripts— specifically config.guess and config.sub— don’t work well with the subsystem, and I recommend that you download the latest versions of these scripts from ftp.gnu.org before porting the applications.

When porting or building X Windows applications, make sure that the necessary prerequisites are installed and available. Many X Windows applications use thirdparty add-ons or fonts that you must build or install first. Most mainstream packages should port relatively easily, especially if you use the GNU compilers.

An Alternative Now that I’ve introduced you to the Subsystem for UNIX-based Applications that ships with Server 2008 and Vista, you should have a good handle on some of the subsystem’s major features. This subsystem provides a feasible alternative to UNIX systems for many enterprises, letting them eliminate legacy dedicated UNIX systems by migrating applications to Server 2008 or Vista. The subsystem’s feature-rich shells, file manipulation tools, easy daemon startup, and networking support can actually make it easier to develop and run some scripts and utilities in SUA than in a native Windows environment, while still enabling organizations to benefit from the many features of the Windows platform.