| 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: Solution: What You Need: Solution Steps: 1. Install SUA. 2. Download and install additional utilities and the SDK from the Microsoft website. 3. Install an X server (optional). 4. Identify candidate shell scripts and applications to port to Windows. 5. Compile C and C++ applications to run under SUA. DIFFICULTY: 3 out of 5 |
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.