INTERIX: UNIX Application Portability to Windows NT via an Alternative Environment Subsystem Stephen R. Walli Softway Systems, Inc. 185 Berry Street, Suite 5514, San Francisco, CA 94107 [email protected] 0. Introduction today. It does this in a price competitive manner with respect to the hardware platforms on which This paper was originally written for and it runs. The problem becomes protecting the presented at the USENIX Windows NT huge investment in applications development over Workshop, Seattle, Washington, August 1997. the past decade or more in UNIX applications. The original paper was presented under the How does one leverage and protect the existing OPENNT name. It has been updated to reflect application base while moving to Windows NT? the current architecture and experience with INTERIX. 2. Alternatives 1. The Problem There are several ways to move existing applications to Windows NT. These range from Walli’s First Law of Applications Portability: the expense of a complete re-write of the Every useful application outlives the platform on application to some form of application port. We which it was developed and deployed. will briefly look at the pros and cons of the following: Application source code portability is one of the • cornerstones of most open systems definitions. a complete re-write of the application to the The intention is that if an application is written to Win32 environment subsystem • a particular model of source-code portability, it the UNIX emulation library approach to can port relatively easily to any platform that porting the application supports the portability model. This model is • the common library strategy for porting often based on source code portability standards applications such as the ISO/IEEE family of POSIX • the Microsoft POSIX subsystem standards [1,2] and ISO/ANSI C[3], and • the INTERIX subsystem specifications that include these standards such as the Open Group's Single UNIX Specification[4]. 2.1A Brief Introduction to the Windows NT Architecture The strength of this model is that the investment in the application's development is not lost in re- Before discussing the alternatives, one must deployment to new architectures. Re-writing the understand a little of the overall Windows NT application to new platforms every five years or architecture[5]. The Windows NT operating so is not an option. There are already too many system was structured such that there is a small new applications to be written in the queue kernel (not unlike the design of Mach) that is without adding the burden of costly re-writes written such that much of the OS is architecture- every few years to address newer faster hardware neutral with the architecture-specific functionality platforms. being provided through the Hardware Abstraction Layer (HAL). Currently businesses are faced with the decision of moving to Microsoft’s Windows NT operating Above the kernel sits subsystems that provide system. Windows NT provides a robust functionality to applications. These subsystems environment to solve many business application are loosely grouped into functional subsystems problems through a host of software development (e.g. the Security subsystem, the I/O subsystem) tools, as well as a platform to run the many that provide basic functionality, and environment Win32-based applications that businesses use subsystems (e.g. Win32 subsystem, the Microsoft POSIX subsystem, the OS/2 subsystem) that Page 1 present a programmatic and user interface to address the lack of interfaces that directly map developers and users. The primary environment the traditional UNIX application interface to subsystem supported by Microsoft, and regarded which they were written. Some of the re-write as the prescribed way to develop applications on may be very straightforward if the use of system Windows NT is the Win32 subsystem. The services was restricted to simple file operations Win32 subsystem is also responsible for (open( ), close( ), read( ), write( )). If the managing the desktop. application depends upon complex signal mechanisms, parent-child relationships (fork( ), Applications programs essentially run as clients of exec( )), or absolute file semantics (hard links, or their respective environment subsystem using a the ability to distinguish files by case alone), then variety of techniques to communicate with the the rewrite strategy becomes more expensive as subsystem when requesting operating system parts of the application must now be re-designed, services. A fast local procedure call (LPC) and then re-written. shared memory are two of the more common methods of communication. When an When one considers a limited number of application is started, the executable image is application programs, this may be an option. If inspected to determine which subsystem will however, one is reviewing a large number of provide the application’s services. applications, the cost of rewriting can become excessive. 2.2Caveat Lector Prior to discussing the alternatives and the 2.4Win32-based UNIX Emulation INTERIX subsystem, it is important to note what Libraries this paper is not about. Win32 and traditional There are a number of Win32-based libraries UNIX applications use different interfaces for emulating the behavior of UNIX system calls and accomplishing the same functions (opening files, libraries. The most common include: creating new processes, etc.). These two • UWIN from AT&T Laboratories operating environments also use different • NuTCracker from Datafocus philosophies with respect to how applications are • Cygwin32 from Cygnus structured when looking at such items as the • Portage from Consensys (Consensys ceased handling of standard I/O streams, the use of file to distribute the product in late 1997.) descriptors, consistent return codes, and process creation relationships and control. Please see Korn [6] for a comparison of these three packages, and for a complete discussion of This paper does not get into religious or the UWIN package. philosophical debate about which OS interface or application architecture may or may not be A set of applications may compile cleanly in this “better” than the other. Neither does it descend environment, but may not run correctly because into “marketing” messages about the rationale for system calls don’t demonstrate the expected providing two different programming and run- semantics. For example, the semantics for fork() time environments on Windows NT. This paper and exec( ) cannot be exactly duplicated with is about solving a very real application respect to the process attributes inherited by the programming problem using a unique strategy child process. NuTCracker and Portage leave a based on the fundamental design of the Windows process “ghost” around, creating a new process, NT OS. when an exec() call is issued. To obviate the need for exact semantics the UWIN project 2.3Application Rewrite to Win32 created a spawn( ) call that replaces the previous There is a family of simple application programs two interfaces with a single interface. that are written to ANSI C and its library specifications and will simply re-compile on the File system semantics are another challenge. The Windows NT operating system in the Win32 Windows NT file system (NTFS) provides subsystem space. almost complete UNIX file system semantics. Group ownership of files, hard links, and filename Most applications present a greater challenge as case sensitivity is all available from NTFS, but are they use some form of system resources. Such not available through the Win32 subsystem. applications require some amount of rewrite to Page 2 All these emulation systems allow for (indeed fulfill the letter of the standard without being may require) the use of Win32 interfaces in the particularly useful to an application. application source code. This is not a feature. In a less experienced development operation it can That said, the Microsoft POSIX subsystem destroy the application’s portability, locking it to passed the breadth of the NIST FIPS 151-2 the hybrid environment. At best it increases the certification process. In fact, the original maintenance cost of the source with an additional OPENNT Commands & Utilities [8] shipped in level of conditional compilation, and the work March 1996 were built on top of a subsystem that may not easily integrate into the existing style of was for the most part the original Microsoft UNIX code. POSIX subsystem. That achievement demonstrated that the environment subsystem 2.5 Common Porting Libraries architecture of Windows NT was flexible and powerful. Depending upon the application space there may be a set of libraries that have already been created that are used as the portability layer. 2.7The INTERIX Subsystem The only requirement here is that the library If the Microsoft POSIX subsystem could be built exists on Windows NT. The library layer then then why not a complete “UNIX” environment becomes the porting exercise. This is a special subsystem? There is nothing in the Open Group case of the normal situation where the application Single UNIX Specification and its attendant source code needs to be ported or re-written. It UNIX 95 [9] brand that can not be implemented is an application structuring issue. on top of the Windows NT kernel. As you will see, this also applies to the graphic environment 2.6The Microsoft POSIX Subsystem of the MIT X11 project. Windows NT supports multiple environment The goals when developing INTERIX were: subsystems by design. One of the original • subsystems was the POSIX subsystem. The To provide a complete porting and runtime Microsoft POSIX subsystem is an exact environment to migrate applications source implementation of the ISO/IEEE POSIX.1 code developed on traditional UNIX systems standard, which includes the ANSI C library by directly to Windows NT. This meant going reference. beyond the standards and specifications (e.g. providing X11R5) as well as providing more Microsoft down-played the POSIX subsystem, than one way to access functionality (e.g. essentially pointing out that it was delivered for determining the next available master conformance to NIST FIPS Pub 151-2 [7] pseudo-terminal).