|
Introduction
History
Structure and Contents
The 1170 Initiative
Platform Vendors Supporting the Single UNIX Specification
ISVs and User Organizations Supporting the Common API Specification
The Single UNIX Specification
System Interfaces and Headers (XSH)
Corrigenda
 Introduction
Many names have been applied to the work that has culminated in the Single UNIX
Specification and its attendant X/Open UNIX brand. It began as the Common API
Specification, became Spec 1170, and is now the Single UNIX Specification published in a
number of X/Open Common Applications Environment (CAE) volumes.
This paper briefly describes the history of Spec 1170, and its journey to becoming the
Single UNIX Specification, along with the organization of that specification.
History
Previously the UNIX operating system has been a product with four elements (Figure 1); the
specification (e.g. SVID) , the technology (e.g. SVR4), the registered trade mark (UNIX),
and the product (e.g. UNIXWare).
Figure 1
With the Single UNIX Specification, there is now a single, open, consensus specification
that defines a product. There is also a mark, or brand, that is used to identify those
products that conform to the Single UNIX specification. Both the specification and the
trade mark are now managed and held in trust for the industry by X/Open Company.
There will be many competing products, all implemented against the Single UNIX
Specification, ensuring competition and vendor choice. There will be a limited number of
technology suppliers, which vendors can license and build there own product, all of them
implementing the Single UNIX Specification. . Buyers can expect each of these products to
carry the X/open UNIX brand as an guarantee of conformance to the specification and that
the vendor stands behind a quality product.
UNIX is now no longer just the operating system product from AT&T (later, Novell),
documented by the System V Interface Definition (SVID), controlled and licensed from a
single point. Neither is it a collection of slightly different products from different
vendors, each extended in slightly different ways. The UNIX specification has been
separated from its licensed source-code product, and "UNIX'' has become a single
stable specification to be used to develop portable applications that run on systems
conforming to the Single UNIX Specification
Structure and Contents
The Single UNIX Specification is a collection of documents that are part of the X/Open
Common Applications Environment (CAE), and include:
A UNIX 95 branded product is built from a number of components (in X/Open language) and
includes:
- XPG4 Internationalized System Calls and Libraries (Extended), covering POSIX.1 and
POSIX.2 callable interfaces, the ISO C library and Multibyte Support Extension addendum,
the Single UNIX Specification extension including STREAMS, the Shared Memory calls,
application internationalization interfaces, and a wealth of other application interfaces.
- XPG4 Commands and Utilities V2, covering the POSIX.2 Shell and Utilities, and a large
number of additional commands and development utilities.
- XPG4 C Language
- XPG4 Sockets
- XPG4 Transport Interfaces (XTI)
- XPG4 Internationalized Terminal Interfaces including the new extensions to support color
and multibyte characters.
The Single UNIX Specification is supported by the X/Open UNIX brand, which in turn is
supported by a verification program. The X/Open brand provides the guarantee that products
adhere to the relevant X/Open specification. Systems that provide the Single UNIX
Specification interfaces can be X/Open UNIX branded as proof to the marketplace. The
Single UNIX Specification is the programmer's reference to the portability environment
provided on X/Open UNIX branded systems.
It is important for application developers to realize that in committing to the brand, the
vendor is obligating themselves to conform. X/Open conformance verification suites are
vendors' ways of measuring their implementation against the specification, providing a
guarantee that they have implemented the specification correctly.
And the X/Open brand commitment goes even deeper than this. It is a promise by the vendor
to conform to the specification, not to the test suite. If a user of a branded system
discovers an interface that does not behave according to the specification, regardless of
whether or not a test case in the verification suite passed in this area, the vendor is
obliged to correct the defect within explicit time frames.
The base is now in place to better support portable applications development by:
- Providing a rich set of interfaces that cover a broad range of "historical UNIX
systems" practice, simplifying the porting of existing applications, and protecting
current application development investments.
- Providing a stable specification against which to write applications that will be
portable to many platforms, and a stable methodology to evolve the specification in a
manner that is not under the control of any single vendor or vendor consortium.
- Ensuring that the portability model embodied in the specifications is based as much as
possible on standards.
- Supporting the specification with an X/Open branding program to provide both halves of
the portability formula, where application developers can write source code to the
specification, and purchase products branded to the specification with the confidence that
the application will port in a very straightforward manner.
The Spec 1170 Initiative
The Common API Specification project started when several vendors (Sun Microsystems, IBM,
Hewlett-Packard, Novell/USL and OSF) organized together to provide a single unified
specification of the UNIX system services. By implementing a single common definition of
the UNIX system services, third-party independent software vendors (ISVs) would be able to
more easily deliver strategic applications on all of these vendors' platforms at once.
The focus of this initiative was to deliver the core application interfaces used by
current programs. The economic driver that initiated the project was to ease the porting
of existing successful applications. While the work was led by a central group of vendors,
it received widespread support within the industry.
Platform Vendors Supporting the Single UNIX
Specification:1
Acer; Amdahl; Apple; AT&T GIS; Bull; Convex; Cray; Data General; Compaq; Encore; 88
Open; Fuji Xerox; Fujitsu Ossi; Hal; Hewlett-Packard; Hitachi; IBM; ICL; Matsushita; Mips
ABI; Mitsubishi; Motorola; NEC; Novell/USL; Oki; Olivetti; OSF; PowerOpen; Precision RISC;
Pyramid; SCO; Sequent; Sequoia; Sharp; Siemens-Nixdorf; Silicon Graphics; Sony; Sparc
International; Stratus; Sun Microsystems; Tadpole; Tandem;
Thompson/Cetia; Toshiba; Unisys; Wang Labs.
ISVs and User Organizations Supporting the Common API
Specification:
AutoDesk; Banyan; Bellcore; Bentley; Cadence; Cadre; Chorus; Computer Associates; DHL; EDS
Unigraphics; Frame Tech; Informix; Island Software; Lachman Tech; Locus; Lotus;
McDonald's; Mentor; Oracle; Pencom Systems; SDRC; Software AG; Shell Oil; Veritas;
Wal-Mart; WordPerfect.
A two-pronged approach was used to develop the Common API Specification. First, a set of
formal industry specifications was chosen to form the overall base for the work. This
would provide stability, vendor neutrality, and lay a well charted course for future
application development, taking advantage of the careful work that has gone into
developing these specifications. It would also preserve the portability of existing
applications already developed to these core models.
X/Open Company's XPG4 Base was chosen as the stable functional base from which to start.
XPG4 Base supports the POSIX.1 system interface and the ANSI/ISO C standards at its core.
It provides a rich set of 174 commands and utilities.
Many UNIX systems already conform to this specification. To this base was added the
traditional UNIX System V Interface Definition, (SVID) Edition 3, Level 1 calls, and the
OSF Application Environment Specification Full Use interface definitions. This represented
the stable central core of the latter two specifications.
The second part of the approach was to incorporate interfaces that are acknowledged common
practice but have not yet been incorporated into any formal specification or standard. The
intent was to ensure existing applications running on UNIX systems would port with
relative ease to a platform supporting the Common API Specification. A survey of real
world applications was used to determine what additional interfaces would be required in
the specification.
Fifty successful application packages were chosen to be analyzed using the following
criteria:
- Ranked in International Data Corp's. 1992, 'Survey of Leading UNIX Applications',
- The application's domain of applicability was checked to ensure that no single
application type (for example, databases) was overly represented,
- The application had to be available for analysis either as source code, or as a shared
or dynamic linked library.
From the group of fifty, the top ten were selected carefully, ensuring that no more
than two representative application packages in a particular problem space were chosen.
The ten chosen applications were:
AutoCAD; Cadence; FrameMaker; Informix; Island Write/Paint; Lotus 1-2-3; SAS (4GL);
Sybase; Teamwork; WordPerfect
APIs used by the applications that were not part of the base specifications were analyzed:
- If an API was used by any of the top ten applications, it was considered for inclusion.
- If an API was not used by one of the top ten, but was used by any three of the remaining
40 applications, it was considered for inclusion.
- While the investigation of these 50 applications was representative of large complex
applications, it still was not considered as a broad enough survey, so an additional 3500
modules were scanned. If an API was used at least seven times in modules that came from at
least two platforms (to screen out vendor specific libraries), then the interface was
considered for inclusion.
The goal was to ensure that APIs in common use were included, even if they were not in
the formal specifications that made up the base. Making the Common API Specification a
superset of existing base specifications ensured any existing applications should work
unmodified. The sponsors of the work considered pruning the Common API Specification of
interfaces from the base specifications that were not found to be in common use in the
application survey.
This idea was rejected for two reasons. While some of the interfaces in the base
specifications are not yet considered common practice, their inclusion in the overall
specification meant there existed clear sign-posts for future applications development
work. As well, it was recognized that the applications chosen for the survey were still
only a representative sample, and that many other applications not surveyed may use these
interfaces.
When the survey was complete, there were 130 interfaces that did not already appear in the
base specification. These interfaces seem to be predominantly Berkeley UNIX calls that had
never been covered in XPG4 Base, the SVID, or the AES, but did represent common practice
in UNIX system applications developed originally on BSD-derived platforms. Such things as
sockets and the 4.3BSD memory management calls were commonly used in many applications.
The resulting Common API Specification was impressive in its coverage. The top ten
applications surveyed were completely covered. Of the remaining 40 application packages,
the next 25 were within 5% of complete coverage. The software vendors involved all
acknowledged that it would be fairly straightforward for them to modify the 5% of the
application to conform fully to the specification.
There were 1170 interfaces in the complete specification when the work was done (926
programming interfaces, 70 headers, 174 commands and utilities), and the name of Spec 1170
was born.
Because of the breadth and origins of the specification, duplication of functionality
existed. There were similar interfaces for doing the same thing in such areas as memory
management (bcopy versus memmove) and creating temporary filenames (tmpnam versus mktemp).
This duplication was allowed as it would increase the number of existing applications that
would be portable in the new model. At the same time, certain functions have been
identified as the recommended practice for future development. There are cases where the
duplicated functionality cannot co-exist in the same application (for example, conflicting
signals models), and it is important to ensure that the is correctly configured if the
expected behavior is to be observed.
In December 1993, Spec 1170 was delivered to X/Open for fast-track processing into a
proper industry supported specification. This work progressed through 1994 and culminated
in the publication of the Spec 1170 work as the Single UNIX Specification in October 1994.
There are now more than 1170 interfaces in the specification as the review process shaped
the document accordingly. (The new internationalized curses specification contributed a
large number of interfaces.)
The Single UNIX Specification documents are part of the X/Open CAE (Common Applications
Environment) document set.
The Single UNIX Specification
Five X/Open CAE documents make up the Single UNIX Specification. These are:
- System Interface Definitions, Issue 4,
Version 2 (XBD)
The XBD document outlines the common definitions used by both the System Interfaces and
Headers, and the Commands and Utilities documents. Such items as locales and regular
expression grammars appear here, along with a large glossary defining common terms and
concepts.
- System Interfaces and Headers, Issue 4, Version
2 (XSH)
The XSH document describes all of the programming interfaces and headers available in the
Single UNIX Specification with the exception of the networking and terminal interfaces
(contained in their own documents). The front section introduces general concerns with
respect to usage guidelines, the compilation environment, error numbers, types, standard
streams and STREAMS. The rest of the document is the reference pages describing each
interface (in alphabetical order) and its use, and each header and its contents.
- Commands and Utilities, Issue 4, Version 2 (XCU)
The XCU document describes all of the commands and utilities available in the Single UNIX
Specification. The first section describes the syntax and functionality of the shell in
depth. The rest of the document is the reference pages describing each command and utility
(in alphabetic order) and its use.
- Networking Services, Issue 4
Three sets of networking services are defined in the Single UNIX Specification, X/Open
Transport Interface (XTI), XPG4 Sockets, and IP Address Resolution interfaces. These
services are described in the Networking Services document, along with appendices
containing useful additional protocol information and examples.
- X/Open Curses, Issue 4
The X/Open Curses interfaces are described in this document. It is an upwardly compatible
version of X/Open Curses, Version 3, extended to support internationalization, enhanced
character sets, and different writing directions.
The System Interfaces and Headers (XSH)
System Interfaces and Headers specification contains the base interfaces and several
"feature" groups. Interfaces that are part of a feature group have a feature
group specific label that appears in the header of the interface's reference page.
XSH (System Interfaces and Headers) contains the following feature groups:
- POSIX.2 C-language binding covering regular expression matching, word expansion, and
filename matching. The label POSIX.2 CLB appears in the header of each of these function's
reference page.
- Single UNIX Specification Extension covering all the functions that have been added to
XPG4 to create the Single UNIX Specification. The label SINGLE UNIX SPECIFICATION appears
in the header of each of these function's reference page.
- Shared Memory covering the SVID 3 kernel extension calls to manage shared memory. The
label SHARED MEM appears in the header of each of these function's reference page.
- Enhanced Internationalization adding functions that are not yet in wide use for
internationalizing applications, but will hopefully provide future direction and a
converging path for functionality of this type. The label ENHANCED I18N appears in the
header of each of these function's reference page.
- Encryption covering the functions crypt, encrypt, and setkey. The label CRYPT appears in
the header of each of these function's reference page. Anything that does not fall into
the feature groups listed above is considered to be base functionality, and marked with
the label BASE in the reference page heading.
XPG4 Base did not require all of the feature groups for conforming implementations.
Only the base interfaces were mandatory. To conform to Single UNIX Specification, an
implementation will need to support all of the feature groups with the exception of the
encryption interfaces. (There are U.S. government export restrictions on this technology
that may disallow some vendors from shipping it.)
The Commands and Utilities (XCU) specification describes all of the utilities required in
the environment. Some of these utilities do not need to be present, being contained in
``packages'' that need not be implemented.
- DEVELOPMENT utilities are those required in a software development environment.
- FORTRAN utilities are required in a FORTRAN-77 development environment, and essentially
consists of the compiler, fort77.
- A number of utilities are considered to be "possibly insupportable", and need
not be implemented. These include such commands as lpstat and uulog.
The only real effect that the Single UNIX Specification had on the XCU
(Commands and Utilities) document from Issue 4, was to modify the cc and c89 C compiler
commands.
A programmer developing applications on an Single UNIX Specification system has at their
disposal all of the functions, commands and utilities described in the Single UNIX
Specification document set. This functional superset of consensus-based specifications and
historical practice also creates a straightforward environment for porting existing
applications running on UNIX systems.
Products that implement Single UNIX Specification and qualify for the X/Open UNIX brand
will compile and run applications built or ported according to this model.
***Edited from "Go Solo -
How to Implement and Utilize the Single UNIX Specification"; published by X/Open
and Prentice Hall PTR.
Information about this, and other X/Open publications may be obtained from any X/Open
office or by sending e-mail to: XoPubs@xopen.org
X/Open is a registered trade mark, and the "X" device is a trade mark of X/Open
Company Limited. UNIX is a registered trade mark in the United States and other countries,
licensed exclusively through X/Open Company Limited
Footnote 1:
This is a list of vendors who have expressed support for the
specification and does not constitute any endorsement by The
Open Group of the company or their products.
|
