Programming Paths from UNIX to NT

X Windows API support: This style of migration implements the X Windows API in NT, letting XWindows-based applications recompile on NT and run as X Windows applications. Of course, theresulting 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-basedapplications as previously described, but also lets programs call both the X Windows APIs and theWin32 APIs. Using this style of migration, you can move a UNIX product to NT, run it as an X Windowapplication to ensure it is viable, and then slowly migrate it to a native Win32 application. Manycommercial products reach the NT market via this route.

The downsides of implementing X Windows APIs in the NT Server environment are that X Windowsconsumes a fair amount of overhead, and X Windows programs don't run at optimal speed. The overheadis high because the underlying third-party product must emulate the entire set of X Windows APIs andsupply an X Windows terminal emulator to provide a user interface to the application. For thisreason, 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. Thedirect port of a UNIX X Windows application to an NT X Windows application is certainly a faster andless error-prone process than performing a full port to the Win32 APIs. As a result, manycorporations 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. Thisapproach delivers the best performance and the best integration into the NT environment. In the realworld, X Windows APIs provide a quick-and-dirty way to port existing applications or to test theviability 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 orfunction. In most cases, you can address your problem using standard UNIX commands and utilitiesdriven by the scripting capabilities of the UNIX command environment. After all, why should youwrite a program to search for a string in a file when you can use grep? Why write a datamodification 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 clearlyheading in this direction, at the moment, NT's scripting capabilities and tools fall far short ofwhat's currently available in the UNIX environment. Even if you add the POSIX subsystem from eitherthe Microsoft Windows NT Server Resource Kit or the Microsoft Windows NT WorkstationResource Kit, you still don't get enough tools to move most UNIX scripts over. For example, youget Perl, but not awk, and you get grep, but not sed. In short, the POSIX subsystem in the resourcekits falls short of delivering a robust UNIX-like environment.

The good news is that the third-party community delivered toolkits and POSIX subsystems soUNIX-like that you will swear you're working with a real UNIX system. Using these toolkits, you canport a wide variety of scripts from an existing UNIX environment to the NT environment. Until thescripting capabilities of NT improve and mature, employing third-party toolkits is often the onlyviable 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 ofthird-party software. This area is an enigma for NT--Microsoft clearly wants to encourage themigration of programs, scripts, and entire servers from UNIX to NT, yet Microsoft provides very fewtools to assist administrators who are willing to pick up the gauntlet. Fortunately, the third-partyvendors have quickly stepped in to provide tools to assist in the migration. Microsoft usually doesnot rely on the kindness of others, but this case is clearly one where kindness is the key tosuccess.