Porting from UNIX to NT

Intergraph is the largest Windows NT development site in the world; Digital Equipment is number 2; Microsoft is number 3! Intergraph is a US-based multinational company that has been providing both hardware and software products for the technical market for more than 20 years. Several years ago, the company undertook the significant task of converting its line of UNIX-based software solutions to the NT environment.

The Decision
Originally, the company provided software solutions based on Digital minicomputers and Intergraph's own intelligent graphics terminals. Later, it developed RISC-based graphics workstations running UNIX. During this RISC/UNIX development phase, Intergraph created and marketed about 800 technical applications, including packages for Computer-Aided Design/Manufacturing/Engineering (CAD/CAM/CAE), as well as vertical-market packages for civil engineering, government, mapping, imaging, and publishing.

As a pioneer in RISC-based graphics workstations, the company created a proprietary UNIX-based GUI and application programming interface (API) environment, called Environ V. This is a typical windowing system. It supports drawing graphics and responds to mouse and keyboard input, and so forth. Environ V also includes extensive support for Intergraph's own bit-mapped and scalable-font technologies. A number of more complex development tool layers exist on top of Environ V, including tools for building user interfaces (I/Forms) and tools for network file management (NFM).

After checking out various open models and doing some development in that direction, Intergraph discovered that Windows NT had entered beta testing. When it appeared that NT had the characteristics and facilities the company was looking for, Intergraph decided to check it out.

The first task was to verify that NT had the necessary resources to support large, complex applications. Historically, Intergraph applications had pushed the limits of the UNIX environment, making extensive use of client/server communications, multitasking, remote file access, SQL database access, and interprocess communications (IPC) and relying on UNIX file systems. In addition, Intergraph required device-driver support for graphics displays with 2D and 3D hardware acceleration, graphics tablets, optical jukebox storage, various LAN and WAN technologies, and more.

The Test Case
After verifying that Windows NT was a capable environment, Intergraph began a project to port NT to its RISC Clipper processor. About this time, Intel released the Pentium processor, which appeared to have enough integer and floating-point performance to support Intergraph's technical applications, especially in systems supporting symmetrical multiprocessing (SMP) arrangements of high-performance Pentium (P54C) processors. This enabled the company to support PC compatibles with medium- to high-end graphics displays running the Intel version of NT. (Intergraph plans to support some non-Intel NT platforms in the future.)

I spoke with a number of Intergraph's key developers about porting software from UNIX to NT. In general, they consider the NT platform to be stable and superior to UNIX in many respects, including the availability of development tools (especially Visual C++). They did, however, experience two problem areas:

• Differences in the semantics of socket behavior
• Lack of a UNIX-like fork mechanism

The following sections cover some of the issues these developers faced in porting from UNIX to NT and present some of their personal observations.

1) POSIX Subsystem
At first the existence of a POSIX subsystem for NT appeared to vastly simplify the conversion task. In practice, however, POSIX applications are restricted to text-style interfaces that run in an NT command-line window and cannot include Win32 system calls. Likewise, Win32-based applications cannot issue most POSIX calls. This makes the POSIX subsystem suitable for only simple applications or for server programs that have little or no interface with the users.

2) Portability Layers
Matching UNIX features to those in the NT environment met with mixed results. Some of the UNIX facilities that Intergraph applications depended upon exist in similar forms (e.g., socket-based IPC) while others could be built on top of existing NT facilities (e.g., I/Forms, which was rewritten as Shamrock). Some resources could be converted into NT equivalents. For example, Intergraph's proprietary fonts were turned into TrueType fonts. However, NT also offered new facilities, such as threads, which were used when appropriate.

Many Intergraph applications were written in script languages of middle-level products, such as Microstation (MDL) or Database Access (DBA). In these cases, once the underlying product was ported, the applications could be ported to NT with remarkably little effort. In particular, Intergraph's third-party vendors got an almost-free ride onto NT because most of their applications are written in these script languages.

Intergraph developers also found that although several of the NT system facilities are supposed to be exact analogs of UNIX facilities (e.g., creating other processes and the socket-style interface), they are different enough to cause problems. In addition, Intergraph's I/Forms product used a look-and-feel that didn't comply with the strict NT GUI standards.

Because of these disparities, several of the Intergraph developers would have preferred doing total rewrites instead of porting existing code. However, the period of time required to create clean implementations that complied 100% with the NT GUI standards would have been considerably longer. Given the number and sizes of the products being ported, this was considered an acceptable compromise. However, new development will be more in compliance with NT standards.

As one developer put it: "Because Intergraph had ported to so many versions of UNIX, we had developed portability layers which took care of the variations. These layers allowed us to port to NT quickly, but they also isolated us from features specific to NT. The biggest issue was in the GUI area where Intergraph had a large investment in forms for screen layout. Since NT seemed [to be] lacking in a highly productive Forms Builder, [we] decided to port the existing UNIX utilities. The effect was a rapid transition but a resulting product which fell short of the Windows look-and-feel. A UNIX vendor moving to NT should make a commitment to strict compliance with the NT GUI style.

"If we had known in advance about some of the pitfalls we would encounter, it would have been obvious that we should rewrite the code almost from scratch. However, since our base platform changed while we were in development--
due to all those NT beta releases--and we had a tight schedule to meet, we didn't have the luxury of learning more about NT before we had to start programming with it. That was probably the source of many of our difficulties."

3) Sockets IPC
Sockets refers to an IPC mechanism originally designed at the University of California at Berkeley, which can be thought of as a variant of named pipes. Basically, one process "publishes" an outgoing socket, and another process--on the same, or another machine--connects to that socket. Once the connection is established, either process can exchange information reliably and in synchronization with the other process.

Windows NT and various implementations of TCP/IP under Windows 3.1 implement an IPC scheme called WinSockets or WinSock that is fully compatible with UNIX's ability to connect to and exchange data via sockets. The WinSock API is also similar to--but not exactly the same as--the UNIX Socket API. In particular, once a UNIX socket connection has been established, a file handle is returned that you can use with the same I/O procedures that you would use to read and write files. In WinSock, however, you can use only the specific procedures provided in its API to read and write data. Furthermore, socket inheritance by a created process in NT is slightly different from socket inheritance by a forked process in UNIX. These two issues required a fair amount of recoding of IPC routines.

According to one of the development-team members: "The hardest part of moving from UNIX to NT was finding the 'hidden differences' between UNIX and NT. In a lot of cases, we had to rewrite some code because, while NT looked the same on the surface, the underlying mechanisms were completely different from UNIX's. The WinSock API was the source of a lot of these misunderstandings. The library calls were the same, but, for instance, sockets are not inherited over a Create Process, as they are for an exec(), and sockets cannot be used with function calls that use file descriptors (i.e., read, write, close)."

   Previous  [1]  2  Next