Chapter 29 - POSIX Compatibility

This chapter describes the Windows NT implementation of a POSIX subsystem. It includes information about the following topics:

Definition of POSIX

Conformance and compliance to POSIX.1

Running applications

Implementation of subsystem

Windows NT POSIX files

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.

StandardISO StandardDescription

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 application programming interface (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
A. Transparent file access
B. Protocol-independent network interface
C. Remote Procedure Calls (RPC)
D. 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.

POSIX Conformance

For a system to be given a certificate of POSIX.1 conformance, it must meet the following requirements:

The system must support all interfaces as defined in the ISO/IEC 9945-1.

The vendor must supply a POSIX.1 Conformance Document (PCD) with the vendor's implementation as specified in ISP/IEC 9945-1.

The implementation must pass the appropriate National Institute of Standards and Technology (NIST) test suite.

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:

Any behavior described in ISO/IEC 9945-1 as unspecified or implementation-defined

Symbolic constants

Any value in the range permitted in ISO/IEC 9945-1

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.

Running Applications

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.

File Systems

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

1.

Select the account in User Manager.

2.

From the Policies menu, select User Rights.

The User Rights Policy dialog box is displayed. Be sure the Show Advanced User Rights check box is selected.

3.

Select the Bypass Traverse Checking right.

4.

Click Remove.

5.

Click OK.

Printing

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:

Network Access

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.

Files Used

The following table lists the principal files used by the POSIX subsystem, and the figure shows how they interact.

FilePurpose

Psxss.exe

The POSIX subsystem server

Posix.exe

The POSIX console session manager

Psxdll.dll

The POSIX dynamic link library

 

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 

Further Information

For further information on the POSIX standards, contact the following resources:

For information on POSIX.1 (ANSI/IEEE 1003.1-1990, ISO/IEC 9945-1:1990), contact:

Publication Sales
IEEE Service Center
P.O. Box 1331445
Hoes Lane 

Piscataway, NJ 08855-1331

For information on other POSIX standards, contact:

IEEE Computer Society
Attention: Assistant Director/Standards
1730 Massachusetts Avenue Northwest
Washington, DC 20036



© 2014 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies