UNIX System V Release 4 (SVR4)

The UNIX operating system was developed by Ritchie and Thompson at Bell Laboratories in the early 1970s. From 1977 to 1982, Bell Laboratories combined several variants of the UNIX system devised by American Telephone and Telegraph (AT&T), into a single system, known commercially as UNIX System III. Bell Laboratories later added several features to UNIX System III, calling the new product UNIX System V, and AT&T announced official support for System V in January 1983.

UNIX System V Release 4 (SVR4), the result of a cooperative venture entered into by Sun Microsystems and AT&T, was announced in November of 1989. SVR4 is a synthesis of the best functionality of AT&T's UNIX System V Release 3, Berkeley Software Distribution 4.3, Sun's SunOS releases and Microsoft's XENIX^(R). SVR4 provides the notions of a consistent Application Programming Interface (API) and a single Application Binary Interface (ABI) for each hardware platform. It offers scalability that allows users, depending on their needs, to move to larger or smaller machines while still using the same environment.

Application Binary Interface

The System V Application Binary Interface (ABI) defines a standard binary interface for compiled applications on systems that implement UNIX System V Release 4 or other operating systems that comply with the System V Interface Definition, Third Edition.¹

The ABI defines a binary interface for application programs that are compiled and packaged for System V implementations on different hardware architectures. Because a binary specification must include information particular to the computer processor architecture for which it is intended, it is not possible for a single document to specify the interface for all possible System V implementations. Therefore, the System V ABI is a family of specifications.

The System V ABI is composed of two basic parts: a generic part that is a source-level interface which describes those aspects that remain constant across all hardware implementations of System V, and a processor-specific part that provides a complete binary interface for specific CPU architectures. Together, the generic ABI and the processor-specific supplement for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.

Software that is ABI-compliant for a particular architecture runs unchanged in its binary form on any ABI-compliant machine of that architecture. Also, this software is source compatible with any other ABI-compliant system and runs unchanged after compilation on the target system.

SunOS Compliance With the ABI Specification

The SunOS operating system is compliant with both the generic ABI as defined in the AT&T System V Application Binary Interface: Generic ABI (ISBN 0-13- 100439-5) and the processor-specific part of the ABI as defined in the Application Binary Interface SPARC Processor Supplement (ISBN 0-13-104696-9) or the Application Binary Interface Intel 386 Processor Supplement (ISBN 0-13-104670- 5) , depending on the underlying hardware architecture.

ABI Specifications and Related Publications

The following documents comprise the ABI specification for the SunOS operating system:

• AT&T System V Application Binary Interface: Generic ABI
• AT&T System V Application Binary Interface SPARC Processor Supplement
• AT&T System V Application Binary Interface Intel 386 Processor Supplement

The documents listed above refer to other specifications and standards, some of which are identified below:

• The System V Interface Definition, Third Edition
• The IEEE Std. 1003.1-1990 Portable Operating System Interface (POSIX.1)-Part 1: System Application Program Interface [C Language]
• The IEEE Std 754-1985 Floating Point Processing Specification
• The X/Open Portability Guide, Issue 3
• The X/Open Portability Guide, Issue 4
• The ANSI Std. X3.159-1989 C Language Specification
• The X11 X Window System Graphical User Interface Specification
• The SPARC Architecture Manual, Version 8
• i486 MICROPROCESSOR Programmer's Reference Manual
• 80386 Programmer's Reference Manual
• 80387 Programmer's Reference Manual

These specifications and standards are discussed elsewhere in this manual.

System V Interface Definition (SVID)

The System V Interface Definition (SVID), first published by AT&T in 1985, represented a major standards initiative. AT&T was a prominent member of /usr/group and the influence of /usr/group is evident in the SVID.

The SVID specifies an operating system environment that allows users to create applications software that is independent of any particular computer hardware. It specifies the operating system components available to both end-users and application programs and defines the functionality, but not the implementation, of components. The SVID specifies the source code interfaces of each operating system component, as well as the runtime behavior seen by an application program or an end-user.

The SVID is compliant with IEEE Std. 1003.1-1990 (POSIX.1) and will continue to evolve towards compliance with other appropriate industry standards as they are approved.

An application using only components defined in the SVID will be compatible with and portable to any computer that supports the SVID. The SVID is organized into a Base System Definition with a series of Extension Definitions. The Base System Definition specifies the components that all System V operating systems must provide. The extensions to the Base System are not required.

All conforming systems must support the source-code interfaces and runtime behavior of all the components of the Base System. A system may conform to none or some extensions. All of the required components must be present for a system to meet the requirements of the extension.

SunOS Compliance With SVID3

The SunOS operating system is compatible with the Base System of the System V Interface Definition, Third Edition. Writing to SVID3 ensures that your applications will be source compatible. Applications that are SVID3 compliant will compile and run on the SunOS operating system.

The SunOS operating system meets all SVID requirements for the following: Base System, Basic Utilities, Kernel, Network Services, Terminal Interface Extensions, Advanced Utilities, and Software Development Extensions.

SVID Specification

System V Interface Definition, Third Edition, Volumes 1-4, AT&T

Device Driver Interface/Driver-Kernel Interface (DDI/DKI)

The Solaris 2.4 DDI, Device Driver Interface and DKI, Driver-Kernel Interface, comprise a set of standard interfaces for device drivers. SVR4 requires that each vendor provide and document a hardware-specific DDI. The Solaris 2.4 DDI is a set of device driver interfaces defined by SunSoft that meets that requirement. The DKI is intrinsic to System V, Release 4 (SVR4). The DKI is divided into two parts: the set of interfaces called DDI/DKI that will continue to be supported in future release of System V and the set of interfaces called DKI only that may not be supported in the future.

SunOS Compliance with the Specification

The SunOS implementation of the DDI/DKI and DKI-only interfaces for device drivers is compliant with the specification described in the UNIX System V Release 4 Device Driver Interface/Driver-Kernel Interface (DDI/DKI) Reference Manual.

DDI/DKI and DKI Specifications and Related Publications

The following manuals describe the DDI and DKI interfaces.

• DDI interfaces are described in the Writing Device Drivers.
• For detailed information on how to write device drivers to these interfaces, see Writing Device Drivers.
• The DKI interfaces are specified in The UNIX System V Release 4 Device Driver Interface/Driver-Kernel Interface (DDI/DKI) Reference Manual.

Data Link Provider Interface (DLPI)

The SVR4 STREAMS-based Data Link Provider Interface (DLPI) is a kernel-level interface that supports the services of the Data Link Layer for both connection-mode and connectionless-mode services. The specification, A STREAMS-Based Data Link Provider Interface, Version 2, designates the format for a set of messages between the data link provider and the data link user. The DLPI header, <dlpi.h>, is part of SVR4 and is included with this SunOS release.

DLPI enables a data link service user to access and use any of a variety of conforming data link service providers without special knowledge of the provider's protocol. Specifically, the interface is intended to support X.25, LAPB, BX.25 level 2, SDLC, ISDN, LAPD, Ethernet^(TM), CSMA/CD, token ring, token bus, Bisync, FDDI, and other data link protocols.

SunOS Compliance With DLPI

The SunOS operating system is compliant with the DLPI specification, Version 2, 1991, revised by the Open Systems Interconnection Working Group (OSIWG), a working group within UNIX International (UI). The version 2 <dlpi.h> header is delivered with SunOS.

DLPI Specification

The following specification is based on the DLPI specification and includes version 2 of the <dlpi.h> header.

A STREAMS-Based Data Link Provider Interface -Version 2, UNIX International

Transport Provider Interface

The Transport Provider Interface (TPI) consists of the kernel components of the Transport Level Interface. TPI specifies the transport service interface in terms of STREAMS messages. The TPI structure is described in the TPI specification for System V Release 4.0.

SunOS Compliance with TPI

The SunOS operating system is entirely compliant with the Transport Provider Interface and intends to remain compliant as TPI continues to evolve. The X/Open Transport Interface (XTI), which was based on and evolved from the Transport Level Interface (TLI), will influence the evolution of TPI. (It is the intention of SunSoft to be compliant with XTI in the near future.)

OPEN LOOK

The OPEN LOOK Graphical User Interface (GUI) was developed by Sun Microsystems in partnership with AT&T. In July 1988, Sun and AT&T distributed more than 1000 copies of the OPEN LOOK specification draft to UNIX system users for review. The comments received from the industry were used to create the final version of the OPEN LOOK specification.

OPEN LOOK is a specification for a user interface within a window environment based on the pioneering work done on graphical user interfaces at Xerox PARC in the 1970s. A graphical user interface standard describes how applications appear on the screen and their behavior in relation to the user. The OPEN LOOK GUI was designed to provide a simple, consistent and efficient interface.

The OPEN LOOK GUI uses windows and menus with common graphic symbols instead of typed system commands to provide an intuitive environment with a consistent screen layout that can be used across various platforms and operating systems. OPEN LOOK has become the standard look and feel for bit-mapped displays under UNIX System V Release 4.

OPEN LOOK compliance has two components: toolkit compliance and environment compliance. There are three types of software that fit within these two categories: toolkits, applications, and environments. Because most applications are built using toolkits, they usually assume the level of

compliance characteristic of the toolkit used to create them. Toolkits, applications and environments as understood in OPEN LOOK parlance are described below:

• Toolkits. A toolkit is a set of programming components used to build OPEN LOOK GUI applications. It consists of a high-level programming interface that provides the elements required to build a user interface. Toolkits provide a set of routines that implement the various interface elements as defined by the specification. The application developer uses the routines provided by the toolkit to create and position the interface elements as needed. The toolkit makes application development easier and ensures that the user interface remains consistent by using the same building blocks. Toolkits help developers create user-interface prototypes by providing a simple and easy-to-use programming interface.
• Applications. An application is a program or set of programs designed to perform a specific task. Applications are built using a user-interface toolkit or other developer tools. While it is possible for the application developer to implement the OPEN LOOK User Interface (UI) without a toolkit, the usual approach is to use a toolkit written for a specific windowing platform. Together, applications and their use of the toolkit define the way programs look and feel to users.
• Environments. An environment is a program or set of programs that effect the design and operation of an OPEN LOOK GUI implementation. An OPEN LOOK compliant environment consists of an OPEN LOOK User Interface (UI) window manager, file manager, workspace properties window and other utility programs.

To guarantee an OPEN LOOK GUI-compliant application, the developer must write the application with an OPEN LOOK GUI compliant toolkit and run the application in a compliant OPEN LOOK GUI environment.

Trademark licensing is available for the following three levels of OPEN LOOK certification:

• Level 1: This level contains all the essential components of a complete user interface. It delineates the minimum features required to certify an implementation as OPEN LOOK GUI compliant. Among the features covered in Level 1 are window types and properties, menu formats, and mouse and keyboard.

• Level 2: Compliance with Level 2 requires the presence of all of the features comprising Level 1 and additional features mandatory for Level 2. These include abbreviated buttons, nonstandard window types, scrollbars and icon settings for color implementations.
• Level 3: Level 3 is a superset of Level 2. This level requires that an application contain certain specialized features and a process manager for extending the functionality of the OPEN LOOK GUI.

For a complete list of the required features for each level, see "Appendix A, Certification" in the OPEN LOOK Graphical User Interface Functional Specification.

Solaris Compliance With OPEN LOOK

The Sun GUI is a superset of OPEN LOOK and includes Sun value-added features. In moving toward full support of the Sun GUI, all required OPEN LOOK features will be supported by Sun at all levels.

OpenWindows implements the OPEN LOOK GUI standard. OpenWindows implements both the 2-D and 3-D OPEN LOOK GUI standard.

OpenWindows is a component of Solaris 2.4. The OPEN LOOK components indicated below implement the OPEN LOOK GUI.

• OPEN LOOK Intrinsics Toolkit (OLIT): The OPEN LOOK Intrinsics Toolkit was created by building a set of widgets for the X Toolkit Intrinsics (Xt) that conform to the OPEN LOOK GUI specification. The OPEN LOOK Intrinsics Toolkit API matches the X11 Release 4 Xt Intrinsics programming interface. For Solaris 2.4, OLIT is Level 2 compliant with certain exceptions.
• XView 3.3 Toolkit (X11-based Visual/Integrated Environment for Workstations): XView is an X11 toolkit for building applications. The XView API is is based upon Xlib, the lowest level of programming available to the X window system programmer. XView implements the OPEN LOOK GUI. For Solaris 2.4, XView is Level 2 compliant with certain exceptions.
• OpenWindows DeskSet: OpenWindows includes a set of OPEN LOOK applications that are collectively known as the DeskSet environment. All of the DeskSet applications support the OPEN LOOK model of dragging and dropping objects. The File Manager DeskSet tool is required by the OPEN

LOOK standard for Level 2 compliance; it represents files (including directories and applications) with glyphs. The OpenWindows DeskSet File Manager program fulfills the Level 2 compliance requirement.

OPEN LOOK Specification and Related References

The specifications listed below address OPEN LOOK. They are published by Addison-Wesley.

• OPEN LOOK Graphical User Interface Functional Specification (ISBN 0-201- 52365-5)
• OPEN LOOK Graphical User Interface Application Style Guidelines (ISBN 0-201- 52364-7)

Licensing the OPEN LOOK Trademark

OPEN LOOK is a trademark of UNIX System Laboratories (USL), a wholly owned subsidiary of Novell, Inc. The Trademark License Agreement is the contract entered into by OPEN LOOK trademark applicants and USL. As a developer of OPEN LOOK applications, you may wish to license the OPEN LOOK trademark. USL has developed a trademark agreement as a formality to protect the trademark. To obtain the use of the OPEN LOOK trademark, follow the recommendations described below; no payment is required.

• For information on how to develop an OPEN LOOK application, refer to the OPEN LOOK Graphical User Interface Functional Specification that is delivered with OpenWindows.
• To receive your "OPEN LOOK Graphical User Interface Trademark License Agreement" forms, call 1 (800) 828-UNIX. If you are a UNIX system licensee, ask for your account representative. Otherwise, a sales associate will handle your request. After an authorized representative of your company signs the agreement, send it to USL at the following address:

  UNIX System Laboratories Attention: Sales Associate (or the name of your account representative) PO Box 25000

  Greensboro, NC 27420-5000.

  Within 30 days, USL will send you an executed agreement authorizing you to use the OPEN LOOK trademark on your software.