Windows NT is often the target platform for UNIX applications that are looking for a new home or
a larger market share. But how do these programs and the scripts that support them migrate to the NT
environment? This month I'll answer that question by looking at the issues involved in porting UNIX
applications to the NT environment.
A Question of Character
Porting single-task, foreground, character-mode applications from UNIX to NT is not a terribly
difficult proposition--most mainstream C and C++ compilers can handle this level of migration.
However, an application rarely moves over as is. Invariably, the application requires subtle changes
to address UNIX and NT differences in file handling, I/O piping, console handling, and the TCP/IP
socket implementation.
When you move beyond single-task, foreground applications, the conversion to NT becomes
dramatically more difficult. For example, if you are working with a UNIX background program (daemon
or otherwise), you will quickly find that you need to either rewrite the program to run as a native
NT service or launch it using an NT-based scheduling program. You must take one of these approaches
because NT does not provide a way for you to force a program to run in the background of a logon
session (as in the case of the UNIX & parameter) and NT does not provide the equivalent of the
UNIX nohup command to let a program run in the background independent of a logon session.
UNIX programs that launch child processes also pose a problem when you port them to the NT
environment. Although NT supports a similar process-spawning mechanism (the Win32 CreateProcess
service), the NT spawning mechanism is not equivalent. Similarly, taking advantage of NT's
multithreading capabilities requires substantial changes in the code--there are no direct UNIX
equivalents to the NT threading services.
The bottom line is that you are better off converting background programs to run as native NT
services. You achieve better integration with the NT environment, and you can take advantage of all
the NT system services, including support for multiple threads. Similarly, convert any programs that
launch child processes into native Win32 applications so that you can use NT process management and
multithreading services.
A Graphical Dilemma
Porting graphical X Windows-based applications from UNIX to NT is the most difficult proposition
of all. Not only are the appearance and controls that X Windows programs use different, but the
underlying APIs are very different from the native Win32 APIs. Microsoft provides no aids for this
porting problem, but for help you can turn to third-party vendors (see the sidebar, "What's Out
There?," page 50 for a complete listing). UNIX-to-NT migration products employ one of the
following approaches to port X Windows applications to NT:
X Windows API support: This style of migration implements the X Windows API in NT, letting X
Windows-based applications recompile on NT and run as X Windows applications. Of course, the
resulting applications have the look and feel of an X Window program instead of a Win32 program.
Concurrent X Windows and Win32 API support: This style of migration supports X Windows-based
applications as previously described, but also lets programs call both the X Windows APIs and the
Win32 APIs. Using this style of migration, you can move a UNIX product to NT, run it as an X Window
application to ensure it is viable, and then slowly migrate it to a native Win32 application. Many
commercial products reach the NT market via this route.
| You can take many different paths for porting UNIX programs to
NT |
The downsides of implementing X Windows APIs in the NT Server environment are that X Windows
consumes a fair amount of overhead, and X Windows programs don't run at optimal speed. The overhead
is high because the underlying third-party product must emulate the entire set of X Windows APIs and
supply an X Windows terminal emulator to provide a user interface to the application. For this
reason, vendors release very few commercial products to the NT market as X Windows applications.
The upside of implementing X Windows APIs is that X Windows accommodates quick migration. The
direct port of a UNIX X Windows application to an NT X Windows application is certainly a faster and
less error-prone process than performing a full port to the Win32 APIs. As a result, many
corporations take this approach for their proprietary or internal X Windows applications.
In an ideal world, all X Windows programs would be rewritten to support Win32 APIs. This
approach delivers the best performance and the best integration into the NT environment. In the real
world, X Windows APIs provide a quick-and-dirty way to port existing applications or to test the
viability of an X Windows program in the NT environment.
Scripts Galore
If you spend any significant time doing network and systems administration in UNIX environments,
you know that you rarely need to sit down and write a C or C++ program to accomplish a task or
function. In most cases, you can address your problem using standard UNIX commands and utilities
driven by the scripting capabilities of the UNIX command environment. After all, why should you
write a program to search for a string in a file when you can use grep? Why write a data
modification tool when you can use sed? And for more complex operations, you can fall back on awk,
Perl, and other scripting languages.
Wouldn't it be wonderful if NT had similar scripting capabilities? Although NT is clearly
heading in this direction, at the moment, NT's scripting capabilities and tools fall far short of
what's currently available in the UNIX environment. Even if you add the POSIX subsystem from either
the Microsoft Windows NT Server Resource Kit or the Microsoft Windows NT Workstation
Resource Kit, you still don't get enough tools to move most UNIX scripts over. For example, you
get Perl, but not awk, and you get grep, but not sed. In short, the POSIX subsystem in the resource
kits falls short of delivering a robust UNIX-like environment.
The good news is that the third-party community delivered toolkits and POSIX subsystems so
UNIX-like that you will swear you're working with a real UNIX system. Using these toolkits, you can
port a wide variety of scripts from an existing UNIX environment to the NT environment. Until the
scripting capabilities of NT improve and mature, employing third-party toolkits is often the only
viable way of moving complex scripts from UNIX to NT.
A Little Help
As you can see, you cannot easily move programs and scripts from UNIX to NT without the aid of
third-party software. This area is an enigma for NT--Microsoft clearly wants to encourage the
migration of programs, scripts, and entire servers from UNIX to NT, yet Microsoft provides very few
tools to assist administrators who are willing to pick up the gauntlet. Fortunately, the third-party
vendors have quickly stepped in to provide tools to assist in the migration. Microsoft usually does
not rely on the kindness of others, but this case is clearly one where kindness is the key to
success.
End of Article
