The Art of Unix Programming

haoji

This made it harder to argue about what features should be in the standard.

Prev Up Next

Chapter 15. Portability

Home Unix standards

haoji

Unix standards

Prev Chapter 15. Portability

Next



Unix standards

The 1973 rewrite of Unix in C made it unprecedentedly easy to port and modify. As a result,
the ancestral Unix diverged into a family of operating systems early on. Unix standards
originally developed to reconcile the APIs of the different branches of the family treee.

The Unix standards that evolved after 1985 were quite successful at this 鈥

haoji

The first attempt to bridge the gap came in February 1983 from UniForum, an influential
Unix user group. Their Uniform 1983 Draft Standard described a 鈥渃ore Unix System鈥

haoji

After 1985 the main thrust of Unix standardization passed to the Insitute of Electrical and
Electronic Engineers (IEEE). Their 1003 committee developed a series of standards generally
known as POSIX. These went beyond describing merely systems calls and C library
facilities; they specified detailed semantics of a shell and a minimum command set, and also
detailed bindings for various non-C programming languages. The first release in 1990 was
followed by a second edition in 1996. The International Standards Organization adopted
them as ISO/IEC 9945.

Key POSIX standards include:

1003.1 (released 1990)
Library procedures. Described the C systenm call API, much like Version 7 except for
signals and the terminal-control interface.
1003.2 (released 1992)
Standard shell and utilities. Shell semantics strongly resembles those of the System V
Bourne shell.
1003.4 (released 1993)
Real-time Unix. Binary semaphores, process memory locking, memory-mapped files,
shared memory, priority scheduling, real-time signals, clocks and timers, IPC message
passing, synchronized I/O, asynchronous I/O, real-time files.
In the 1996 Second Edition, 1003.4 was split into 1003.1b (real-time) and 1003.1c
(threads).


Despite being underspecified in a couple of key areas such as signal-handling semantics and
omitting BSD sockets, the original POSIX standards became the basis of all later Unix
standardization work. They are still cited as an authority, albeit indirectly through references
like POSIX Programmer's Guide [Lewine]; the de facto Unix API standard is still 鈥淧OSIX
plus sockets鈥

haoji

with the POSIX drafts, then after 1990 incorporated and extended them. Unlike POSIX,
which attempted to capture a safe subset of all Unixes, the X/Open Portability Guides
(XPGs) were oriented more towards common practice at the leading edge; even XPG1 in
1985, spanning SVr2 and 4.2BSD, included sockets.

XPG2 in 1987 added a terminal-handling API that was essentially System V curses(3). XPG3
in 1990 merged in the X11 API. XPG4 in 1992 mandated full compilance with the 1989
ANSI C standard . All three of these standards were heavily concerned with support of
internationalization and described an elaborate API for handling codesets and message
catalogs.

In reading about Unix standards you might come across references to 鈥淪pec 1170鈥

haoji

the reach of most distributors of open-source operating systems. In any case, Linux changes
so fast that any given release of a distribution would probably be obsolete by the time it
could get certified.

Standards like the Single Unix Specification have not lost their relevance. They're still
valuable guides for Unix implementors. But how the Open Group and other institutions of
the old-school Unix standardization process will adapt to the rapid tempo of open-source
releases (and to the low- or zero-budget operation of open-source development groups!)
remains to be seen.

Unix standards in the open-source world

In the mid-1990s, the open-source community began standardization efforts of their own.
These efforts built on the source-code-level compatibility secured by POSIX and its
descendants. Linux, in particular, had been written from scratch in a way that depended on
the availability of Unix API standards like POSIX.

In 1998 Oracle ported its market-leading database product to Linux, in a move that was
rightly seen as a major breakthrough in Linux's mainstream acceptance. The engineer in
charge of the port provided a definitive demonstration that API standards had done their job
when he was asked by a reporter what technical challenges Oracle had had to surmount. The
engineer's reply was 鈥淲e typed 鈥榤ake鈥

haoji

supermicros, and open-source Unixes changed the rules, Vendors found they no longer had a
stable platform to ship their binaries to.

The superficial problem, at first, was the large number of Unix distributors 鈥

haoji

IETF and the RFC standards process

Prev Chapter 15. Portability

Next



IETF and the RFC standards process

When the Unix community merged with the culture of Internet engineers, it also inherited a
mind-set formed by the RFC standards process of the Internet Engineering Task Force. In
IETF tradition, standards have to arise from experience with a working prototype
implementation 鈥

haoji

All IETF standards pass through a stage as RFCs (Requests for Comment). The submission
process for RFCs is deliberately informal. RFCs may propose standards, survey results,
suggest philosophical bases for subsequent RFCs, or even make jokes. The appearance of the
annual April 1st RFC is the closest equivalent of a high holy day observance among Internet
hackers, and has produced such gems as A Standard for the Transmission of IP Datagrams on
Avian Carriers (RFC 1149) and The Hyper Text Coffee Pot Control Protocol (RFC 2324).

But joke RFCs are about the only sort of submission that instantly becomes an RFC. Serious
proposals actually start as 鈥淚nternet-Drafts鈥

haoji

environments鈥