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). • requirements for government agency To provide true semantics for the system procurement. The development environment was interfaces such that application source code not very supportive, and it was poorly would not need to change to account for documented. As an exact implementation of “not quite UNIX” semantics. POSIX.1, the Microsoft POSIX subsystem was • To ensure any changes made to the somewhat limited in functionality. application source code should make it more portable (i.e. follow the standards) rather The interesting thing to note about early than less portable (i.e. using Windows NT experiments with the Microsoft POSIX specific constructs.) subsystem is that all the “big” things (process • To ensure performance was not effected by semantics, signals, and the file system) behave as an appreciable amount. expected − it is the little things that are • To ensure that the Windows NT operating surprising. The ttyname( ) description in system’s integrity was not compromised in POSIX.1 states that the function returns a pointer anyway (e.g. security). to a string containing the pathname of the • To integrate the INTERIX subsystem cleanly terminal, but returns a NULL pointer if the file into the Windows NT world such that it was descriptor is invalid or if the pathname cannot be not “isolated” with respect to such things as determined. There are no error conditions that data access and application or system are detected[1]. A function that always returns a management. NULL pointer is a sufficient implementation to
Page 3 After initial investigations into Windows95, it • X11R5 clients libraries (Xlib, Xt, Xaw, etc.) was decided to not pursue a solution in this and almost all the X11R5 clients space. There is no way to provide complete or • pseudo-terminals true POSIX/UNIX semantics on Windows95. • OSF/Motif 1.2.4 • cron service The overall goal was to leverage the Windows • gcc/g++/g77 and gdb/truss, as well as the NT environment subsystem architecture and “standard” development tools [g]make, rcs, design to its logical conclusion, taking it from the lex, yacc, nm, ar, strip general purpose application environment that • telnetd with full concurrent multi-user exists solely in the Win32 subsystem space, and support. using it to provide an application platform for • both Win32 and UNIX-based applications. inetd, ftpd, rshd, rlogind, rexec • tape device support • 3. A Short History of INTERIX Perl 5 • the public domain KornShell with full job In September 1995, Softway Systems, Inc. control, the Tenex csh and 290+ utilities entered into a long-term agreement with Microsoft to extend the Microsoft POSIX subsystem into a complete traditional UNIX 4. The INTERIX Architecture subsystem, capable of branding to the Open The overall architecture of INTERIX consists of Group’s UNIX 95 profile brand. Work began the environment subsystem, its mapping to the immediately to wrap the POSIX subsystem in a Windows NT file system (NTFS), its relationship shell and utilities environment (delivered March to functional subsystems (e.g. security), and its 1996) that conformed to the POSIX.2 Shell and compiler environment. Issues of integration with Utilities Execution Environment. An X11R6 the rest of Windows NT and the Win32 server was added (July 1996), along with a telnet subsystem are discussed in the following section. service (August 1996). A software development kit (SDK) was added such that developers could begin porting their own applications (September 4.1The INTERIX Subsystem 1996). At that time, the SDK essentially The INTERIX subsystem consists of three parts: supported the POSIX.1 interfaces, ISO C library, • The subsystem itself (PSXSS.EXE) that and approximately 60 historical Berkeley library functionally re-maps the Windows NT kernel routines from the 4.4BSD-Lite distribution that and manages such items as process were required while developing the first POSIX.2 relationships and signal delivery. implementation. It provided the additional tools • The terminal session manager (POSIX.EXE) required to develop applications (the RCS that manages the desktop console window version control suite, ar, cc/c89) and wrapped the for each INTERIX-based session leader. Microsoft Visual C/C++ command-line compiler. • The dynamic link library (PSXDLL.DLL) Extending the INTERIX subsystem to map more that handles certain system service requests of the kernel interface and adding libraries and directly, as well as the communication utilities has been ongoing. With the release of between the subsystem and INTERIX OPENNT 2.0 (May 1997) and OPENNT 2.1 (Jan processes. 1998), there is now support for: When an INTERIX application is started for the • POSIX.1, including a nearly complete first time, the Win32-based Program Manager general terminal interface determines that the application belongs to a • ISO C standard library subsystem other than the Win32 subsystem and a • Berkeley sockets number of events happen: • System V Interprocess Communications • If the INTERIX subsystem is not already facilities (shared memory, semaphores, running, it is started. The subsystem can be message queues). configured to start-up at system boot time, • Memory mapped files but by default is started for the first INTERIX • System V and Berkeley signal interfaces application. layered onto the POSIX.1 signal semantics. • A terminal session manager is started to • traditional curses (ncurses also supports manage console window output for the colour) application. A terminal session manager runs
Page 4 for each session. It is the tty device for an subsystem is able to create hard-links in the file INTERIX application. system, something not available via the Win32 subsystem. Win32 subsystem applications (such At that point, application processes run, as the Explorer or File Manager) see two communicating with the INTERIX subsystem in separate files. Case sensitivity in the filename is the same manner as a Win32 application runs and supported through the INTERIX subsystem, so communicates with the Win32 subsystem. Fast both makefile and Makefile can exist, and Local Procedure Call (LPC) and shared memory removing one will not accidentally remove the are the two primary mechanisms used for other. communications between the INTERIX subsystem and its processes. Advanced features of NTFS are also available to applications running from the INTERIX 4.2The Windows NT File System subsystem. The audit capabilities to track file access success/failure of open, close, read, and NTFS was developed for Windows NT to write operations are features of NTFS, and provide a fully functional file system and address available to INTERIX applications. The ability to the shortcomings of the DOS FAT file system. use additional permission controls with access It provides: • control lists is also available. These are all file Recoverability and redundancy of critical system capabilities that managed by applications disk structures that are outside the typical ported application. • Enhanced security consistent with the Windows NT provides the tools to manipulate Windows NT security model the audit and advanced security features of • Data redundancy capabilities to support disk NTFS. mirroring and striping • Support for large volumes 4.3Security, Privileges, and • Unicode-based filenames Permissions • Bad cluster remapping • POSIX file system semantics, including case sensitivity for filenames, hard links, the file Windows NT has obtained its U.S. Department change time stamp, and group ownership of Defense Orange Book C2 security certification, supporting all required discretionary File access is mapped from the process to data on access controls. One of the goals of INTERIX the disk via a layered driver model. The NTFS was to ensure it worked cleanly with the security driver is simply another driver layer under the model on Windows NT, and did not compromise control of the Windows NT executive I/O any of its capabilities. manager. The NTFS driver can further layer on various fault tolerant drivers, and ultimately In general, objects (e.g. files) are protected by layers onto the actual disk driver. access control lists (ACL) that are made up of access control entries (ACE). When a user logs All system service calls for file access come onto Windows NT, authentication is provided through the I/O manager, regardless of the via username and password and confirmed environment subsystem of origin, i.e. both the through the security subsystem. An access token Win32 and INTERIX subsystems share a common is associated with the successfully logged on view of the NTFS. There is no container file user’s process and this is used in all actions with system in which POSIX/UNIX file system objects to determine what access is appropriate semantics are emulated. Files are treated as given the objects’ ACLs. objects within the Windows NT executive, and are managed by the Object manager with respect Several issues arise with respect to INTERIX. to object (file) sharing and protection. The The user and group name space is shared. There Object manager interfaces with the Security is no concept of separate user and group Reference Monitor when checking file access databases. Groups can also own objects. This permissions. means that a file created on the Win32 side of the house may be owned by a group, and a long While the INTERIX subsystem shares a common listing (ls) from the INTERIX side of the house view of the files within the NTFS, additional will show a group name as both the owner and functionality is supported. The INTERIX the group of the file. This is a little disconcerting for a UNIX system user the first time it is
Page 5 witnessed. Files created from the INTERIX side testers complained about this lack of a root user of the house assign ownership appropriately and id. consistently with the POSIX standards. 4.4The Compiler Environment There are no actual permission bits for a file or The INTERIX development environment consists directory, but rather ACLs are used to map the of the GNU compilers (gcc/g++/g77), a set of permission world of UNIX/POSIX. There is an headers, libraries, and shell script compiler drivers ACE entry for the file owner, file group, and a for cc and c89 that wrap around the command- group named “Everyone” that align with the line version of the Microsoft Visual C/C++ appropriate permission fields traditionally compiler (CL.EXE) and linker (LINK.EXE). associated with file permissions in the UNIX world. The ACL can be displayed via the File The compiler builds object modules that can be Manager. Again, files created from the Win32 linked regardless of the subsystem with which the side of the house will receive an ACL consistent application will run. The Microsoft linker knows with the Win32 subsystem rules. A long listing how to stamp the executable appropriately for the from the INTERIX world must map the ACL to “POSIX” subsystem, such that it is correctly permission bits as best it can. Additional levels passed off to the subsystem when the Win32 of security are possible by adding additional subsystem determines it is a “POSIX” binary at ACEs. application start-up time. There are no /etc/passwd or /etc/groups files. All Programs that run as clients of one environment authentication information is kept in the database subsystem cannot make calls to interfaces accessed by the security subsystem. This is one supported by another environment subsystem, so of the two areas that source code changes separate libraries are provided to ensure no specific to INTERIX are required for an dependencies to the Win32 world are referenced application that authenticates users. (The other is within the libraries. handling rooted pathnames that expect /usr and / bin to exist in the file hierarchy.) The idea of Support for gdb and truss has been provided by generating a “shadow” password file was implementing a /proc environment. The MSVC entertained then quickly dropped. The sheer compilers do not generate sufficient information scope and size of some Windows NT domains in the object files to be particular good with gdb, and the number of users in those domains made so compilation with gcc/g++ is the recommended start-up time infeasible, and synchronization way to get complete gdb functionality. issues and the maintenance of security would prove too fragile. We provided scripts that allow a system administrator to generate the domain or 4.5Performance Issues local password database, such that daily user The INTERIX subsystem is a peer environment administrative jobs can still be run against it. subsystem to the Win32 subsystem. INTERIX processes communicate with the INTERIX As there is no password file against which to subsystem using the same mechanisms as Win32 authenticate a user, INTERIX provides a simple subsystem processes use to communicate with the functional interface to handle user authentication, Win32 subsystem. as well as a set of exec( ) functions to execute an application as a particular user. The INTERIX Comprehensive benchmarks have not been run, login program executed by the INTERIX telnetd but early informal work has been done using the makes use of these functions to setup the shell as iozone [10] benchmark, netperf [11] benchmark, a new user. This replaces the setuid mechanism. and some informal programs to compare CPU bound program throughput. The iozone tests and Windows NT does support an Administrator user CPU tests were run on a traditional UNIX system with enhanced privileges, as well as an as well as both the Win32 and INTERIX administrators group. There is, however, no root subsystems running on identical hardware. The user with all privileges. This has not caused any netperf benchmarks were run between insurmountable problems in any of the application comparable Windows NT machines, and porting experiences we have had to date, nor Windows NT and a similar Intel machine running have any of the customer base or product beta- a traditional Berkeley-based system. Informal trials indicate:
Page 6 • CPU bound applications perform the same between the Win32 and INTERIX Determining the balance between protecting the subsystems. application investment and solving the business • CPU bound applications performed better on problem with a platform’s unique attributes INTERIX than a mainstream traditional becomes a challenge. UNIX system. • INTERIX and a traditional UNIX platform Windows NT provides a rich environment of showed comparable disk performance trends tools and functionality, developed on top of the with iozone. Win32 subsystem. The model for integration • For small block read( ) and write( ) between the Win32 and INTERIX worlds happens operations, Win32 outperforms INTERIX. at a higher level than the application For large block read( ) and write( ) programming interface. Applications source code operations, INTERIX outperforms Win32. is ported directly to Windows NT to run with the • Socket throughput between Windows NT INTERIX subsystem. This protects the and a traditional Berkeley system on a local application investment. Integration with the network is virtually the same regardless of Win32 world can then take place in a number of whether the performance testing programs ways: NTFS, the Desktop, Win32exec, shared are running with the INTERIX or Win32 memory, pipes and sockets. subsystems. From an end-user's point of view, on a single Performance tuning is an ongoing task and there machine environment they simply have a are a number of projects underway to increase the “desktop” full of applications. They don’t care overall performance of the INTERIX subsystem. which subsystem the application is communicating with for kernel services anymore than they care in which language the programmer 5. Integration with the Win32 World wrote the source code. Walli’s Second Law of Applications Portability: Useful applications seldom live in a vacuum. 5.1NTFS The Win32 and INTERIX worlds share a common There are a number of stresses on applications file system. Files created in one world are seen in that exist on multiple platforms or have a history the other. All the security and auditing features of being migrated to new platforms. provided by NTFS and managed through the • Most operating systems provide functionality Win32-based administration tools are available to beyond that defined in the POSIX family of INTERIX ported applications. standards and the Open Group specifications. This additional functionality may be as straight forward as providing the X11 GUI, 5.2The Desktop or as complex as MVS, VMS, and Windows Windows NT presents either the Windows 3.1 or NT, where another entire operating the Windows 95 desktop. This environment environment is present. easily supports interaction between the INTERIX and Win32 worlds. • Applications often contain platform specific source code. This can be to leverage An INTERIX subsystem terminal or tty appears as platform specific functionality, or to handle a Win32 console. This means large windows and functionality provided differently on different screen buffers, scroll bars and cut-and-paste are platforms. all available at the user interface. An INTERIX console window behaves very much like a local • Once deployed the need to share data xterm. Cut-and-paste between Win32-based between applications becomes a necessity, applications and INTERIX applications is flawless. and new applications are created in the space For example, text from a Microsoft Word between existing applications. document can be easily cut then pasted into a vi session or INTERIX shell. • The use of non-standard or platform specific tools and functions is sometimes necessary to Icons can be set up to launch INTERIX solve the business problem, indeed this may applications, included X11-based applications and drive the actual platform purchase. shell scripts.
Page 7 5.4INTERIX Sockets and Winsock Win32 GUI applications launched from an Applications can communicate in client/server INTERIX shell present their own window as fashion using sockets and the TCP/IP protocol. would be expected, and the application can either Client/server applications can be built to use be run in the foreground (where the shell will either the Win32 GUI for client code, written on wait for it to complete) or the background. Winsock in the Win32 subsystem (run on Windows NT and Windows 95), or maintain the 5.3Win32exec traditional UNIX client code with its X11 or An early ability demanded by users was to simple character interface written using sockets. execute Win32-based applications from the Server code is maintained as traditional UNIX INTERIX world. A Win32exec ability was added code running on the INTERIX subsystem. The that allows Win32 GUI and command-line long term flexibility of the solution is completely applications to be executed from within an in the developer's hands. INTERIX process. There are a number of examples of the strength There are a number of challenges to overcome in and flexibility of this solution in our own product this space. A Win32 GUI application is relatively space. straight forward, in that there is no I/O to be • Early on we ported the Apache web server managed between the subsystems. Once control directly into the INTERIX environment. The of the process has been passed to the Win32 Apache server source code plus all the subsystem, the INTERIX shell can wait or existing Perl, CGI, HTML scripting from the continue as desired. If a Win32 command-line UNIX environment comes directly into the user interface (CUI) application is run, and its Windows NT world on the INTERIX output is to be seen in the shell window, as if subsystem. The Microsoft Internet Explorer from the standard output of a “normal” child and Netscape browser are Win32 “clients” process rather than one running as a client of that can then be used to connect to the web another subsystem, a certain amount of server. handshaking and re-direction needs to be performed. Standard streams need to be mapped • The INTERIX X11R6 server is a Win32 to Win32 handles appropriately, such that I/O can application. All of the INTERIX X11R5 be redirected to other processes (Win32 or clients are INTERIX subsystem applications. INTERIX) in a pipeline, or to files. • The telnet daemon shipped with INTERIX is The ability to execute Win32 applications allows a direct port of a traditional UNIX telnetd a number of facilities to be instantly accomplished running on the INTERIX subsystem. Any in a manner most consistent with Windows NT, telnet client, local or remote, Win32-based or but with a “UNIX” interface. UNIX-based, can connect to it. (As a further example of mixing and matching in the For example, the lp utility becomes a simple shell environment to best express functionality script wrapper around the Win32 PRINT.EXE while protecting the application source, the command. All the functions available on the INTERIX subsystem telnetd further runs as a network printing system are instantly available in Windows NT service, controlled by either a manner most appropriate to the architecture, the INTERIX command-line service utility or while providing an interface most appropriate to the Win32 GUI service control applet in the a traditional UNIX environment. Likewise, Windows NT Control Panel.) useradd and userdel, traditional UNIX commands to manage users, become simple 5.5Shared Memory and Memory scripts wrapped around NET.EXE. A variation of this solution was used to support the mt Mapped Files command for tape device management. Instead The Win32 subsystem supports the concept of of adding a lot of non-standard tape device memory mapped files. The Windows NT kernel interfaces to the INTERIX subsystem, the mt supports shared memory sections, but these are command was written as a simple Win32-based not directly manifested to the programmer. command-line utility and installed in the bin INTERIX supports SVID shared memory and directory. The shell executes mt as it would any memory mapped files. A very high bandwidth other command. connection can be created between Win32 and
Page 8 INTERIX processes using memory mapped files. the INTERIX Tcl/Tk environment running With the next release of INTERIX (June 1998) a with the familiar X11 look-and-feel on developer will be able to Win32 map an INTERIX Windows NT. shared memory section as a file as well. While the first solution adds a new dimension to 5.6Win32 GUIs and UNIX Applications the applications architecture with respect to the [12] Windows world of both Windows NT and Windows95, the latter two solutions provide A number of customers have raised the question graphic front-ends with a broad range of of how to create a Win32 (Win95) GUI for a deployment opportunities and flexibility. UNIX application ported to Windows NT. This is an evolutionary step beyond simply porting the application directly to Windows NT on the 5.7UNIX Daemons and Windows NT INTERIX subsystem, and the customer has Services [13][14] already decided that new work will be An early customer demand from INTERIX was a undertaken. better telnet daemon than was commercially available. To port a traditional telnetd to The environment subsystem architecture prevents INTERIX required pseudo terminals be added to client applications of one subsystem calling DLLs the subsystem. Once this was accomplished, the from another subsystem, so the obvious step of Berkeley telnetd ported directly to INTERIX. simply embedding Win32 GUI calls into the Merely having an INTERIX telnet daemon did not UNIX application source base is unavailable. completely fulfill the customer requirement. On Modifying the application source to embed Windows NT, services are the functional Win32 GUI interfaces is a very limiting solution equivalent to UNIX daemons, and there are a and prevents the redeployment of the application number of tools available (both graphic and again without substantial work. command line) for managing Windows NT services. Three different methods of wrapping a Win32 GUI on UNIX applications have been used with One can run a traditional daemon as a process in INTERIX depending upon the nature and domain the background, however, INTERIX more of the application: properly supports running INTERIX ported • If the application is (or lends itself to) a daemons as Windows NT services. To the client server architecture, then the server side service manager, the daemon appears to be a is directly ported to Windows NT on the service. It correctly maps the Windows NT start INTERIX subsystem maintaining the and stop messages to the appropriate signals the application development investment here, daemon understands. and the client is written to Win32. The client has been written using Visual Basic or Once telnetd was built, inetd was quick to follow MSVC/C++ and Winsock. The client is and as of Spring 1998, INTERIX supports all the exportable to any “Windows” system. traditional internet daemons (inetd, telnetd, • Two different customers have written web- ntalkd, ftpd, tftpd, rlogind, rshd, fingerd, rexecd) based Java front-ends to the UNIX back-end configured through a traditional inetd.conf file in on INTERIX. This has the added benefit that the /etc directory. as long as the developer is careful, they have a completely portable graphic front-end to One of the interesting aspects of supporting the match their portable UNIX application back- daemons is to ensure they correctly integrate with end. the Windows NT security model. The use of • We have experimented in-house with the setuid() is restricted in use. For an application Win32-based Tcl/Tk provided free from Sun like telnetd, it is relatively straight forward to Microsystems. The Win32 implementation modify login to correctly exec the shell with the is a complete Tcl/Tk environment but the Tk execasuser call after fetching the user’s widget set displays with a Win32 look-and- password. For remote shell operations where the feel. The UNIX application code runs as a user does not want to continually use their ported INTERIX application. The Tcl/Tk password, INTERIX supports a .password file that graphic front-end is portable to any UNIX makes use of NTFS ACL security to ensure the environment supporting Tcl/Tk, including security of the system. It is recommended that
Page 9 inetd is run as a completely unprivileged account also been ported so configure scripts that rely on to further ensure the security of the environment. it have fewer problems.
6. Porting Experiences Configure aside, the source code itself often just builds. Before configure support was added, the Literally millions of lines of complex UNIX fastest way to port a GNU tool to INTERIX was application code has been ported to Windows NT to toss away the configure script, copy the with INTERIX by a large base of commercial and makefile template and configuration header government organizations. (As of Spring, 1998 template, and quickly hand-tune them turning on there were also 22 independent software vendors anything that said POSIX or ANSI C. A fast shipping products on top of INTERIX.) The inspection was often enough to get it right. The following sub-sections discuss porting source code typically built at that point. For experiences with various packages of software example, the only changes required in the 17000+ that the Softway Systems developers have ported lines of gawk was to change
6.14.4BSD-Lite Configure still has problems in some areas. Much of the original utility base for the early There are some scripts (e.g. bash) where headers INTERIX commands and utilities came straight appear to be scanned for prototypes which misses off the 4.4BSD-Lite distribution. The general functions defined as macros, and thus configure flow was to copy the source distribution over to a doesn’t. It took on the order of two hours to working directory, use a simple template port bash (Gnu’s Born Again Shell). The makefile, and begin simple compile-edit cycles primary problems were stepping around the GNU until the utility built. The first thing that always malloc environment in the build, and catching and needed to be changed was to change fixing a circular macro definition associated with
Page 10 distribution, with the single exception of the xmkmf was used to generate the appropriate setuid test. Makefile and xv was made.
6.4Apache 7. Summary Apache, the public domain web server, is 45,726 It has become too expensive to continually lines of code. It was ported as an experiment rewrite applications to move them from system to early in the alpha test cycle of OPENNT 2.0. system, and source code portability is an important tool to protect existing applications Initially, investments. Our experience clearly • symbolic links, setsid( ) and setpgrp( ) were demonstrates that the Windows NT architecture stepped around. of alternative environment subsystems provides a • Calls to mktemp( ) were changed to use way to accomplish this. INTERIX provides the getenv( ) of $TMPDIR instead of hard- facilities of a traditional UNIX system on coding path names. Windows NT, such that existing applications • Uses of chown( ) were avoided as they developed on traditional UNIX systems can be violated the chown( ) functionality mandated directly brought to Windows NT, rebuilt, and by POSIX.1 in association with the standard deployed. Using the environment subsystem option POSIX_CHOWN_RESTRICTED. architecture of Windows NT, a peer environment • A crypt( ) routine (taken from 4.4BSD-Lite) to the Win32 world exists, and is integrated to was required. that world in a manner most logical to both.
The following stanza (reformatted for Up-to-date information about INTERIX can be publication) was added to the configuration found at: http://www.INTERIX.com header for INTERIX. 8. References #elif defined(INTERIX) 1. ISO/IEC 9945-1:1990, Information #define S_ISLNK(m) (0) Technology Portable Operating System #define bzero(a,b) memset(a,0,b) #define Interface (POSIX) Part 1: System USE_FCNTL_SERIALIZED_ACCEPT Application Program Interface (API) [C #undef HAS_GMTOFF Language], IEEE Standards, NJ, ISBN 1- #define NO_KILLPG 55937-061-0 #define NO_SETSID 2. ISO/IEC 9945-2:1993, Information #define JMP_BUF sigjmp_buf Technology Portable Operating System #include
Page 11 System Application Program Interface [C Language], 12 May, 1993. 8. OPENNT Commands & Utilities, Release 1.0, Softway Systems Inc., March 1996. 9. Walli, Stephen R., Go Solo: How to Implement and Go Solo with the Single UNIX Specification, Prentice Hall, Englewood Cliffs, NJ, 1995 10. The iozone benchmark available from this site includes source code and documentation for several I/O benchmarks, 9 May, 1997 http://www.cs.umbc.edu/~elm/Ftp/ iobenchmarks 11. netperf-1.7.1 Netperf is a benchmark for measuring networking performance. It focuses on bulk data transfer and request/response performance using TCP or UDP and the Berkeley Sockets interface. It is maintained and supported by the IND Networking: 19 March 1997 http://hpux.dsi.unimi.it/hppd/hpux/ Networking/Admin/netperf-1.7.1/ 12. Walli, Stephen R., Win32 Tcl/Tk GUIs on UNIX Apps on Windows NT, ;login Special Issue on Windows NT, November 1997. 13. Ruddock, Rodney and Walli, Stephen R., inetd and telnetd on Windows NT with OPENNT, ;login Special Issue on Windows NT, November 1997. 14. McMullen, John, and Ruddock, Rodney Technical Note #9: inetd and the Daemon Package, Softway Systems, Inc., 12 Feb, 1998.
9. Trademarks INTERIX is a registered trademark of Softway Systems, Inc. Windows NT is a trademark of Microsoft Corporation. UNIX is a registered trademark of The Open Group. All other trademarks belong to their respective holders.
Page 12