March 11, 1996
<page>570pg1A</page>
First of two parts.
Now that microsoft windows NT is showing up regularly on departmental servers, you may have decided that porting your Unix applications to Windows NT could be a good move. But since Windows NT and Unix support very different sets of application programming interfaces, that task can seem daunting. Will it really be a simple porting job or will it require a total rewrite?
The extent of the task in moving an application from Unix to NT depends on many factors: the functionality of the application, whether it has a character or graphical user interface, what operating system features it uses, and the quality of its engineering. If you have properly designed your applications to be modular, porting should be easier. The biggest problem will usually be the user interface.
The first task is to become familiar with the Windows NT operating system and the tools that are available to developers. To avoid serious programming errors, you need to understand the subtle differences in the way Unix and NT operating system features work, particularly the process model, signal semantics, serial I/O, networking and communications, memory management, and file mechanisms.
The good news is that Windows NT provides many of the same services and facilities typically found in Unix environments. Microsoft and third parties also offer add-on tools and services that ease the porting of even complex applications.
Many well-known and useful Unix applications have been ported successfully to Windows NT, which may be a source of encouragement for your own efforts. These applications include TCP networking protocol stacks, PC-NFS file sharing software, various shells, filters, and utilities, including the GNU EMACS editor.
Applications that adhere to ANSI C and lack significant hardware or operating system dependencies are usually straightforward to port. But if your application requires performance that can be achieved only through direct access to lower levels of hardware, you will need to write a client-side driver. Unfortunately, this is a complex programming task: We recommend you do not attempt it unless you have considerable experience writing device drivers and an NT source license. The primary reference on this topic is the Windows NT DDK (Device Driver Kit).
Win32 And Unix
Windows NT is
a microkernel-based operating system that supports protected
address spaces, pre-emptive multitasking, and multiple APIs, as
shown in the chart above. The NT Executive is analogous to
a Unix kernel in that it provides interrupt and exception
handling, virtual memory, and interprocess communications
support, as well as file system and network services. The Win16,
Posix, and Win32 interfaces are supported by separate protected
subsystems operating in user mode (as opposed to kernel or
executive mode).
Win32 is the main subsystem of Windows NT, interacting directly with the operating system. This subsystem is dependent on the hardware architecture and provides a rich set of graphics, operating system services, network, and security APIs. The Win32 API provides a flat 4-Gbyte address space with no segments. The lower half of this address space is reserved for user processes and the upper half for the operating system. The Win32 protected subsystem owns the display and the console input devices-the keyboard and mouse.
In contrast, a typical Unix system running in a high-end PC or low- to midrange workstation will consist of a single monolithic kernel, perhaps augmented with dynamically loadable drivers or shared libraries (see chart, p. 12A). The Unix system call interface is implemented directly by the operating system kernel. Microkernel-based Unix-like operating systems, such as Mach and others, lie somewhere between a conventional BSD Unix implementation and Windows NT's executive/protected subsystem model.
The Unix
run-time environment consists of library calls, operating-system
service calls, and remote procedure calls (RPCs). Library calls
typically are linked into an application's user space either
statically or via a dynamically loaded or shared library.
Operating-system service calls are entry points into the Unix
kernel and provide relatively low-level system services such as
file I/O, TCP/IP sockets I/O, and RPCs. Unix variants
provide a variety of other services to applications, such as
shared memory, threads, and hardware-specific features.
The Microsoft Windows NT run-time environment provides analogous, and in many cases identical, services as are available from Unix. The Posix subsystem is the most Unix-like. Most Unix source code will recompile with little effort or modification under the Posix subsystem. Unfortunately, this is a character-based subsystem and there are no provisions for graphics. One option is to run an application that is RPC-enabled under the Posix subsystem while its graphical display is piped via RPCs to a user interface application running under Win32.
Development Tools
The scope and variety of development tools available on Windows NT is strong and growing compared to those on Unix. While some advanced integrated development tools such as CenterLine Software's CodeCenter and Hewlett-Packard's Softbench are available on Unix, they are not available on all platforms, and-while high in quality-they tend to be more expensive than NT tools.
The NT learning curve (or in some cases, unlearning curve) unfortunately appears to be quite steep, for reasons that are not perfectly clear. But the transition is not insurmountable with appropriate support and training. Part of the problem-due to difficulties in mapping Unix development processes, methodology, and modes of thought to a Windows development environment-can be solved simply by porting the development environment. For example, various Unix shells for Windows NT, including the popular C shell and Korn shell from Mortice Kern Systems in Waterloo, Ontario, are useful tools.
Nutcracker from DataFocus in Fairfax, Va., is a set of libraries and utilities supporting important portions of the typical Unix development environment, particularly the X Window X11R5 and OSF Motif libraries (See http://www.datafocus.com/port/pg_homep.htm).
Standard Unix development tools (e.g., awk, sed, lex, grep, etc.) have been ported by a variety of vendors, including Congruent Software and Mortice Kern Systems. Hippo Software also provides a library called Hippix that supports most of the Posix 1003.1 API as well as a variety of utilities familiar to Unix developers, including the RCS version control system.
The European Microsoft Windows NT Academic Centre (EMWAC) at the University of Edinburgh in Scotland has written various Internet tools for Windows NT and distributes them as freeware. These are an HTTP Web server, Gopher server, WAIS server, WAIS tool kit based on freeWAIS 0.202, finger server, and freeware Internet mail services (SMTP, POP3). EMWAC reports that porting relatively involved shell scripts using the Hippix tool kit is surprisingly easy, with only a few gotchas as described in the second part of this series. A comprehensive list of Internet tools and other resources for Windows NT may be found at http://www.microsoft.com/BackOffice/Internet
Cygnus Support in Mountain View, Calif., which provides commercial support for the GNU software, is hosting the gnu-win32 project to port GNU programs to the Win32 API. The group already has ported the fundamental GNU development tools (gcc C compiler, gdb debugger, gas Intel assembler, etc.), and it is working on a version of the standard C library that will support utility programs such as the bash shell and GNU make. You can find out more about this project by visiting the World Wide Web page at http://www.cygnus. com/misc/gnu-win32
In February, Softway Inc. in San Francisco announced an agreement with Microsoft to develop a Unix for Windows NT, called OpenNT. It isn't as far along as some of the other efforts, but promises a strong future. Its goal is to provide complete IEEE Posix.1, Posix.2, and X/Open standards conformance in 18 months (See http://www.softway.com).
User Interface API
On Unix, X Window was designed to use a client-server model and was developed to solve a distributed computing problem rather than a user interface problem. It achieved wide acceptance, in part because it was a well-defined, open standard, but also because it could provide network transparency for the important areas of graphics display and user interaction.
Win32 applications do not necessarily follow a client-server model. They typically are intended to be executed on the user's machine. Depending on your application, this may or may not be an important factor. Some X and Motif-based applications may depend heavily on the network transparency provided by the X Window System.
An application written for the X Window System may depend on structured interprocess communications implemented using the Inter-Client Communications Convention Mechanism (ICCCM) interface. Many of these operations also are available through comparable, but different, Windows features, such as Microsoft OLE object technology. For example, drag-and-drop is implemented differently in X Window and Windows. You should decide if it is necessary to implement each of these features in your Windows NT application. If so, it will not be a port but a rewrite to get those features to the NT platform.
Straightforward Ports
If you structure your application so that the user interface is modularized or maintained as a discrete component, the porting process will be much more straightforward. Otherwise, you may spend a considerable amount of time separating the user interface logic from the core processing of the application and, in effect, rewriting the application.
Graphical user interfaces consist of windows, menus, button bars, and other controls. These concepts and the desktop metaphor are implemented by layers of software shown at right.
A port from a typical OSF/ Motif client application interface is conceptually simple, but requires a mastery of at least one or preferably both sets of user interface components: the Motif widget set or the Microsoft Foundation Classes. The Motif widget set is augmented by the X Intrinsics functions that provide the application framework; the MFC implements this functionality in the CWinApp object. Other similar mappings between X Window and Windows exist. For example, the mapping between the Motif File Selection Dialog widget and the MFC CFileDialog class is relatively straightforward and mechanical.
Some user interface mapping software is available to automate the conversion from X Window to Windows-for example, the Xlib emulation package for NT (available at ntxlib.zip on ftp.microsoft.com or the CompuServe MSWIN32 Forum) and the WinX library from Pearl Software in Emeryville, Calif.
X Window is called a policy-neutral windowing system because it requires a window manager to implement the presentation of the user interface on the screen. Policy neutrality may be an unfamiliar concept to Windows users and developers, where user interface policy is less equivocal. Policy and style dictate what menus and buttons look like, how dialogs are presented, and so on.
The concepts most commonly referred to as "look and feel" are implemented in X Window by a window manager and user interface toolkit that are separate from the display driver. The most common window manager and tool-kit in use today is OSF/Motif, which enforces a policy and user interface style. Another more powerful but less widely used suite is the Common Desktop Environment (CDE), developed by several major Unix vendors.
Some facilities provided by Motif, and more recently the CDE, have comparable components in Win32 and OLE. If you examine the OSF/Motif Style Guide and the Microsoft Windows Style Guide, you'll see that their philosophies and presentations are similar, though their implementations are different. So you'll find that the implementations are different. So you 'll find that the implementation level is where most of your porting effort is centered.
Two weeks from now, we 'll discusss low-level graphics APIs, debugging, tracing and performance profiling, inteprocess communications, security, and file system gotchas, among other topics. We 'll also mention some more tools and techniques that facilitate the porting effort between these two systems.