Chapter 29 - POSIX Compatibility
This chapter describes the Windows NT implementation of a POSIX subsystem. It includes information about the following topics:
Note This chapter is not intended to be a POSIX tutorial.
Definition of POSIX
POSIX, which stands for Portable Operating System Interface for computing environments, began as an effort by the IEEE community to promote the portability of applications across UNIX environments by developing a clear, consistent, and unambiguous set of standards. POSIX is not limited to the UNIX environment, however. It can be implemented on non-UNIX operating systems, as was done with the IEEE Std. 1003.1-1990 (POSIX.1) implementation on the VMS, MPE, and CTOS operating systems. POSIX actually consists of a set of standards that range from POSIX.1 to POSIX.12.
As the following table shows, most of these standards are still in the proposed state. This section deals with the Windows NT implementation of a POSIX subsystem to support the international ISO/IEC IS 9945-1:1990 standard (also called POSIX.1). POSIX.1 defines a C-language source-code-level application programming interface (API) to an operating system environment.
For a system to be given a certificate of POSIX.1 conformance, it must meet the following requirements:
Windows NT version 3.51 Workstation and Windows NT Server have been tested and certified using the official NIST PCTS for Federal Information Processing Standard (FIPS) 151-2, and NIST has validated the test results. Windows NT 4.0 will begin testing soon. Windows NT version 3.5 is in the process of being verified for POSIX.1 compliance and will also be submitted to NIST for FIPS 151-2 certification. FIPS 151-2 incorporates POSIX.1 as a reference standard and also requires a number of the optional features defined in POSIX.1 to promote application portability among conforming implementations. An implementation that conforms to FIPS 151-2 also conforms to POSIX.1. Note that conformance is specific to the manufacturer, hardware platform, and model number on which the implementation is tested.
POSIX.1 is a source-level standard; it does not provide any binary compatibility.
Application Compliance to POSIX.1
POSIX.1 has four categories of compliance, ranging from very strict to very loose. The various categories are described in this section.
The current release of Windows NT supports strictly conforming POSIX.1 applications and ISO/IEC conforming POSIX.1 applications. Windows NT supports the latter by virtue of the fact that only 110 of the 149 functions of standard C are part of POSIX.1, and standard C is itself an ISO standard (ISO/IEC 9899).
Strictly Conforming POSIX.1 Applications
A strictly conforming POSIX.1 application requires only the facilities described in the POSIX.1 standard and applicable language standards. This type of application accepts the following conditions:
This is the strictest level of application conformance, and applications at this level should be able to move across implementations with just a recompilation. At this time, the only language interface that has been standardized for POSIX.1 is the C-language interface. (As shown in the figure below, a strictly conforming POSIX application can use 110 calls from the standard C libraries.)
Figure 29.1 A Strictly Conforming POSIX Application
Applications Conforming to ISO/IEC and POSIX.1
An ISO/IEC-conforming POSIX.1 application is one that uses only the facilities described in ISO/IEC 9945-1 and approved conforming language bindings for the ISO or IEC standard. This type of application must include a statement of conformance that documents all options and limit dependencies, and all other ISO or IEC standards used.
Figure 29.2 An ISO/IEC-conforming POSIX.1 Application
This level of conformance is not as strict as the previous one for two reasons: First, it allows a POSIX.1 application to make use of other ISO or IEC standards, such as GKS. Second, it allows POSIX.1 applications within this level to require options or limit values beyond the minimum. For example, such an application could require that the implementation support filenames of at least 16 characters. The POSIX.1 minimum is 14 characters.
Applications Conforming to POSIX.1 and <National Body>
A <National Body> conforming POSIX.1 application differs from an ISO/IEC-conforming POSIX.1 application in that this type of application may also use specific standards of a single ISO/IEC organization, such as ANSI or British Standards Institute (BSI). This type of application must include a statement of conformance that documents all options and limit dependencies, and all other <National Body> standards used.
For example, you could have a <National Body> conforming POSIX application that uses calls from a BSI-standard set of calls.
Figure 29.3 A National Body Conforming POSIX.1 Application
POSIX.1-Conformant Applications that Use Extensions
A conforming POSIX.1 application using extensions is an application that differs from a conforming POSIX.1 application only because it uses nonstandard facilities that are consistent with ISO/IEC 9945-1. Such an application must fully document its requirements for these extended facilities.
Figure 29.4 A Conforming POSIX.1 Application Using Extensions
This is the lowest level of conformance; almost any C program could satisfy this with the appropriate documentation.
POSIX applications can be started from a Windows NT console window (command prompt), My Computer, the Windows NT Explorer, or by invocation from within another POSIX application.
POSIX requires a certain amount of functionality from the file system, such as the ability for a file to have more than one name (or hard links) and case-sensitive file naming. Neither FAT nor HPFS supports these features, which is another reason why a new file system was required for Windows NT. NTFS supports both hard links and case-sensitive naming. If you want to run in a POSIX-conforming environment, you need at least one NTFS disk partition on your computer.
You can run POSIX applications from any Windows NT file system. If the application does not need to access the file system, the application will run with no problems. However, if the application does require access to the file system, it might not behave correctly on a non-NTFS disk partition.
Bypass Traverse Checking
By default, when you install Windows NT for the first time, the user right Bypass Traverse Checking is granted to everyone. This right allows a user to change directories through a directory tree even if the user has no permission for those directories.
If you want to run in a POSIX-conforming environment, you must disable this privilege for your account by using the User Manager Administrative tool.
Note You must be an administrator to do this.
To disable the Bypass Traverse Checking right for an account
The POSIX subsystem itself does not directly support printing, but Windows NT supports redirection and piping between subsystems. If your POSIX application writes to stdout, and if you have connected or redirected either your serial or parallel ports to a printer, you can redirect the output of a POSIX application to that printer. For example, the following sequence of commands will send to a network printer the output of a POSIX application that writes to stdout:
NET USE LPT1: \\MYSERVER\PRINTER POSIXAPP.EXE > LPT1:
The POSIX.1 specification does not have a requirement for access to remote file systems, but as with any of the other subsystems, the POSIX subsystem and POSIX applications have transparent access to any Win32 remotely connected file system.
Restrictions on POSIX Applications
With this release of Windows NT, POSIX applications have no direct access to any of the facilities and features of the Win32 subsystem, such as memory mapped files, networking, graphics, or dynamic data exchange.
Implementation of Subsystem
The POSIX subsystem is implemented in Windows NT as a protected server. POSIX applications communicate with the POSIX subsystem through a message-passing facility in the Executive known as a Local Procedure Call (LPC).
Figure 29.5 POSIX Subsystem in Windows NT
The POSIX subsystem and each POSIX application run in a protected address space that protects them from any other application that might be running on Windows NT. POSIX application are preemptively multitasked with respect to each other and with respect to other applications running in the system.
The following table lists the principal files used by the POSIX subsystem, and the figure shows how they interact.
Figure 29.6 How POSIX Subsystem Files Interact
Communicating with Other Subsystems
Windows NT supports a common command processor that can run commands from any subsystem. In addition, Windows NT supports piped input and output between commands of different subsystems. For example, you could run the ls utility and pipe the results through the more command to the console:
ls -l | more
For further information on the POSIX standards, contact the following resources: