Perils of Porting Applications
from Unix to NT


By David S. Linthicum



As Windows NT takes a larger share of the client/server market, the migration of some Unix applications to NT will be inevitable. But porting them isn't a cut-and-dried process.

When Windows NT was announced several years ago, Bill Gates, Microsoft chairman, called it a better Unix than Unix. What was then a joke is now a concern in the Unix community. But should it be? NT fills a need that Unix could not completely fill, but the two operating systems can complement each other by taking on specific roles in the enterprise.

NT has found its way into the corporate structure through the desktop, Microsoft's traditional area of strength, and the local-area network, where Novell NetWare was the leader. "The success of NT is a combination of solid marketing from Microsoft along with the fact that the product fills a legitimate technical need not well-satisfied by Windows or Novell," says Steve Ruegnitz, first vice president of financial services firm Lehman Brothers, Inc., in Jersey City, NJ. His firm is porting to NT in-house Unix applications that lend it proprietary competitive advantage.

On the other hand, Unix remains the preferred operating system for high-end, heavy-load applications such as hosting database servers and transaction processing (TP) monitors. "Unix is still a good fit for database and calculation engines--areas that need multiprocessing power that scales up a long way," says Ruegnitz.

Although Windows 95 and Windows NT connect easily to Unix-based servers, many organizations are inclined to employ NT on the server as well. The Windows graphical user interface (GUI) is familiar to most users, and applications based on the Win32 application programming interfaces (APIs) that run on the workstations will run on the server as well. Application support for Windows NT is many times that of Unix. "It is only natural that the best server for NT workstations will be an NT server," says Bentley Radcliff, senior consultant for Enabling Technologies, an Atlanta-based consulting firm.

However, Windows NT still can't support the loads that Unix handles easily. While NT works for the majority of workgroup-class applications, Unix has the power to bring distributed computing to enterprise-class applications. Moreover, the existing Unix infrastructure is not easily replaced by NT for both cultural and technical reasons. "For organizations already well into Unix, it's like moving sideways for the moment," says Ruegnitz. "You need to learn new tools, work around facilities that are not immediately available and build infrastructure to support NT. Most organizations won't want to support both environments."

Does moving to NT create more problems than it solves? Are we turning back the clock to deal with issues already resolved in the past? These are questions that IS managers must deal with as NT makes greater inroads into their organizations.

The Pains of Porting

Today, cross-platform development has gone from being an option to an integral part of most application development strategies. In the past, IS departments often hoped that everyone would migrate to a single platform, but the fact of life is that organizations employ a mix of operating systems and processors. In addition to support for multiple platforms, users want applications that work identically across all platforms and thus reduce the need for extra training and support. Of course, a price tag comes with this wish list.

Porting applications to Windows NT is a tricky business. Although most Unix flavors, as well as NT, are Posix-compliant, this compliance covers only the least common denominator in operating system services (see "The Promise of Posix"). A native API-to-API comparison demonstrates that NT and Unix are very different beasts. Applications that exploit native GUI APIs won't have much in common with the other operating system.

Organizations port Unix applications for various reasons. For instance, many Unix applications that reside on data servers will make their way to Windows NT because NT has a large portion of the low-end server market. Developers must port to expand their installed base as well as demonstrate that their application is as flexible as others that are making the move to NT. Usually these applications are not graphical and therefore don't require as much rewriting as applications that exploit Unix GUIs, primarily Motif, in order to move to Win32.

Some GUI-based Unix applications are being ported, for the same reasons. However, changing the native GUI API is a laborious process, and if they don't employ high-end porting tools, developers must learn to maintain dual code sets. Configuration management can become a problem in this scenario.

Applications being moved from Unix to NT are usually business-critical and are crossing platforms to reach a larger audience or to support an audience that's moving to Windows NT. Types of applications range from vertical market software, such as tire sales or dental practice management systems, to comprehensive products, such as general ledger accounting software and network management subsystems. Moreover, distributed, object-based applications also are being deployed on NT as well as Unix, as orders increase for NT versions of object request brokers.

Some applications, not yet built, are headed down the portability route as well. These will be a bit easier to manage, since designers and developers can build the application from the ground up to support portability from Unix to NT. But selecting the wrong strategy to make an application portable can hurt the application's chances for survival in the long run. Portability pitfalls abound in the application world.

Nuts and Bolts

When you consider moving an application to Windows NT, concentrate on new tools and resources not available on NT, as well as changes to the source code. "NT is missing basic features every Unix programmer expects," says Radcliff of Enabling Technologies. "The best advice is, evaluate before making the plunge."

Most Unix developers are accustomed to a consistent set of powerful Unix utilities such as awk, sed, lex and grep. You won't find these on Windows NT. However, most of these tools are available from commercial vendors such as Hamilton Laboratories of Sudbury, MA, and MKS of Waterloo, Ontario. They provide native Windows NT Unix utilities that make transplanted Unix developers feel more at home.

Like Unix, Windows NT is a preemptive multitasking, multiuser, multithreaded operating system. NT can run not only Win32-based applications but Posix and OS/2 applications (character-based only). These subsystems provide both the system calls and the proper state for the application.

Unix and NT have a lot in common, including a multiuser programming model, a process/thread programming model with 32 priority levels, a built-in remote procedure call (RPC), sockets, file systems that use long file names and a flat, 32-bit memory model. NT also provides process synchronization facilities and a nonblocking asynchronous I/O model.

All this said, however, many concepts change when you move an application from Unix to Windows NT, including the use of Windows message loops, application-to-application communication using Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE), OLE Automation and the Distributed Component Object Model (DCOM, formerly called Network OLE). Those who port to Windows NT also need to understand Windows resources and callbacks, and you'll have to change compilers and integrated development environments (IDEs) as well.

For simple applications, such as Hello World, developers will find that standard C code compiles well and runs under Windows NT as a character-based application. End users, however, insist on GUI-based applications with native look-and-feel. To utilize the full set of features of NT, developers have to rewrite applications to use native Win32 calls.

At the interface level, Windows NT provides the Graphical Device Interface (GDI), a portion of the Win32 API. GDI includes objects and windows management. At any level, it is very different from native Unix APIs such as Xlib, Xt and Motif. However, Unix developers who port their brains as well as their code to NT will be happy to note that GDI provides a "superset" of X Window System features. Of course, these features need a completely different set of system calls.

To begin the porting process, the best tactic is to get something running under Windows NT. Usually this means porting an application from Unix to NT a subsystem at a time. Once the application runs, developers can add the Win32 enhancements, then port subsystem by subsystem.

The differences between Unix and Windows NT applications will lead most Unix development organizations to move slowly when considering porting to NT. For instance, there are public domain utilities such as ntxlib.zip (available via anonymous FTP from ftp.uu.net) that resolve calls to the Win32 API. All the programmatic differences between Unix and Windows NT exceed the scope of this article, but considering how a few things change can help you to understand how the port will affect your application.

File I/O on Unix systems, for example, consists of fopen(), fread(), fwrite(), fprint() and fclose(). These are just as easy to use for Windows NT character-based applications, but Windows NT requires that developers use CreateFile(), ReadFile() and WriteFile() to get at the power of 64-bit file access and asynchronous I/O. Moreover, the Windows NT file system may not use I-node representations, so Unix applications that rely on I-nodes won't work well with Windows NT and will have to undergo function call surgery to become NT-ready.

Tool-Oriented Portability

Straight Unix-to-NT porting of code is not the only option for developers. For those who want to create or rewrite applications for both Unix and Windows NT, there are several third-party portability tools and libraries. These products include Zapp from Inmark Development Corp. of Mountain View, CA; C++/Views from Liant Software of Framingham, MA; XVT from XVT Software of Boulder, CO; and Zinc from Zinc Software of Pleasant Grove, UT. You'll also have the option to select among numerous fourth-generation language (4GL) application development tools that are portable between the two operating environments.

Cross-platform libraries are C++ frameworks that can leverage the object-oriented features of C++ and place all the native platform-related code (such as Win32, Xlib or Motif) in a class library. The developer accesses the native operating system and GUI services using proprietary API calls. When moving an application from one operating system to the next, developers simply swap in the appropriate library and recompile.

Although each cross-platform library has its own approach to application development and portability, all allow the developer to layer the native APIs behind the proprietary APIs, thus making the application portable. However, what they do with that API varies from tool to tool, and portability often comes at the expense of native look-and-feel and sometimes performance.

Some cross-platform libraries support only a subset of the native features that exist on both the Unix and Windows NT platforms. This means that you can't take complete advantage of the power of some NT features such as DDE and OLE. Cross-platform library vendors are doing a better job of providing native features and functions, but developers who place these features in their applications do so at the expense of portability.

Other cross-platform libraries don't worry about what native features to support. Instead they emulate the GUI controls across Unix and Windows NT by writing directly to the graphical subsystems of each platform. Not using the native API can cause some strange results. For example, using cross-platform libraries that support emulation, portable applications written for Windows NT 3.5 will look out of place when running on Windows NT 4.0, which supports the Windows 95 look-and-feel. In other words, as the GUIs change, the application won't automatically adjust, because it does not really use the native API. Other cross-platform tools provide the best of both worlds. If the native control is not available to provide the portable application with a consistent look-and-feel, the libraries emulate it.

The trade-off in use of cross-platform tools is portability at the expense of openness and performance. Since you create your application using proprietary APIs, you can't do much with the application beyond the scope of the tool. The extra layer that the application must go through can cause performance problems, as does using non-native mechanisms to write to the user interface. However, these tools can also deliver portable applications quicker than developers who try to make their applications native to both platforms, using dual code sets. If that's your application porting strategy, count on spending twice the dollars for development hours, as well as tools. For now, cross-platform tools and frameworks provide a quick fix.

Other Porting Tricks

There is another option to cross-platform porting, and that's to use operating system extensions and emulation software that can run both Unix and Windows NT binaries. If you think this sounds too good to be true, you're right. In most cases, being able to run non-native executables inside Windows NT, or Unix for that matter, extracts a trade-off in performance and compatibility.

There are, however, a few products promising Unix and NT applications that will easily coexist. For example, OpenNT System from Softway Systems of San Francisco allows users to run both native Unix and native Win32 applications by layering a Unix subsystem on top of the Windows NT kernel. Softway takes the direct route, licensing the Windows NT source code to build the OpenNT commands and utilities. According to Dan Kusnetzky, director of Unix systems research at International Data Corp. in Framingham, MA, products of this sort present the best way to have Unix and Windows NT applications work together on the same system. Certainly, this is a better solution than emulation or running X Window System emulators on NT-based workstations.

Coming from the other direction, MainSoft Corp. of Sunnyvale, CA, for example, has announced MainWin Extended Development Environment (XDE), a development environment that allows developers to port Win32-based applications to Unix. MainWin XDE supports Windows NT controls and is available on HP-UX and SCO Open Server. A few other products, such as Wind/U from Bristol Technology of Ridgefield, CT, enable users to run NT applications under Unix.

NT and the Enterprise

Is NT in your application's future? That's a question you'll have to ask if you begin to see legions of Windows NT-based servers and workstations in your playground, and users asking for application support across environments. There should be a clear business requirement before you endure the cost and trouble to rewrite a Unix application for NT.

When you move an application to Windows NT, you have few available options. First, you can take the optimistic approach: run an X emulator on NT and hope that nobody notices. Although this is up and running in a week, emulators don't provide native look-and-feel or the performance that some users demand.

Second, you can use the "power porting" approach, in which you force a native Unix application to run on Windows NT by hacking through the code, changing one API after the other. This approach requires the most time and trouble, but it allows your application to make the most of its new environment. Rigorous testing should follow power porting.

Third, you can use the tool-driven approach, where you write or rewrite your Unix application using a proprietary cross-platform tool. While this is quicker than power porting, you will trade some native features for portability.

Finally, you can use the Posix porting approach and rely on the Posix subsystem to drive your applications. Although this is also a quick fix, Posix cannot make the most of NT's features and functions. Users will soon steer clear of the application in favor of native products. Whatever approach you select, there is no easy way to move a native Unix application to Windows NT. Still, if you do your homework up front, your application will have a better chance of new life on a new platform.

David S. Linthicum is an author and speaker and a technical manager with AT&T Solutions in Vienna, VA. He can be reached at 70742.3165@compuserve.com.