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.

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.

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.

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.

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.

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.