Standardizing UNIX

• By David Chisnall
• Feb 2, 2007
• Article is provided courtesy of Prentice Hall Professional

Like this article? We recommend
UNIX System Administration Handbook, 3rd Edition

Andrew Tanenbaum once said that the nice thing about standards is that there are so many to choose from. In the UNIX dark ages, there were no standards. Everyone who released a version of UNIX would support the base functionality from the AT&T or BSD code that they started with and then add a load of their own extensions on top.

Since one of the key marketing features for UNIX vendors was that it was easy to port code from one UNIX to another, the lack of standards was a problem. A group of European UNIX vendors decided to address the problem by developing the X/Open specification. Any code written to that specification could be run on any conforming implementation.

Unfortunately, this standardization effort happened at the same time as another effort conducted by the IEEE, which produced the IEEE 1003 specification. Because "IEEE 1003" isn’t very easy to remember, and doesn’t exactly roll off the tongue, the IEEE asked for suggestions for a more catchy name. Richard M. Stallman, better known for founding the GNU Project, proposed the name Portable Operating System Interface. Since POSI would have sounded silly, an X was added on the end to make the acronym POSIX. This change made the name sound more like UNIX, and made it a lot more marketable.

Windows NT and the POSIX Checkbox

The U.S. government has always been a fan of standards, and POSIX was no exception. Many government agencies specify POSIX as a requirement. This was a significant problem for one vendor, which had quite a large portion of the operating systems market. Microsoft DOS wasn’t POSIX-complaint, and since it also wasn’t UNIX-based, making DOS POSIX-compliant would have taken a lot of effort.

Microsoft’s new operating system, Windows NT, was designed with the ability to run different servers, providing different interfaces to the system. One of these interfaces was used to run OS/2 applications, one handled "native" Win32 applications, and one was provided for POSIX compatibility.

Unfortunately, the Windows NT POSIX layer was close to useless. The POSIX standard itself included a lot of ambiguity; many functions are allowed to return ENOTIMPLEMENTED and fail. A system may pass all of the POSIX compliance tests with only a significant fraction of the functions, and Microsoft’s implementation did exactly that. Windows NT developers were expected to use the Win32 API, and not POSIX. The POSIX subsystem was there to allow them to put a tick in the correct feature box, and not for anyone to actually use. Not only was the POSIX subsystem woefully incomplete—it was impossible to mix POSIX and Win32 code in the same application. Therefore, POSIX applications (if you could get them to run at all) were limited to the command line, since the only way of accessing the GUI functionality was the Win32 API.

Fortunately, the story doesn’t end there. In 1995, Steve Chamberlain, working at Cygnus Solutions, noticed that much of the code was already in place to allow the GNU Compiler Collection (GCC) to produce Windows executables. It already supported the COFF binary format used by 32-bit versions of Windows, as well as the x86 instruction set.

Once GCC was able to produce Windows binaries, it was logical to try to make it run on Windows. Unfortunately, this task was much more difficult. Building GCC requires a POSIX-like environment, which wasn’t available on Windows. A few Cygnus engineers began working to produce a POSIX compatibility layer that translated POSIX calls into native Windows calls—the opposite of Winelib.

In 1999, Cygnus Solutions merged with Red Hat, which continues to develop this translation layer, marketed as Cygwin and available under the GPL or a closed-source license. Over the years, a lot of Free Software has been compiled and packaged using Cygwin, including a complete X server, allowing many graphical UNIX applications to be run on Windows with no modification.

At the same time as Cygwin was being developed, Softway Systems created OpenNT, a replacement for the POSIX subsystem in Windows NT. Later the name was changed to Interix; and finally, after being purchased by Microsoft, was named Services for UNIX. As of 2004, server versions of Windows have a POSIX subsystem that supports threads, signals, sockets, and shared memory, less than twenty years after the standard was finalized, and only a little over a decade after Microsoft began advertising POSIX compliance.