Ray Cort
Microsoft Corporate Technology Team
Created: May/June 1993
This article will discuss the following topics:
POSIX stands for Portable Operating System Interface for computing environments. POSIX 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. However, POSIX is not limited to the UNIX environment. It can also be implemented on non-UNIX operating systems, as was done with the IEEE Standard 1003.1-1990 (POSIX.1) Implementation on Virtual Memory System (VMS), Multiprogramming Executive (MPE), and the Conversion Technology Operating System (CTOS). 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 proposal state. This article deals with the Microsoft® 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.
Family of POSIX standards
Standard |
ISO Standard? |
Description |
| POSIX.0 | No | A Guide to POSIX Open Systems Environment. This is not a standard in the same sense as POSIX.1 or POSIX.2. It is more of an introduction and overview of the other standards. |
| POSIX.1 | Yes | Systems API (C Language) |
| POSIX.2 | No | Shell and tools (IEEE-approved standard) |
| POSIX.3 | No | Testing and verification |
| POSIX.4 | No | Real-time and threads |
| POSIX.5 | Yes | ADA language bindings to POSIX.1 |
| POSIX.6 | No | System security |
| POSIX.7 | No | System administration |
| POSIX.8 | No | Networking Transparent file access Protocol-independent network interface Remote Procedure Calls (RPC) Open system interconnect protocol-dependent application interfaces |
| POSIX.9 | Yes | FORTRAN language bindings to POSIX.1 |
| POSIX.10 | No | Super-computing Application Environment Profile (AEP) |
| POSIX.11 | No | Transaction Processing AEP |
| POSIX.12 | No | Graphical user interface |
The POSIX subsystem is implemented in Windows NT as a protected server (Figure 1). POSIX applications communicate with the POSIX subsystem through a message-passing facility in the Executive known as a Local Procedure Call (LPC).
Figure 1. POSIX subsystem in Windows NT
The POSIX subsystem, as well as each POSIX application, runs in its own protected address space that protects it from any other application that might be running on Windows NT. POSIX applications are preemptively multitasked with respect to each other and to other applications running in the system.
For a system to be given a certificate of POSIX.1 conformance, it must meet the following requirements:
Many people talk about a "POSIX-compliant" application, but what does that really mean? For POSIX.1, there are four categories of compliance, ranging from a very strict compliance to a very loose compliance. The various categories are outlined in the following subsections.
A strictly conforming POSIX.1 application (Figure 2) requires only the facilities described in the POSIX.1 standard and applicable language standards. This type of application accepts the following:
Figure 2.
This is the strictest level of application conformance. Applications at this level should be able to move across implementations with just a recompilation. At the time of this writing, the only language interface that has been standardized for POSIX.1 is the C language interface. (As shown in Figure 2, a strictly conforming POSIX application can use 110 calls from the standard C libraries.)
An ISO/IEC-conforming POSIX.1 application (Figure 3) is one that uses only the facilities described in ISO/IEC 9945-1 and approved conforming language bindings for ISO or IEC standards. 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 3.
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 Graphical Kernel System (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.
A <National Body>–conforming POSIX.1 application (Figure 4) differs from an ISO/IEC-conforming POSIX.1 application because this type of application may also use specific standards of a single ISO/IEC organization, such as the American National Standards Institute (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.
Figure 4.
For example, you could have a <National Body>–conforming POSIX application that used calls from a BSI-standard set of calls.
A conforming POSIX.1 application using extensions (Figure 5) 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 5.
This is the lowest level of conformance; almost any C program could satisfy this with the appropriate documentation.
This current release of Windows NT supports strictly conforming POSIX.1 applications, and ISO/IEC-conforming POSIX.1 applications. Windows NT supports the latter because 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).
Windows NT is in the process of being verified for POSIX.1 conformance, and will be submitted to NIST for the Federal Information Processing Standards Publication (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 applications can be started from a Windows NT console window (command prompt), File Manager, Program Manager, or by invocation from within another POSIX application.
The following files are required to support the POSIX subsystem and run POSIX applications:
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, there is no way to guarantee that it will behave correctly on a non-NTFS disk partition.
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 either the User Manager or User Manager for Domains tool as follows (you must be an administrator to do this):
Figure 6.
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 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 the output of a POSIX application that writes to stdout, to a network printer:
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.
Windows NT supports a common command processor that can execute commands from any of the subsystem. Furthermore, Windows NT supports the piping of input and output between commands of different subsystems. So, it is possible to do the following:
Windows NT supports a common command processor that can run commands from any of the subsystems. In addition, Windows NT supports piped input and output between commands of different subsystems. For example, you could type the following command to list the contents of the current directory, then pipe the results through the more command to the console:
ls -l | more
The ls utility is implemented in the POSIX subsystem and generates output as shown in Figure 7.
Figure 7.
Figure 8 illustrates how a POSIX application interacts with other components of the Windows NT operating system.
Figure 8.
A certain amount of functionality can be gained by using a single command shell of Windows NT. From a programming point of view, although not elegant, it is possible to put a Win32 graphical front-end on a POSIX application by using the redirection of stdin and stdout.
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.
For further information on the POSIX standards, contact either or both of the following resources.
For information on POSIX.1 (ANSI/IEEE 1003.1-1990, ISO/IEC 9945-1:1990):
Publication Sales
IEEE Service Center
P.O. Box 1331
445 Hoes Lane
Piscataway, NJ 08855-1331
For information on other POSIX standards:
IEEE Computer Society
Attention: Assistant Director/Standards
1730 Massachusetts Ave. NW
Washington, DC 20036