The Posix portable operating system interface standard produced by the IEEE has provided a useful focus for related standards efforts such as X/Open’s Portability Guide and the Japanese Sigma project, and is a common link between developments undertaken by the Open Software Foundation and Unix International. But now companies are adding the Posix interface to their proprietary operating systems, and two of the leading US trade papers have been jumping to the erroneous conclusion that these firms are implementing Unix under their proprietary operating systems. There is so much confusion over exactly what Posix-compliance really means, so we asked Dominic Dunlop of The Standard Answer to explain the position.

Many people think that Posix is a standard for Unix. It’s not. If it were, it would not be possible for Digital Equipment, Hewlett-Packard, and Microsoft to confuse an already bemused market by announcing Posix interfaces for their proprietary operating systems – VMS, MPE/V, and OS/2 respectively. Why are suppliers rushing to jump on the Posix bandwaggon, and what is it about the Posix standard that enables them to do so without completely jettisoning their original operating environment? And, in the end, does Posix compatibility at this level bring any benefit to computer users? As with so many things in this world, the answers to these questions have to do with power, and those that wield it.

Check in the box

The US government wields a lot of power over computer suppliers by dint of the enormous budget that it controls. So, when the government’s National Institute of Science and Technology (NIST, formerly the National Bureau of Standards – NBS) brings out a Federal Information Processing Standard that specifies requirements to be satisfied by all US government purchased computers, suppliers sit up and listen. A year ago, NIST released FIPS 151. Broadly speaking, this states that all computers purchased by the US government for general purpose data processing must be able to offer a Posix interface. (There are various exceptions: one of the more important is that, pending a standard for real-time Posix, computer systems that must satisfy some real-time requirement can ignore the FIPS.) Note that the FIPS requires only a capability: it does not specify that the computer actually runs Posix while doing the job for which the government buys it. All it has to do is offer a Posix interface in case the government decides to install additional Posix-compliant application software at some time in the future. This approach is realistic: large application packages cannot be written to use a new operating system interface at the drop of a hat, so many current needs can be satisfied only by existing packages designed for proprietary operating systems. On the other hand, the approach enables suppliers to continue offering solutions based on proprietary technology, just so long as they can prove that Posix is supported as an option, and so put a check in the box on the requirements form. This may well delay the day when all the applications are written for Posix as a matter of course.This brings us to another concentration of power – that of the manufacturers themselves. It was clear from the early days of the Posix project in the Institute of Electrical and Electronic Engineers, IEEE, that the proposed operating system interface could not simply describe Unix running on a bare machine, but must also apply to emulations of Unix hosted by other operating systems. Without this capability, Posix could not gain support from important computer manufacturers, and so would have little chance of becoming a publicly-agreed standard. Consequently, IEEE Std 1003.1-1988, the document that finally emerged from the standards process, is careful not to specify anything that might imply that the Posix environment has total control of its host system. For example, nothing in the standard allows even a privileged user to set the time of day, to connect or disconnect file systems, or to configure input-output devices: these actions may be the pr

ovince of some underlying environment, not of Posix itself. The result is a definition of an environment that can be hosted by VMS, MPE, OS/2, and, indeed, any other multi-tasking operating system that offers a supervisor mode and a protection mechanism. It is also a definition that is not quite rich enough to allow the implementation of many types of practical application program. Federal Information Processing Standard 151 makes the application developer’s life a little easier by requiring some features specified only as options in the Posix standard. Consequently, a FIPS-compliant interface is a better base for useful applications than an interface that presents simply the minimum requirements of the Posix standard. And, because the FIPS is backed by the stick of US government requirements and the carrot of US government funds, it has come to represent the practical standard to which suppliers conform. Even so, a practical application program is likely to require a considerably larger foundation, taking in such topics as administration, command language, communications, database access, graphics and screen control. Standards covering these fields are emerging, and are likely to be backed by future US Federal Information Processing Standards.

Smart enough

The National Insitute of Science & Technology has done the world a service by requiring compliance with FIPS 151, but is smart enough to know that this is only one step along the road that leads eventually to open systems. The current Posix standard on its own is not rich enough to form a basis for practical applications in the real world. This applies whether the environment is in control of the systems on which it runs, or is hosted by some other operating system. Consequently, a supplier that offers no more than a Posix interface to an existing proprietary operating system is not offering a great deal: several additional standardised subsystems are required before the facility becomes useful. The many draft standards being developed by the IEEE and others will eventually be sufficient to define open systems that can fill any requirement without the need for extensions. Until then, less authoritative, but considerably more comprehensive, documents such as the X/Open Portability Guide, come much closer to describing practical systems which allow real application portability.