- Windows NT and the POSIX Checkbox
- A Tale of Two Standards
- Whats in a Standard?
- But Theres More!
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
But There’s More!
The UNIX specifications continue to evolve. In 2003, a new version of the Single UNIX Specification was released, commonly known as UNIX03. The UNIX-year nomenclature comes from the fact that The Open Group, which publishes the SUS, is the current custodian of the UNIX trademark, and so The Open Group’s standards define which systems are allowed to be called UNIX. In 2003, The Open Group sued Apple for describing OS X as UNIX without applying for certification. The case was settled in 2004. The exact terms of the settlement weren’t published, although Apple still refers to OS X as being "based on UNIX." Whether the UNIX trademark is still enforceable remains unclear, although these days the value of the UNIX trademark is somewhat difficult to distinguish anyway, since the two most widely distributed *NIX systems (OS X and Linux) are not officially UNIX.
Extensions to the POSIX specifications include the real-time APIs, which attempt to correct some of the shortcomings of the original UNIX APIs. Support for asynchronous I/O is one example, but a more useful one is a reworking of the UNIX signals model.
Traditional UNIX signals have some problems as a general-purpose event model. They convey only one bit of information—that a signal with a particular number has been raised. While in a signal handler, if another signal with the same number is raised, the signal handler itself could be preempted. Alternatively, you could mask future occurrences of the signal while the handler was running, but then they would be lost. There was no good way of sequentially processing each signal event.
The real-time signals extensions improve matters considerably. They provide an enhanced signal handler, which takes an argument containing some extra data associated with the signal. This value is either an integer or a pointer, and can be used to identify the source of the signal.
The other improvement offered by real-time signals is that they can be enqueued. When a real-time signal arrives, the signal handler runs to completion. Afterward, the next signal is taken off the head of the queue and processed.
While most operating systems support the basic POSIX standards, support for the extensions is somewhat more hit-and-miss. Most UNIX-like systems support the old System V IPC mechanisms, but support for their POSIX replacements is less common. OS X, for example, supports the newer POSIX Semaphores and shared memory, but not message queues. Of course, new is a relative term. These APIs were originally standardized over a decade ago, in 1993.
UNIX standards tend to codify existing implementations, rather than proposing new ones. The standard way of communicating over a network on a modern UNIX system is to use Berkeley Sockets (now sometimes called POSIX Sockets), an API that originated on 4.4BSD. For many years, System V IPC was the standard way of communicating between local processes, although there are now POSIX APIs that supersede it. The POSIX IPC mechanisms are semantically very similar to their System V counterparts, however, and making a platform that supports one support the other isn’t a difficult undertaking.
Although certification is no longer essential for a UNIX-like system to be taken seriously, there is still a significant benefit to the existence of standards. It’s a lot easier to write code that conforms to the specification, and then apply platform-specific patches for non-compliant systems, than to navigate the maze of nonstandard APIs. Eventually the patches can usually be removed, since most systems still aim toward compliance even when they sometimes fail to meet it.