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:
| 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.
