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
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
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
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
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 email@example.com.