SYSTEM V
APPLICATION BINARY INTERFACE

Edition 4.1

Copyright  1990−1996 The Santa Cruz Operation, Inc. All rights reserved.
Copyright  1990−1992 AT&T. All rights reserved.
No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor translated
into any human or computer language, in any form or by any means, electronic, mechanical, magnetic,
optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner,
The Santa Cruz Operation, Inc., 400 Encinal Street, Santa Cruz, California, 95060, USA. Copyright
infringement is a serious matter under the United States and foreign Copyright Laws.
Information in this document is subject to change without notice and does not represent a commitment
on the part of The Santa Cruz Operation, Inc.
SCO, the SCO logo, The Santa Cruz Operation, and UnixWare are trademarks or registered trademarksof The Santa Cruz Operation, Inc. in the USA and other countries. UNIX is a registered trademark in
the USA and other countries, licensed exclusively through X/Open Company Limited. NeWS is a
registered trademark of Sun Microsystems, Inc. X11 and X Window System are trademarks of
Massachusetts Institute of Technology All other brand and product names are or may be trademarksof, and are used to identify products or services of, their respective owners.
SCO UnixWare is commercial computer software and, together with any related documentation, is
subject to the restrictions on US Government use as set forth below. If this procurement is for a DOD
agency, the following DFAR Restricted Rights Legend applies:
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the Government is subject torestrictions as set forth in subparagraph (c)(1)(ii) of Rights in Technical Data and Computer Software
Clause at DFARS 252.227-7013. Contractor/Manufacturer is The Santa Cruz Operation, Inc., 400 EncinalStreet, Santa Cruz, CA 95060.

If this procurement is for a civilian government agency, this FAR Restricted Rights Legend applies:
RESTRICTED RIGHTS LEGEND: This computer software is submitted with restricted rights under
Government Contract No. _________ (and Subcontract No. ________, if appropriate). It may not be
used, reproduced, or disclosed by the Government except as provided in paragraph (g)(3)(i) of FAR
Clause 52.227-14 alt III or as otherwise expressly stated in the contract. Contractor/Manufacturer is
The Santa Cruz Operation, Inc., 400 Encinal Street, Santa Cruz, CA 95060.

If any copyrighted software accompanies this publication, it is licensed to the End User only for use instrict accordance with the End User License Agreement, which should be read carefully before
commencing use of the software.
ACKNOWLEDGEMENTS"We acknowledge the contributions of the 88OPEN Consortium Ltd., portions of whose System V ABIImplementation Guide for the M88000 Processor and the System V ABI M88000 Processor Networking
Supplement have been incorporated in this section of the ABI with permission."

DRAFT COPY
March 18, 1997
File: copyright386:adm.book:sum
Page: 2

Contents

Table of Contents
INTRODUCTIONSOFTWARE INSTALLATION
LOW-LEVEL SYSTEM INFORMATIONOBJECT FILESPROGRAM LOADING AND DYNAMIC LINKING
LIBRARIESFORMATS AND PROTOCOLSSYSTEM COMMANDSEXECUTION ENVIRONMENT
WINDOWING AND TERMINAL INTERFACESDEVELOPMENT ENVIRONMENTS FOR AN ABI SYSTEMNETWORKING
Index

1

INTRODUCTION

2SOFTWARE INSTALLATION

System V Application Binary Interface
Foundations and Structure of the ABIHow to Use the System V ABIDefinitions of Terms

Software Installation and Packaging
File Formats
File Tree for Add-on Software
Commands That Install, Remove and Access Packages

Table of Contents

1-1
1-2
1-4
1-8

2-1
2-7
2-15
2-16

i

DRAFT COPY
March 18, 1997
File: MasterToc
386:adm.book:sum
Page: 3

3

LOW-LEVEL SYSTEM INFORMATION4OBJECT FILES

5PROGRAM LOADING AND DYNAMIC
LINKING

Introduction
Character Representations
Machine Interface (Processor-Specific)
Function Calling Sequence (Processor-Specific)
Operating System Interface (Processor-Specific)
Coding Examples (Processor-Specific)

3-1
3-2
3-3
3-4
3-5
3-6

Introduction
ELF Header
Sections
String Table
Symbol Table
Relocation

4-1
4-4
4-10
4-21
4-22
4-27

Introduction
Program Header
Program Loading (Processor-Specific)
Dynamic Linking

6

5-1
5-2
5-11
5-12

LIBRARIESIntroduction
C Library
Threads Library
Dynamic Linking Library
Network Services Library
Socket Library
Curses Library
X Window System Library
X11 Nonrectangular Window Shape Extension Library

ii

6-1
6-5
6-15
6-17
6-18
6-21
6-22
6-26
6-33

Table of Contents

DRAFT COPY
March 18, 1997
File: MasterToc
386:adm.book:sum
Page: 4

X Toolkit Intrinsics Library
Motif Libraries
System Data Interfaces

7

FORMATS AND PROTOCOLS8SYSTEM COMMANDS9EXECUTION ENVIRONMENT

10

WINDOWING AND TERMINAL INTERFACES

11

DEVELOPMENT ENVIRONMENTS FOR AN
ABI SYSTEM

Introduction
Archive File
Other Archive Formats
Terminfo Data Base
Formats and Protocols for Networking

Commands for Application Programs

Application Environment
File System Structure and Contents

The System V Window System
System V Window System Components

Development Environments

12

6-34
6-38
6-46

7-1
7-2
7-6
7-7
7-10

8-1

9-1
9-3

10-1
10-3

11-1

NETWORKING
Networking

12-1

Table of Contentsiii

DRAFT COPY
March 18, 1997
File: MasterToc
386:adm.book:sum
Page: 5Required STREAMS Devices and Modules
Required Interprocess Communication Support
Required Transport Layer Support
Required Transport Loopback Support
Optional Internet Transport Support

IN

12-2
12-3
12-4
12-7
12-8

Index
Index

IN-1

iv

Table of Contents

DRAFT COPY
March 18, 1997
File: MasterToc
386:adm.book:sum
Page: 6

Figures and Tables

Figure 2-1: Package File Tree Organization
Figure 2-2: Data Stream File Layout for Distribution Media
Figure 4-1: Object File Format
Figure 4-2: 32-Bit Data Types
Figure 4-3: ELF Header
Figure 4-4: e_ident[ ] Identification Indexes
Figure 4-5: Data Encoding ELFDATA2LSB
Figure 4-6: Data Encoding ELFDATA2MSB
Figure 4-7: Special Section Indexes
Figure 4-8: Section Header
Figure 4-9: Section Types, sh_type
Figure 4-10: Section Header Table Entry: Index 0
Figure 4-11: Section Attribute Flags, sh_flags
Figure 4-12: sh_link and sh_info Interpretation
Figure 4-13: Special Sections
Figure 4-14: String Table Indexes
Figure 4-15: Symbol Table Entry
Figure 4-16: Symbol Binding, ELF32_ST_BIND
Figure 4-17: Symbol Types, ELF32_ST_TYPE
Figure 4-18: Symbol Table Entry: Index 0
Figure 4-19: Relocation Entries
Figure 5-1: Program Header
Figure 5-2: Segment Types, p_type
Figure 5-3: Segment Flag Bits, p_flags
Figure 5-4: Segment Permissions
Figure 5-5: Text Segment
Figure 5-6: Data Segment
Figure 5-7: Note Information
Figure 5-8: Example Note Segment
Figure 5-9: Dynamic Structure
Figure 5-10: Dynamic Array Tags, d_tag
Figure 5-11: Symbol Hash Table
Figure 5-12: Hashing Function
Figure 5-13: Initialization Ordering Example
Figure 6-1: Shared Library Names

Table of Contents

2-2
2-4
4-1
4-3
4-4
4-7
4-9
4-9
4-10
4-12
4-13
4-15
4-16
4-17
4-17
4-21
4-22
4-23
4-24
4-26
4-27
5-2
5-3
5-6
5-6
5-7
5-7
5-8
5-9
5-15
5-15
5-21
5-22
5-25
6-3

v

DRAFT COPY
March 18, 1997
File: MasterToc
386:adm.book:sum
Page: 7

Figure 6-2: libc Contents, Names without Synonyms
Figure 6-3: libc Contents, Names with Synonyms
Figure 6-4: libc Contents from XSH4.2, Names with Synonyms
Figure 6-5: libc Contents, Internal Names without Synonyms
Figure 6-6: libc Contents, Additional Services
Figure 6-7: libc Contents, Global External Data Symbols
Figure 6-8: libthread Contents *, Part 1 of 2
Figure 6-9: libthread Contents *, Part 2 of 2
Figure 6-10: libdl Contents *Figure 6-11: libnsl Contents, Part 1 of 3
Figure 6-12: libnsl Contents *, Part 2 of 3
Figure 6-13: libnsl Contents, Part 3 of 3
Figure 6-14: libnsl Contents, Global External Data Symbols
Figure 6-15: libsocket Contents, Part 1 of 2
Figure 6-17: libsocket Contents, Part 2 of 2
Figure 6-18: libcurses Contents
Figure 6-19: libcurses Contents, Global External Data Symbols
Figure 6-20: libX Contents
Figure 6-21: libX Contents, Callback Function Names
Figure 6-22: libX Contents *, Global External Data Symbols
Figure 6-23: libXext Contents *Figure 6-24: libXt Contents
Figure 6-25: libXt Contents, Global External Data Symbols
Figure 6-26: libXm Contents *Figure 6-27: libXm Contents *, Global External Data Symbols
Figure 6-28: libMrm Contents *Figure 6-29: Minimum Sizes of Fundamental Data Objects
Figure 7-1: <ar.h>
Figure 7-2: Example String Table
Figure 7-3: Archive Word Encoding
Figure 7-4: Example Symbol Table
Figure 8-1: Commands required in an ABI Run-time Environment
Figure 8-2: XPG4.2 Commands required in an ABI Run-time Environment
Figure 8-3: Commands required in an ABI Run-time Environment for Motif *Figure 9-1: Required Devices in an ABI Run-time Environment
Figure 11-1: Required libm Functions
Figure 11-2: Required libcurses Functions
Figure 12-1: Required STREAMS Devices
Figure 12-2: Required STREAMS Modules
Figure 12-3: TLI-XTI Error Codes
Figure 12-4: t_look Events
Figure 12-5: XTI Flag Definitions
Figure 12-6: XTI Service Types
Figure 12-7: Flags to be used with t_alloc
Figure 12-8: XTI Application States

vi

6-5
6-6
6-8
6-9
6-11
6-12
6-15
6-16
6-17
6-18
6-18
6-19
6-20
6-21
6-21
6-22
6-25
6-27
6-32
6-32
6-33
6-35
6-37
6-39
6-44
6-45
6-47
7-2
7-4
7-4
7-5
8-1
8-2
8-3
9-4
11-4
11-5
12-2
12-2
12-4
12-4
12-5
12-5
12-5
12-5

Table of Contents

DRAFT COPY
March 18, 1997
File: MasterToc
386:adm.book:sum
Page: 8Figure 12-9: XTI values for t_info flags member
Figure 12-10: TCP Options
Figure 12-11: IP Options
Figure 12-12: TCP Options
Figure 12-13: UDP Options
Figure 12-14: IP Options
Figure 12-15: Data Structures

Table of Contents

12-6
12-10
12-10
12-11
12-11
12-12
12-13

vii

DRAFT COPY
March 18, 1997
File: MasterToc
386:adm.book:sum
Page: 9

1

INTRODUCTION

System V Application Binary Interface

1-1

Foundations and Structure of the ABI

1-2
1-2

Conformance Rule

How to Use the System V ABIBase and Optional Components of the ABI
Evolution of the ABI Specification

1-4
1-6
1-7

Definitions of Terms

1-8

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cchap1
386:adm.book:sum
Page: 10

System V Application Binary Interface
The System V Application Binary Interface, or ABI, defines a system interface forcompiled application programs and a minimal environment for support of installation scripts. Its purpose is to document a standard binary interface for application programs on systems that implement an operating system that complies with
the X/Open Common Application Environment Specification, Issue 4.2 and the System
V Interface Definition, Fourth Edition.
The ABI defines a binary interface for application programs that are compiled andpackaged for System V implementations on many different hardware architectures. Since a binary specification must include information specific 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, rather than a single one.
The System V ABI is composed of two basic parts: A generic part of thespecification describes those parts of the interface that remain constant across all
hardware implementations of System V, and a processor-specific part of thespecification describes the parts of the specification that are specific to a particular
processor architecture. 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.
This document is the generic ABI. It must be used in conjunction with a supplemental specification containing processor-specific information. Whenever a section of this specification must be supplemented by processor-specific information,
the text will reference the processor supplement. The processor supplement may
also contain additional information that is not referenced here.

System V Application Binary Interface

1-1

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 11E
X
X

Foundations and Structure of the ABIThe System V ABI is based on several reference documents. Because it is a binaryinterface, it includes the fundamental set of machine instructions for that processor to which the specification applies, and includes many other low-levelspecifications that may be strongly affected by the characteristics of a given
processor’s architecture. It also includes higher-level information about System V.
The interfaces specified here were drawn from existing standards for operating
systems, user interfaces, programming languages, and networking, including
those on the following list and others.
The architecture manual for the target system’s processor.
The System V Interface Definition, Fourth Edition.

M

The IEEE POSIX 1003.1-1990 standard operating system specification.
The X/Open Common Application Environment Specification (CAE), Issue 4.2.

X

The International Standard, ISO/IEC 9899:1990 (E), Programming Languages C, 12/15/90.

E

The X Window SystemTM, X Version 11, Release 5, graphical user interface
specification.

G

Conformance RuleNOTE

All interfaces in the X/Open CAE Specification, Issue 4.2 (excluding thosemarked Withdrawn) and certain interfaces in the System V Application Binary
Interface, Fourth Edition are contained in this document, the System V Application Binary Interface, Edition 4.1 (System V ABI 4.1). Note that all interfaces in
the System V ABI are conformant to XPG4.2. Those interfaces that were originally in the System V Application Binary Interface, Fourth Edition will also be
conformant to the System V Interface Definition, Fourth Edition in cases where
the SVID adds additional functionality over XPG4.2. In all cases where System
V Interface Definition, Fourth Edition functionality conflicts with X/Open CAE
Specification, Issue 4.2 functionality, X/Open CAE Specification, Issue 4.2 is followed. For this reason certain libraries presented in Chapter 6 and Chapter 8
will be divided into two tables. The first table presents interfaces which aregoverned by the specifications in the X/Open CAE Specification, Issue 4.2 andthe System V Interface Definition, Fourth Edition. The second tables presentsinterfaces which were not originally in the System V Application Binary Interface,
Fourth Edition and are therefore only governed by the specifications in the
X/Open CAE Specification, Issue 4.2.

1-2

X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

INTRODUCTION

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 12

The ABI is divided into sections dealing with specific portions of the interface.
Some sections include a large amount of detailed information, while others contain lists of interface components and pointers to other documents.
In general, this specification does not duplicate information that is available inother standards documents. For example, the ABI section that describes systemservice routines includes a list of the system routines supported in this interface,formal declarations of the data structures they use that are visible to application
programs, and a pointer to the X/Open CAE Specification, Issue 4.2 and the System V
Interface Definition, Fourth Edition for information about the syntax and semantics
of each call. Only those routines not described in System V Interface Definition,
Fourth Edition or elsewhere are described in the ABI.
Other sections of the ABI are written using this same model. The ABI identifies
operating system components it includes, provides whatever information about
those components that is not available elsewhere, and furnishes a reference toanother document for further information. Information referenced in this way is
as much a part of the ABI specification as is the information explicitly included
here.

Foundations and Structure of the ABI

1-3

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 13

M
M

How to Use the System V ABIThe complete System V ABI is composed of this generic ABI specification and the
supplemental processor-specific specification for a particular processor architecture. These two documents constitute a specification that should be used in conjunction with the publicly-available standards documents it references (some ofthese are listed above). The ABI enumerates the system components it includes,
but descriptions of those components may be included entirely in the ABI, partly
in the ABI and partly in other documents, or entirely in other reference documents.
Application programmers who wish to produce binary packages that will installand run on any System V-based computer should follow this procedure:
1 . Write programs using the X/Open CAE Specification, Issue 4.2 and the Level 1
source-level interfaces described in the System V Interface Definition, Fourth
Edition in the following sections. (See the Conformance Rule above.) Routines guaranteed to be present on all ABI-conforming systems as
dynamically-linkable resources are listed below.

X
X

BA_OS: All Level 1 routines are available as shared resources.

E

BA_LIB: All Level 1 routines are available as shared resources
except for the math routines which may be available as an ABIcompliant static archive (see Chapter 11):

E
E

acos
atan2
cosh
floor
j1
matherr
sqrt
yn

acosh
atanh
erf
fmod
jn
pow
tan

asin
cbrt
erfc
gamma
lgammaremainder
tanh

asinh
ceil
exp
hypot
log10
sin
y0

atan
cos
fabs
j0
log
sinh
y1

ABI-conforming applications should not use the encryption routines crypt(), encrypt(), or setkey(), and should not use theLevel 2 routines advance(), compile(), step(), drand48(),
erand48(), jrand48(), lcong48(), lrand48(), mrand48(),
nrand48(), seed48(), and srand48(), since these routines are
not required to be present on an ABI-conforming system.

1-4

INTRODUCTION

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 14*

KE_OS: All Level 1 routines in this section are guaranteed to bepresent as shared resources on an ABI-conforming system.

E

RS_LIB: All routines in this section are guaranteed to be present asshared resources on ABI-conforming systems that include networking facilities.
MT_LIB: All routines in this section are guaranteed to be present
as shared resources on ABI-conforming systems.

M

The routines listed in the ‘‘System Library’’ , ‘‘Threads Library’’ , ‘‘Network
Services Library’’ , and the ‘‘X Window System Library’’ (see: Chapter 6, 10)
must be accessed as dynamically-linked resources. Other routines may be
dynamically linked, or may be statically bound into the application from anarchive library.

E
E

2 . Use only the system utilities and environment information described in
Chapters 8 and 9 of the ABI.
3 . Compile programs so that the resulting executable programs use thespecified interface to all system routines and services, and have the format
described in the ABI specification. The commands available on a systemthat also supports an ABI development environment is defined in Chapter
11.
4 . Package the application in the format and on the media described in the
ABI, and install or create files only in the specified locations provided forthis purpose when the application is installed. The packaging tools available on a system that also supports an ABI development environment isdefined in Chapter 11.

E
E

E
E

The manufacturers of System V-based computer systems who wish to provide thesystem interface described in this specification must satisfy a complementary setof requirements:
1 . Their system must implement fully the architecture described in the
hardware manual for their target processor architecture.
2 . The system must be capable of executing compiled programs having theformat described in this specification.
3 . The system must provide libraries containing the routines specified by the
ABI, and must provide a dynamic linking mechanism that allows these routines to be attached to application programs at run time. All the systemroutines must behave as specified by the X/Open CAE Specification, Issue 4.2
and the System V Interface Definition, Fourth Edition (see the Conformance
Rule above).

How to Use the System V ABI

1-5

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 15XX

4 . The system’s map of virtual memory must conform to the requirements of
the ABI.
5 . The system’s low-level behavior with respect to function call linkage, system traps, signals, and other such activities must conform to the formats
documented in the ABI.
6 . The system’s compilation system, if present, must compile source code into
executable files having the formats and characteristics specified in the ABI.
7 . The system must provide all files and utilities specified as part of the ABI, in
the format defined here and in other referenced documents. All commands
and utilities must behave as documented in the X/Open CAE Specification,
Issue 4.2 and the System V Interface Definition, Fourth Edition (see the Conformance Rule above). The system must also provide all other components ofan application’s run-time environment that are included or referenced in
the ABI specification.
8 . The system must install packages using the formats and proceduredescribed in the ABI, and must be capable of accepting installable software
packages, either through physical media or through a network interface.

Base and Optional Components of the ABIThe ABI provides two levels of interface specification: Base and Optional. Basecomponents of the ABI are required to be present in all ABI-conforming systems.
Optional components may be absent on an ABI-conforming system, but, when
they are present, they must conform to the specification given in the ABI. All components of the ABI are to be considered Base components unless they are explicitly
described as Optional like the one that follows.
NOTE

THE FACILITIES AND INTERFACES DESCRIBED IN THIS SECTION ARE
OPTIONAL COMPONENTS OF THE System V Application Binary Interface.

This distinction is necessary because some ABI capabilities depend on the presenceof hardware or other facilities that may not be present, such as integral graphics
displays or network connections and hardware. The absence of such facilities
does not prevent a System V-based system from conforming with the ABI
specification, though it may prevent applications that need these facilities fromrunning on those systems.

1-6

INTRODUCTION

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 16XX

Evolution of the ABI Specification
The System V Application Binary Interface will evolve over time to address newtechnology and market requirements, and will be reissued at intervals of approximately three years. Each new edition of the specification is likely to contain extensions and additions that will increase the potential capabilities of applications thatare written to conform to the ABI.
The System V Application Binary Interface, Edition 4.1 includes certain elements
marked as DEPRECATED. An interface, header, or command has been marked as
DEPRECATED if it is specified as To Be Withdrawn in the X/Open CAE
Specification, Issue 4.2, or if it is not present in the X/Open CAE Specification, Issue
4.2 and is designated as Level 2 in the System V Interface Definition, Fourth Edition.
Long term support for such functions can not be presumed.

How to Use the System V ABI

1-7

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 17

X
X
X
X
X

Definitions of Terms
The following terms are used throughout this document.
ABI or System V ABI: Refers to the specification that is the subject of thisdocument, the System V Application Binary Interface. The System V ABI for aparticular system is composed of the generic ABI and the Processor-specificSupplement for the processor used in the system.
generic System V ABI or generic ABI: Consists of the processor-independent
portions of the System V Application Binary Interface.
Processor-specific ABI or Processor-specific Supplement: Consists of those portions of the System V ABI that are specific to a particular processor architecture. Together, the generic ABI and the appropriate Processor-specific Supplement comprise the System V ABI for systems employing a particular processor architecture.
ABI-conforming system: A computer system that provides the binary system interface for application programs described in the System V ABI.
ABI-conforming program: A program written to include only the systemroutines, commands, and other resources included in the ABI, and a program compiled into an executable file that has the formats and characteristics specified for such files in the ABI, and a program whose behavior complies with the rules given in the ABI.
ABI-nonconforming program: A program which has been written to
include system routines, commands, or other resources not included in the
ABI, or a program which has been compiled into a format different fromthose specified in the ABI, or a program which does not behave as specified
in the ABI.
undefined behavior: Behavior that may vary from instance to instance or
may change at some time in the future. Some undesirable programming
practices are marked in the ABI as yielding undefined behavior.
unspecified property: A property of an entity that is not explicitly included
or referenced in this specification, and may change at some time in the
future. In general, it is not good practice to make a program depend on anunspecified property.

1-8

INTRODUCTION

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 18

NOTE

Diffmarkings have been retained in the text of this book to indicate in whichrevisions of System V certain modifications were made to the ABI.
A "" character in the right hand margin indicates a corrective change in the
ABI made just after the Release 4 ABI was published.
An "E" character in the right hand margin indicates a change in the ABI madein UNIX System V Release 4.1.
A "G" character in the right hand margin indicates a change in the ABI madein UNIX System V Release 4.2.
A "M" character in the right hand margin indicates a change in the ABI madein UnixWare 2.0. A "X" character in the right hand margin indicates achange in the ABI made to merge in XPG4.2 source API requirements.

Definitions of Terms

X

1-9

DRAFT COPY
March 18, 1997
File: chap1
386:adm.book:sum
Page: 19

2

SOFTWARE INSTALLATION

Software Installation and Packaging
Installation Media
Physical Distribution Media and Formats
Media Format
Software Structure of the Physical Media

File Formats

2-1
2-1
2-1
2-1
2-2

pkginfo File
The pkgmap File
The copyright File
The space File
The depend File
The compver File
Installation and Removal Scripts

2-7
2-7
2-9
2-10
2-10
2-11
2-11
2-11

File Tree for Add-on Software

2-15

Commands That Install, Remove andAccess Packages

2-16

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cchap2
386:adm.book:sum
Page: 20

Software Installation and Packaging
Installation MediaThis section of the ABI describes the media from which application software canbe installed on all ABI-conforming systems. It includes the following characteristics of supported media:
Physical Distribution Media and Formats: Specification of the physicalmedia that may be used to distribute ABI-conforming application software.
Media Format: Format of the software on the installation medium.
Software Structure of the Physical Media: A functional description of thefiles contained on the physical media and their layout on the media.
File Formats: The format and interpretation of installation data files.

Physical Distribution Media and Formats
NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

Media Format
Packages are stored as a continuous data stream on the distribution media. The
continuous data stream is valid for all media. The data stream can be createdusing the dd and cpio utilities.

Software Installation and Packaging

2-1

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 21

Software Structure of the Physical Media
Add-on application software is bundled and installed in units called packages.
Multiple packages can be delivered on a single volume of media or a package canspan multiple volumes of media. A package that spans multiple volumes of
media must be the only package in the distribution. cpio always pads headers toa 512 byte boundary, and archives to an integral block size, set by the -C or -B
option. Each archive on the media is extended to the block size specified by null
padding.
Software to be bundled as a package must be organized as a file tree subdirectory
as shown in Figure 2-1. The data stream from the distribution media is read onto
disk into a file subtree of this format before the actual installation begins. Figure
2-2 shows the sequence of files in the data stream stored on distribution media.
Figure 2-1: Package File Tree Organization

/
.
.
.
pkg

install pkginfo

compver

copyright depend

space

pkgmap

reloc

root

packageobjects

packageobjects

0 or more
scripts

2-2

SOFTWARE INSTALLATION

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 22E
E
E

The following is a brief description of files and directories shown in Figure 2-1.
Entries in constant width type are standard file or directory names; the namesof the other items are package-specific.
The following files are required:pkginfo: describes the package.
pkgmap: describes each package object (files, directories, and so on).
The following files and directories are optional:
compver: describes previous versions of the package with which this version is backward compatible.
copyright: copyright notice for the package.
depend: describes dependencies and incompatibilities across packages.
install: contains optional package information files.
package objects: executables, data files, and so on, belonging to the package.
reloc: contains relocatable package objects (files whose pathnames on thetarget system are determined at the time of installation rather than at thetime of package creation).
root: contains non-relocatable package objects.
space: describes space requirements beyond package objects.
scripts: zero or more scripts to handle package-specific installation andremoval requirements.

Software Installation and Packaging

2-3

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 23

Figure 2-2: Data Stream File Layout for Distribution Media

header:special information
files (cpio archive):# PaCkAgE DaTaStReAm[: type]pkgA num_parts max_part_size [N ... N]
pkgB num_parts max_part_size [N ... N].
.
.
# end of header
pkgA/pkginfo
pkgA/pkgmap
pkgB/pkginfo
pkgB/pkgmap.
.
.

package part
(cpio archive):

pkgA/pkginfo
pkgA/install/*pkgA/root.1/*
pkgA/reloc.1/*

package part
(cpio archive):

pkgA/pkginfo
pkgA/root.2/*
pkgA/reloc.2/*.
.
.

package part
(cpio archive):

pkgB/pkginfo
pkgB/install/*
pkgB/root.1/*
pkgB/reloc.1/*
.
.
.

2-4

SOFTWARE INSTALLATION

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 24

The data stream format begins with a header containing a series of new-line terminated ASCII character strings. A special character string on the first line
identifies the start of the header. It should be in the following format:# PaCkAgE DaTaStReAm[: type]
When no type is defined, the data stream is continuous. Additional types of data
streams may be specified in a processor-specific ABI supplement. Such additional
types would deal with media-specific physical storage attributes, for example,
record size, blocking factors, or alignment of package parts on the media.
Next are one or more special lines, one for each package in the distribution. Eachline has the following format:
pkginstance num_parts max_part_size [N . . . N]
where:
pkginstance is the package identifier made up of the package abbreviation(described later as the PKG parameter in the pkginfo file) and an optionalsuffix.
num_parts is the number of parts into which the package is divided. As
shown in Figure 2-2, a part is a collection of files contained in a cpio
archive. A part is the atomic unit by which a package is processed. Eachpart must fit entirely on a distribution media volume, that is, a part cannot
cross volumes. A developer chooses the criteria for grouping files into a
part.
max_part_size is the maximum number of 512-byte blocks consumed by asingle part of the package.
N . . . N are optional fields to indicate the number of parts stored on thesequential volumes of media which contain the package. For example,
pkgA 6 2048 2 3 1
indicates that pkgA consists of six parts. The largest part is 2048 512-byte
blocks in size. The first two parts exist on the first volume, the next threeparts exist on the second volume, and the last part exists on the third, andlast, volume. These fields only apply where multiple volumes are needed to
distribute a package. Otherwise, these fields should not appear and any
process reading the header should assume that all parts of the package
reside on the current volume. When these fields are used, there can only be
one package in the data stream.

Software Installation and Packaging

2-5

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 25

E

A special new-line terminated character string on a separate line identifies the endof the header. It should be in the following format:# end of header
The header must be padded to a 512-byte boundary.
Following the header is a cpio archive containing special information files foreach package. The rest of the data stream consists of package parts. Note that agiven package may consist of one or more parts, that is, cpio archives. A packages which requires multiple parts must meet the following conditions:
Each part must contain the entire pkginfo file.
Each part includes its own root and reloc directories and these directories
are numbered. For example, a package that requires n parts has root.1 andreloc.1 through root.n and reloc.n. n is limited to eight digits.
The install directory and its contents are only provided in the first part.

2-6

SOFTWARE INSTALLATION

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 26E

File Formats
pkginfo File
The pkginfo file describes the package, as a whole. Each line is of the form
parameter=value. The list below describes defined parameters. These parameters
can be retrieved via pkginfo(AS_CMD) and/or have a specific meaning to the
package installation and removal commands (pkgadd(AS_CMD) andpkgrm(AS_CMD)). No specific ordering of parameters is required. Lines beginning with # are treated as comments.
PKG: Package abbreviation, limited to 9 characters. The first character mustbe alphabetic; remaining characters can be alphabetic, numeric, or the characters + and -. install, new, and all are not valid package abbreviations.
NAME: Package name, limited to 256 ASCII characters.
ARCH: A comma-separated list of identifiers that specify the architecture(s)on which the package can run. Each architecture identifier is limited to 16
ASCII characters; the character ’,’ is invalid.
VERSION: Version identifier, limited to 256 ASCII characters. The first character can not be a left parenthesis due to the syntax of the depend file. This
identifier is vendor-specific information.
DESC: Descriptive text, limited to 256 ASCII characters.
VENDOR: Vendor identifier, limited to 256 ASCII characters.
HOTLINE: Phone number or mailing address where further information may
be requested or bugs reported. The value of this parameter is limited to 256
ASCII characters.
EMAIL: An electronic mail address, with the same purpose and length limitation as the HOTLINE parameter.
VSTOCK: Vendor stock number, limited to 256 ASCII characters.
CATEGORY: A comma-separated list of categories to which the package
belongs. Add-on software packages must state their membership in theapplication category. Users can request information on all packages in
specific categories via pkginfo(AS_CMD). Category identifiers are caseinsensitive and are limited to 16 alphanumeric characters, excluding thespace and comma characters.

File Formats

2-7

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 27

PSTAMP: Production stamp, limited to 256 ASCII characters.
ISTATES: Space-separated list of valid run-levels during which this package
can be installed. Run-levels are integers in the range 0 through 6, s and S[see System V Interface Definition, Fourth Edition, init(AS_CMD)].
RSTATES: Same as ISTATES, but applies to package removal.
ULIMIT: Temporary file size limit to use during installation of this package[see getrlimit].
INTONLY: A parameter that indicates a package can only be installed interactively by the pkgadd(AS_CMD) command. If this parameter is supplied andset to any non-null value (for example, y or yes), the package can only be
installed interactively. Otherwise, the package can be installed in a noninteractive mode using pkgask(AS_CMD) or pkgadd with the -n option.
MAXINST: An integer that specifies the maximum number of instances of thispackage that can be installed on a system at one time. If this parameter is
not supplied, a default of 1 is used (at most one copy of the package can beinstalled on a system at any time).
BASEDIR: The pathname to a default directory where ‘‘relocatable’’ files may
be installed. If BASEDIR is blank and the basedir variable in the admin file isset to ‘‘default,’’ the package is not considered relocatable. In this case, if
files have relative pathnames, package installation will fail. An administrator can override BASEDIR by setting the basedir variable in the admin file.






CLASSES: A space-separated list of package object classes to be installed.
Every package object is assigned to one class (in the pkgmap file). Class
assignment can be used to control (for example, based on administrator
input at the time of installation) which objects are installed and to provide
specific actions to be taken to install or remove them. The value of thisparameter can be overridden at the time of installation.
PKG, NAME, ARCH, VERSION, CATEGORY and BASEDIR are mandatory parameters,that is, package developers must supply them. The rest are optional.
Other parameters may be defined in the pkginfo file. If they are used as part ofpackage object pathnames in the pkgmap file, the value supplied in the pkginfo
file is used as a default and may be overridden at the time of
installation. Other parameters will be made part of the environment in which installation scripts execute.

2-8

SOFTWARE INSTALLATION

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 28

E

The pkgmap File
Each line in the pkgmap file describes a package object or installation script (withthe exception of one pkgmap entry, described at the end of this section). The following list describes the space-separated fields in each pkgmap entry; their ordermust be the same as in the list. Lines in the file that begin with # are ignored.
part: A positive integer that indicates the part of a multi-part package inwhich this pathname resides.
ftype: A one-character file type identifier from the set below:fa fileda directoryian installation or removal scriptla linked filesa symbolic linkpa named pipeba block special deviceca character special deviceea file installed or removed by editingv

a volatile file, whose contents are expected to change as the
package is used on the systemx

an exclusive directory, which should contain only files installed
as part of this or some other standard format packageclass: A package object class identifier, limited to 12 characters. none is used
to specify no class membership. This field is not specified for files whose
ftype is i.
pathname: The pathname describing the location of the file on the target
machine. For files of ftype, l or s, pathname must be of the form path1=path2,
specifying the destination (path1) and source (path2) files to be linked. Special characters, such as an equal sign (=), are included in pathnames by surrounding the entire pathname in single quotes (as in, for example,’/usr/lib/˜=’).
The pathname may contain variables which support relocation of the file. A$parameter may be embedded in the pathname structure. $BASEDIR can beused to identify the parent directories of the path hierarchy, making theentire package easily relocatable. Default values for parameter and BASEDIR
must be supplied in the pkginfo file and may be overridden at installation.

File Formats

2-9

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 29

major: The major device number, applicable to files whose ftype is b or c.
minor: The minor device number, applicable to files whose ftype is b or c.
mode: The octal mode of the file. ? indicates that no particular mode isrequired. This field is not provided for files whose ftype is l, s or i.
owner: The uid of the owner of the file; it must be a legal uid. ? indicates thatno particular owner is required. This field is not provided for files whose
ftype is l, s or i.
group: The group to which the file belongs, limited to 14 characters. ? indicates that no particular group is required. This field is not provided for files
whose ftype is l, s or i.
size: The file size in bytes. This field is not provided for files whose ftype is d,x, p, b, c, s or l.
cksum: The checksum of the file contents, as calculated by sum. This field is
not provided for files whose ftype is d, x, p, b, c, s or l.
modtime: The time of last modification as reported by the function stat.
This field is not provided for files whose ftype is d, x, p, b, c or l.
An additional line in the pkgmap file, beginning with a colon, provides information about the media on which the package is distributed. Its format is::number_of_parts maximum_part_size
number_of_parts specifies the number of parts which compose this package.
maximum_part_size specifies the size, in 512-byte blocks, of the largest part.

The copyright File
The contents of the copyright file will be displayed on stdout at the time of installation; there are no format requirements.

The space File
The space file describes disk block and inode requirements for the package
beyond files listed in the pkgmap file and provided on the media. Each line in thefile contains the following three space-separated fields:
pathname: A directory name. Naming conventions (with respect to indicating relocatability) are the same as for the pathname field in the pkgmap file.
blocks: The number of 512-byte blocks required.

2-10

SOFTWARE INSTALLATION

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 30

inodes: The number of distinct files required.

The depend File
The depend file describes dependencies across packages. The format of each entry
is as follows:
type pkg name(arch)version
The following field definitions and rules apply:
type: Describes the type of dependency:Pa prerequisite for installationI

an incompatibilityRreverse dependency (the referenced package depends on this package)

pkg: The package abbreviation, as defined in the pkginfo file.
name: The package name, as defined in the pkginfo file.
arch: The package architecture, as defined in the pkginfo file.
version: The package version, as defined in the pkginfo file.
There may be zero or more (arch)version lines.
(arch)version lines must begin with white space.

The compver File
The compver file specifies previous versions of the package with which this version is backward compatible. It is used for dependency checking across packages,
in conjunction with the depend file. It consists of version identifiers, as defined in
the pkginfo file, one per line.

Installation and Removal Scripts
This section describes installation and removal scripts that may be provided by apackage to meet package-specific needs. Scripts are executed by the command sh
and therefore must be either shell scripts or executable programs. In the case ofrecovery from an interrupted installation they may be re-executed; they should be
written so that multiple invocations produce the same results as a single invocation.

File Formats

2-11

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 31

NOTE

Since substantive differences exist between the shell traditionally provided by
System V systems and the new X/Open CAE Specification, Issue 4.2 shell, andsince many shell scripts are liable to be affected by these differences, it isrecommended that installation scripts and any other shell scripts that havestringent compatibility requirements continue to use the traditional System Vshell. New shell scripts may wish to take advantage of the capabilities of the
X/Open CAE Specification, Issue 4.2 shell.

X
X
X
X
X

The request Script
The request script, if provided, is the first script executed at the time of package
installation. Its purpose is to interact with the user and modify details of the installation process as a result of this interaction. The script writes shell variableassignments to the file named by its only argument. It is executed with uid rootand gid sys. stdin, stdout and stderr are all attached to the controlling terminal. The following variables are defined as part of the installation procedure andmay be set by the request script:

E
E

CLASSES: As defined in the pkginfo file.
Procedure Scripts
Four scripts may be provided by a package to handle package-specific requirements - preinstall, postinstall, preremove and postremove.
The following constraints apply to these procedure scripts:
When the script is executed, stdin is attached to the controlling terminal;
stdout and stderr are attached to the controlling terminal.

M

Each pathname created or modified by a procedure script during installation or removal, and which should be considered part of the package, must
be logically added or removed from the package via theinstallf(AS_CMD) or removef(AS_CMD) commands.
Procedure scripts are executed with uid root and gid sys.
Class Scripts
Class scripts provide non-standard installation and removal actions for classes of
package objects (the membership of objects in a class is specified in the pkgmap
file). The following constraints apply:
Each class included in the value of the CLASSES parameter is installed, in theorder in which they appear in that parameter. Objects in class none are
installed first.

2-12

SOFTWARE INSTALLATION

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 32

M

If an object belongs to class none or no class script is provided for the class,the object is copied from the medium to the target system during installation, and removed during removal.
Class script names are of the form operation.class, where operation is either i(for install) or r (for remove), and class is the class name, limited to 12 characters. Class names beginning with 0 are reserved.
Class scripts will execute as uid root and gid sys.

M

During installation, the script is executed with either no arguments or the
single argument ENDOFCLASS. stdin contains a list of filename pairs, of theform source_pathname destination_pathname. The source_pathname parameteris either a pathname on the medium or /dev/null to indicate there is no file
to copy from the medium (for example, a directory). destination_pathname isthe target pathname. Only files that are members of the class and are not
identical to files already on the system are provided to the script.
The script is invoked with the single argument ENDOFCLASS to indicate that
there are no more files belonging to the class once end of file is reached on
stdin during the current invocation of the script.
During removal, the script is executed with no arguments. stdin contains alist of filenames, including all members of the class except those shared byother installed packages whose ftype in the pkgmap file is something otherthan e.
Two standard classes are defined: build and sed. The name of the file on
the medium is the name of the file on the target system to be modified.



For the sed class, the file provided on the medium contains the commandsed instructions. Lines of the format !install and !remove mark the
beginning of instructions which apply to installation and removal, respectively. The file on the target system will be modified by the output of sed,using the provided data.



A file that belongs to the build class is executed with a single argument,
install or remove. Its output (on stdout) is written to the file it referenceson the target system.
Exit Codes Used by Scripts
Scripts shall exit with an additive combination of one of the first four and one of
the last two exit codes listed below:
0:

successful execution

File Formats

2-13

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 33

E

1:
2:
3:
10:
20:

fatal error
warning
interruption
reboot after installation of all packages
reboot after installation of this package

For example, the exit code for a script resulting in a warning condition and that
requires an immediate reboot is 22.

2-14

SOFTWARE INSTALLATION

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 34

File Tree for Add-on Software/opt, /var/opt and /etc/opt are reserved in the file tree for the installation of
application software packages. Each add-on software package should adhere to
the following rules:
Static package objects should be installed in /opt/pkg, where pkg is the
package abbreviation or instance.
Package objects that change in normal operations (for example, log andspool files) should be installed in /var/opt/pkg.
Machine-specific configuration files should be installed in /etc/opt/pkg.
Executables that are directly invoked by users should be installed in/opt/pkg/bin.
Only package objects that must reside in specific locations within the systemfile tree in order to function properly (for example, special files in /dev)
should be installed in those locations.

File Tree for Add-on Software

2-15

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 35

Commands That Install, Remove and Access
Packages
The following commands and library routines are used to install and remove
packages and to retrieve information about installed packages. They will be
included in every ABI-conforming system, and are defined in the System V Interface Definition, Fourth Edition.
pkgadd(AS_CMD):

installs packages

pkgrm(AS_CMD):

removes packages

pkgchk(AS_CMD):

checks installed packages

pkginfo(AS_CMD):

display information about packages

pkgask(AS_CMD):

runs the request script and stores output for later use

installf(AS_CMD):

associates an installed file with a package

removef(AS_CMD):

removes a file’s association with a package

pkgparam(AS_CMD):

display the values of parameters defined by the packagein the pkginfo file

2-16

SOFTWARE INSTALLATION

DRAFT COPY
March 18, 1997
File: chap2
386:adm.book:sum
Page: 36

3

LOW-LEVEL SYSTEMINFORMATION

Introduction

3-1

Character Representations

3-2

Machine Interface (Processor-Specific)

3-3Function Calling Sequence (ProcessorSpecific)

3-4Operating System Interface (ProcessorSpecific)

3-5

Coding Examples (Processor-Specific)

3-6

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cchap3
386:adm.book:sum
Page: 37

Introduction
This chapter defines low-level system information, much of which is processorspecific. It gives the constraints imposed by the system on application programs,
and it describes how application programs use operating system services. ANSI C
serves as the ABI reference programming language. By defining the implementation of C data types, the ABI can give precise system interface information without
resorting to assembly language. Giving C language bindings for system services
does not preclude bindings for other programming languages. Moreover, theexamples given here are not intended to specify the C language available on theprocessor.
NOTE

According to ANSI C, a bit-field may have type int, unsigned int, or
signed int. The C language used in this ABI allows bit-fields of type char,short, int, and long (plus their signed and unsigned variants), and oftype enum.

This chapter’s major sections discuss the following topics.
Character representations. This section defines the standard character set used
for external files that should be portable among systems.
Machine interface. This section describes the processor architecture available
to programs. It also defines the reference language data types, giving thefoundation for system interface specifications.
Function calling sequence. The standard function calling sequence accommodates the operating system interface, including system calls, signals, andstack management.
Operating system interface. This section describes the operating systemmechanisms that are visible to application programs (such as signals, process initialization, and so on).
Coding examples. Finally, some C code fragments show how programming
languages may implement some fundamental operations under the ABI
specifications. These examples are not intended to give the only implementations, the optimal implementations, nor requirements for implementations.

Introduction

3-1

DRAFT COPY
March 18, 1997
File: chap3
386:adm.book:sum
Page: 38

Character Representations
Several external file formats represent control information with characters (see‘‘Archive File’’ in Chapter 7, for example). These single-byte characters use the 7bit ASCII character set. In other words, when the ABI mentions character constants, such as ’/’ or ’\n’, their numerical values should follow the 7-bit ASCII
guidelines. For the previous character constants, the single-byte values would be
47 and 10, respectively.
Character values outside the range of 0 to 127 may occupy one or more bytes,
according to the character encoding. Applications can control their own character
sets, using different character set extensions for different languages as appropriate. Although ABI-conformance does not restrict the character sets, they generally
should follow some simple guidelines.
Character values between 0 and 127 should correspond to the 7-bit ASCII
code. That is, character sets with encodings above 127 should include the7-bit ASCII code as a subset.
Multibyte character encodings with values above 127 should contain only
bytes with values outside the range of 0 to 127. That is, a character set thatuses more than one byte per character should not ‘‘embed’’ a byte resembling a 7-bit ASCII character within a multibyte, non-ASCII character.
Multibyte characters should be self-identifying. That allows, for example,
any multibyte character to be inserted between any pair of multibyte characters, without changing the characters’ interpretations.
These cautions are particularly relevant for multilingual applications.

3-2

LOW-LEVEL SYSTEM INFORMATION

DRAFT COPY
March 18, 1997
File: chap3
386:adm.book:sum
Page: 39

Machine Interface (Processor-Specific)

NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

Machine Interface (Processor-Specific)

3-3

DRAFT COPY
March 18, 1997
File: chap3
386:adm.book:sum
Page: 40

Function Calling Sequence (ProcessorSpecific)

NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

3-4

LOW-LEVEL SYSTEM INFORMATION

DRAFT COPY
March 18, 1997
File: chap3
386:adm.book:sum
Page: 41

Operating System Interface (ProcessorSpecific)

NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

Operating System Interface (Processor-Specific)

DRAFT COPY
March 18, 1997
File: chap3
386:adm.book:sum
Page: 423-5

Coding Examples (Processor-Specific)

NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

3-6

LOW-LEVEL SYSTEM INFORMATION

DRAFT COPY
March 18, 1997
File: chap3
386:adm.book:sum
Page: 43

4

OBJECT FILES

Introduction

4-1
4-1
4-3

File Format
Data Representation

ELF Header
ELF Identification
Machine Information (Processor-Specific)

Sections

4-4
4-7
4-9

Special Sections

4-10
4-17

String Table

4-21

Symbol Table

4-22
4-26

Symbol Values

Relocation
Relocation Types (Processor-Specific)

Table of Contents

4-27
4-28

i

DRAFT COPY
March 18, 1997
File: Cchap4
386:adm.book:sum
Page: 44

Introduction
This chapter describes the object file format, called ELF (Executable and Linking
Format). There are three main types of object files.
A relocatable file holds code and data suitable for linking with other object
files to create an executable or a shared object file.
An executable file holds a program suitable for execution; the file specifies
how the function exec creates a program’s process image.

X

A shared object file holds code and data suitable for linking in two contexts.
First, the link editor [see ld(SD_CMD)] may process it with other relocatable and shared object files to create another object file. Second, thedynamic linker combines it with an executable file and other shared objects
to create a process image.
Created by the assembler and link editor, object files are binary representations ofprograms intended to execute directly on a processor. Programs that require
other abstract machines, such as shell scripts, are excluded.
After the introductory material, this chapter focuses on the file format and how it
pertains to building programs. Chapter 5 also describes parts of the object file,concentrating on the information necessary to execute a program.

File Format
Object files participate in program linking (building a program) and program execution (running a program). For convenience and efficiency, the object file format
provides parallel views of a file’s contents, reflecting the differing needs of these
activities. Figure 4-1 shows an object file’s organization.

Introduction

4-1

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 45

Figure 4-1: Object File Format

Linking View______________________
______________________

ELF header Program header table 
optional______________________
______________________

Section 1...
______________________
______________________
Section n...
______________________
...
______________________ Section header table 
______________________

Execution View_______________________
_______________________

ELF header Program header table 
_______________________
Segment 1

_______________________
Segment 2

_______________________...
_______________________ Section header table 
optional_______________________
An ELF header resides at the beginning and holds a ‘‘road map’’ describing thefile’s organization. Sections hold the bulk of object file information for the linking
view: instructions, data, symbol table, relocation information, and so on. Descriptions of special sections appear later in the chapter. Chapter 5 discusses segments
and the program execution view of the file.
A program header table, if present, tells the system how to create a process image.
Files used to build a process image (execute a program) must have a program
header table; relocatable files do not need one. A section header table contains information describing the file’s sections. Every section has an entry in the table; eachentry gives information such as the section name, the section size, and so on. Files
used during linking must have a section header table; other object files may or
may not have one.
NOTE

Although the figure shows the program header table immediately after the
ELF header, and the section header table following the sections, actual files
may differ. Moreover, sections and segments have no specified order. Only
the ELF header has a fixed position in the file.

4-2

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 46

Data Representation
As described here, the object file format supports various processors with 8-bit
bytes and 32-bit architectures. Nevertheless, it is intended to be extensible tolarger (or smaller) architectures. Object files therefore represent some control datawith a machine-independent format, making it possible to identify object files andinterpret their contents in a common way. Remaining data in an object file use theencoding of the target processor, regardless of the machine on which the file wascreated.
Figure 4-2: 32-Bit Data Types

Name
Size
Alignment
Purpose_____________________________________________________________
 4 
 Unsigned program address
Elf32_Addr
4
 2 
 Unsigned medium integer
Elf32_Half2
Elf32_Off4
 4 
 Unsigned file offset
Elf32_Sword44 Signed large integer
Elf32_Word 4 4 Unsigned large integer
 Unsigned small integer
unsigned char  1 1_____________________________________________________________

All data structures that the object file format defines follow the ‘‘natural’’ size andalignment guidelines for the relevant class. If necessary, data structures contain
explicit padding to ensure 4-byte alignment for 4-byte objects, to force structure
sizes to a multiple of 4, and so on. Data also have suitable alignment from the
beginning of the file. Thus, for example, a structure containing an Elf32_Addr
member will be aligned on a 4-byte boundary within the file.
For portability reasons, ELF uses no bit-fields.

Introduction

4-3

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 47

ELF Header
Some object file control structures can grow, because the ELF header contains theiractual sizes. If the object file format changes, a program may encounter control
structures that are larger or smaller than expected. Programs might therefore
ignore ‘‘extra’’ information. The treatment of ‘‘missing’’ information depends oncontext and will be specified when and if extensions are defined.
Figure 4-3: ELF Header#define EI_NIDENT

16

typedef struct {unsigned charElf32_Half
Elf32_Half
Elf32_Word
Elf32_Addr
Elf32_Off
Elf32_Off
Elf32_Word
Elf32_Half
Elf32_Half
Elf32_Half
Elf32_Half
Elf32_Half
Elf32_Half} Elf32_Ehdr;

e_ident

e_ident[EI_NIDENT];
e_type;e_machine;e_version;
e_entry;e_phoff;e_shoff;
e_flags;
e_ehsize;e_phentsize;
e_phnum;
e_shentsize;e_shnum;
e_shstrndx;

The initial bytes mark the file as an object file and provide
machine-independent data with which to decode and interpretthe file’s contents. Complete descriptions appear below, in ‘‘ELF
Identification.’’

4-4

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 48

e_typeThis member identifies the object file type.
Name
Value
Meaning_______________________________________

ET_NONE
0 No file type
ET_REL1  Relocatable file

ET_EXEC
2  Executable file
ET_DYN
3  Shared object file
ET_CORE
4  Core file
ET_LOPROC  0xff00  Processor-specific
ET_HIPROC  0xffff  Processor-specific_______________________________________

Although the core file contents are unspecified, type ET_CORE isreserved to mark the file. Values from ET_LOPROC through
ET_HIPROC (inclusive) are reserved for processor-specific semantics. If meanings are specified, the processor supplement explainsthem. Other values are reserved and will be assigned to new
object file types as necessary.

e_machine

This member’s value specifies the required architecture for anindividual file.
Name
Value
Meaning__________________________________________________

EM_NONE
0  No machine
EM_M32
1  AT&T WE 32100

EM_SPARC
2  SPARC

EM_3863  Intel 80386

EM_68K
4  Motorola 68000

EM_88K5  Motorola 88000

EM_8607  Intel 80860

EM_MIPS
8  MIPS RS3000 Big-Endian
EM_MIPS_RS4_BE 
10  MIPS RS4000 Big-Endian
RESERVED 11-16  Reserved for future use__________________________________________________



E
E
E

Other values are reserved and will be assigned to new machines
as necessary. Processor-specific ELF names use the machine nameto distinguish them. For example, the flags mentioned below use
the prefix EF_; a flag named WIDGET for the EM_XYZ machine
would be called EF_XYZ_WIDGET.
e_version

This member identifies the object file version.

ELF Header

4-5

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 49

Name
Value
Meaning_____________________________________
 0
 Invalid version
EV_NONE Current version
EV_CURRENT  1_____________________________________

The value 1 signifies the original file format; extensions will create
new versions with higher numbers. The value of EV_CURRENT,
though given as 1 above, will change as necessary to reflect thecurrent version number.
e_entryThis member gives the virtual address to which the system firsttransfers control, thus starting the process. If the file has no associated entry point, this member holds zero.

e_phoff

This member holds the program header table’s file offset in bytes.
If the file has no program header table, this member holds zero.

e_shoff

This member holds the section header table’s file offset in bytes. If
the file has no section header table, this member holds zero.

e_flags

This member holds processor-specific flags associated with thefile. Flag names take the form EF_machine_flag. See ‘‘Machine
Information’’ in the processor supplement for flag definitions.

e_ehsizeThis member holds the ELF header’s size in bytes.

e_phentsize

This member holds the size in bytes of one entry in the file’s program header table; all entries are the same size.

e_phnum

This member holds the number of entries in the program header
table. Thus the product of e_phentsize and e_phnum gives thetable’s size in bytes. If a file has no program header table,e_phnum holds the value zero.

e_shentsize

This member holds a section header’s size in bytes. A section
header is one entry in the section header table; all entries are thesame size.

e_shnum

This member holds the number of entries in the section header
table. Thus the product of e_shentsize and e_shnum gives thesection header table’s size in bytes. If a file has no section header
table, e_shnum holds the value zero.

e_shstrndx

This member holds the section header table index of the entry
associated with the section name string table. If the file has no
section name string table, this member holds the value
SHN_UNDEF. See ‘‘Sections’’ and ‘‘String Table’’ below for more
information.

4-6

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 50

ELF Identification
As mentioned above, ELF provides an object file framework to support multiple
processors, multiple data encodings, and multiple classes of machines. To support
this object file family, the initial bytes of the file specify how to interpret the file,independent of the processor on which the inquiry is made and independent of
the file’s remaining contents.
The initial bytes of an ELF header (and an object file) correspond to the e_ident
member.
Figure 4-4: e_ident[ ] Identification Indexes

Name
Value
Purpose__________________________________________


EI_MAG00File identification

EI_MAG1
1  File identification
EI_MAG2
2  File identification

EI_MAG3
3  File identification

EI_CLASS
4  File class
EI_DATA
5  Data encoding
EI_VERSION
6  File version

EI_PAD
7  Start of padding bytes

EI_NIDENT  16  Size of e_ident[]__________________________________________


These indexes access bytes that hold the following values.
EI_MAG0 to EI_MAG3
A file’s first 4 bytes hold a ‘‘magic number,’’ identifying the fileas an ELF object file.
Name
Value
Position_____________________________________
ELFMAG0  0x7f  e_ident[EI_MAG0]
ELFMAG1  ’E’  e_ident[EI_MAG1]
ELFMAG2  ’L’  e_ident[EI_MAG2]
ELFMAG3  ’F’  e_ident[EI_MAG3]_____________________________________

ELF Header

4-7

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 51

EI_CLASSThe next byte, e_ident[EI_CLASS], identifies the file’s class, or
capacity.
Name
Value
Meaning____________________________________

ELFCLASSNONE
0
Invalid class 1
 32-bit objects
ELFCLASS32
E
LFCLASS64____________________________________
 2
 64-bit objects
The file format is designed to be portable among machines ofvarious sizes, without imposing the sizes of the largest machineon the smallest. Class ELFCLASS32 supports machines with files
and virtual address spaces up to 4 gigabytes; it uses the basic
types defined above.
Class ELFCLASS64 is reserved for 64-bit architectures. Its appearance here shows how the object file may change, but the 64-bit
format is otherwise unspecified. Other classes will be defined asnecessary, with different basic types and sizes for object file data.

EI_DATA

Byte e_ident[EI_DATA] specifies the data encoding of theprocessor-specific data in the object file. The following encodings
are currently defined.
Name
Value
Meaning___________________________________________

ELFDATANONE
0
Invalid data encoding See below
ELFDATA2LSB  1

E
LFDATA2MSB  2___________________________________________
 See below
More information on these encodings appears below. Other
values are reserved and will be assigned to new encodings asnecessary.

EI_VERSION

Byte e_ident[EI_VERSION] specifies the ELF header version
number. Currently, this value must be EV_CURRENT, as explained
above for e_version.

EI_PAD

This value marks the beginning of the unused bytes in e_ident.
These bytes are reserved and set to zero; programs that read
object files should ignore them. The value of EI_PAD will change
in the future if currently unused bytes are given meanings.

A file’s data encoding specifies how to interpret the basic objects in a file. As
described above, class ELFCLASS32 files use objects that occupy 1, 2, and 4 bytes.
Under the defined encodings, objects are represented as shown below. Byte
numbers appear in the upper left corners.

4-8

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 52

Encoding ELFDATA2LSB specifies 2’s complement values, with the least significant
byte occupying the lowest address.
Figure 4-5: Data Encoding ELFDATA2LSB

0x01
0x01020x01020304

0

0

0

01
02
04

1

1

01
03

2

02

3

01

Encoding ELFDATA2MSB specifies 2’s complement values, with the most significant
byte occupying the lowest address.
Figure 4-6: Data Encoding ELFDATA2MSB

0x01
0x01020x01020304

0

0

0

01
01
01

1

1

02
02

2

03

3

04

Machine Information (Processor-Specific)
NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

ELF Header

4-9

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 53

Sections
An object file’s section header table lets one locate all the file’s sections. The section header table is an array of Elf32_Shdr structures as described below. A section header table index is a subscript into this array. The ELF header’s e_shoff
member gives the byte offset from the beginning of the file to the section header
table; e_shnum tells how many entries the section header table contains;e_shentsize gives the size in bytes of each entry.
Some section header table indexes are reserved; an object file will not have sections for these special indexes.
Figure 4-7: Special Section Indexes

Name
Value
________________________

SHN_UNDEF
0
SHN_LORESERVE  0xff00

SHN_LOPROC
 0xff00
SHN_HIPROC
 0xff1f
SHN_ABS 0xfff1
 0xfff2
SHN_COMMONSHN_HIRESERVE  0xffff________________________


SHN_UNDEFNOTEThis value marks an undefined, missing, irrelevant, or otherwise meaningless section reference. For example, a symbol‘‘defined’’ relative to section number SHN_UNDEF is an
undefined symbol.

Although index 0 is reserved as the undefined value, the section header tablecontains an entry for index 0. That is, if the e_shnum member of the ELF
header says a file has 6 entries in the section header table, they have theindexes 0 through 5. The contents of the initial entry are specified later in thissection.

SHN_LORESERVEThis value specifies the lower bound of the range of reserved
indexes.

SHN_LOPROC through SHN_HIPROC
Values in this inclusive range are reserved for processorspecific semantics. If meanings are specified, the processor
supplement explains them.

4-10

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 54

SHN_ABS

This value specifies absolute values for the correspondingreference. For example, symbols defined relative to section
number SHN_ABS have absolute values and are not affected byrelocation.

SHN_COMMON

Symbols defined relative to this section are common symbols,
such as FORTRAN COMMON or unallocated C external variables.

SHN_HIRESERVEThis value specifies the upper bound of the range of reserved
indexes. The system reserves indexes between
SHN_LORESERVE and SHN_HIRESERVE, inclusive; the values do
not reference the section header table. That is, the section
header table does not contain entries for the reserved indexes.

Sections contain all information in an object file, except the ELF header, the program header table, and the section header table. Moreover, object files’ sections
satisfy several conditions.
Every section in an object file has exactly one section header describing it.
Section headers may exist that do not have a section.
Each section occupies one contiguous (possibly empty) sequence of bytes
within a file.
Sections in a file may not overlap. No byte in a file resides in more than one
section.
An object file may have inactive space. The various headers and the sections might not ‘‘cover’’ every byte in an object file. The contents of theinactive data are unspecified.
A section header has the following structure.

Sections

4-11

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 55

Figure 4-8: Section Header

typedef struct {Elf32_Word
Elf32_Word
Elf32_Word
Elf32_Addr
Elf32_Off
Elf32_Word
Elf32_Word
Elf32_Word
Elf32_Word
Elf32_Word} Elf32_Shdr;

sh_name;sh_type;sh_flags;
sh_addr;sh_offset;
sh_size;
sh_link;
sh_info;sh_addralign;
sh_entsize;

sh_nameThis member specifies the name of the section. Its value is anindex into the section header string table section [see ‘‘String
Table’’ below], giving the location of a null-terminated string.

sh_typeThis member categorizes the section’s contents and semantics.
Section types and their descriptions appear below.

sh_flags

Sections support 1-bit flags that describe miscellaneous attributes. Flag definitions appear below.

sh_addrIf the section will appear in the memory image of a process,this member gives the address at which the section’s first byteshould reside. Otherwise, the member contains 0.

sh_offset

This member’s value gives the byte offset from the beginningof the file to the first byte in the section. One section type,
SHT_NOBITS described below, occupies no space in the file,and its sh_offset member locates the conceptual placementin the file.

sh_size

This member gives the section’s size in bytes. Unless the section type is SHT_NOBITS, the section occupies sh_size bytes
in the file. A section of type SHT_NOBITS may have a non-zerosize, but it occupies no space in the file.

sh_link

This member holds a section header table index link, whose
interpretation depends on the section type. A table below
describes the values.

4-12

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 56

sh_info

This member holds extra information, whose interpretation
depends on the section type. A table below describes thevalues.

sh_addralignSome sections have address alignment constraints. For example, if a section holds a doubleword, the system must ensure
doubleword alignment for the entire section. That is, the valueof sh_addr must be congruent to 0, modulo the value of
sh_addralign. Currently, only 0 and positive integral powersof two are allowed. Values 0 and 1 mean the section has noalignment constraints.

sh_entsize

Some sections hold a table of fixed-size entries, such as a symbol table. For such a section, this member gives the size inbytes of each entry. The member contains 0 if the section does
not hold a table of fixed-size entries.

A section header’s sh_type member specifies the section’s semantics.
Figure 4-9: Section Types, sh_type

Name
Value
____________________________

SHT_NULL0
SHT_PROGBITS 
1
SHT_SYMTAB2SHT_STRTAB3
SHT_RELA
4

SHT_HASH
5
SHT_DYNAMIC 
6
SHT_NOTE
7
SHT_NOBITS8
SHT_REL9
SHT_SHLIB
10SHT_DYNSYM
11
SHT_LOPROC
0
x
7
0
0
0
0
0
00

SHT_HIPROC
0
x
7
f
f
f
f
f
ff

 0x80000000
SHT_LOUSER
 0xffffffff
SHT_HIUSER____________________________


SHT_NULL

This value marks the section header as inactive; it does nothave an associated section. Other members of the section
header have undefined values.

Sections

4-13

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 57

SHT_PROGBITSThe section holds information defined by the program, whose
format and meaning are determined solely by the program.

SHT_SYMTAB and SHT_DYNSYM
These sections hold a symbol table. Currently, an object file
may have only one section of each type, but this restriction
may be relaxed in the future. Typically, SHT_SYMTAB provides
symbols for link editing, though it may also be used for
dynamic linking. As a complete symbol table, it may containmany symbols unnecessary for dynamic linking. Consequently, an object file may also contain a SHT_DYNSYM section,
which holds a minimal set of dynamic linking symbols, to save
space. See ‘‘Symbol Table’’ below for details.
SHT_STRTAB

The section holds a string table. An object file may have multiple string table sections. See ‘‘String Table’’ below for details.

SHT_RELA

The section holds relocation entries with explicit addends, suchas type Elf32_Rela for the 32-bit class of object files. An
object file may have multiple relocation sections. See ‘‘Relocation’’ below for details.

SHT_HASH

The section holds a symbol hash table. All objects participating
in dynamic linking must contain a symbol hash table.
Currently, an object file may have only one hash table, but thisrestriction may be relaxed in the future. See ‘‘Hash Table’’ in
Chapter 5 for details.

SHT_DYNAMIC

The section holds information for dynamic linking. Currently,
an object file may have only one dynamic section, but this restriction may be relaxed in the future. See ‘‘Dynamic Section’’in Chapter 5 for details.

SHT_NOTE

The section holds information that marks the file in some way.
See ‘‘Note Section’’ in Chapter 5 for details.

SHT_NOBITS

A section of this type occupies no space in the file but otherwise resembles SHT_PROGBITS. Although this section contains
no bytes, the sh_offset member contains the conceptual fileoffset.

SHT_REL

The section holds relocation entries without explicit addends,
such as type Elf32_Rel for the 32-bit class of object files. An
object file may have multiple relocation sections. See ‘‘Relocation’’ below for details.

4-14

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 58

This section type is reserved but has unspecified semantics.
Programs that contain a section of this type do not conform to
the ABI.

SHT_SHLIB

SHT_LOPROC through SHT_HIPROC
Values in this inclusive range are reserved for processorspecific semantics. If meanings are specified, the processor
supplement explains them.
SHT_LOUSER

This value specifies the lower bound of the range of indexes
reserved for application programs.

SHT_HIUSER

This value specifies the upper bound of the range of indexes
reserved for application programs. Section types between
SHT_LOUSER and SHT_HIUSER may be used by the application,
without conflicting with current or future system-defined section types.

Other section type values are reserved. As mentioned before, the section header
for index 0 (SHN_UNDEF) exists, even though the index marks undefined sectionreferences. This entry holds the following.
Figure 4-10: Section Header Table Entry: Index 0

Name
Value
Note
____________________________________________________
 No namesh_name0
 SHT_NULL  Inactive
sh_type
sh_flags0 No flags
sh_addr0 No address
sh_offset
0 No file offset
 No size
sh_size0 SHN_UNDEF  No link information
sh_link
sh_info0
 No auxiliary information
sh_addralign 0 No alignment
sh_entsize0 No entries____________________________________________________


A section header’s sh_flags member holds 1-bit flags that describe the section’s
attributes. Defined values appear below; other values are reserved.

Sections

4-15

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 59

Figure 4-11: Section Attribute Flags, sh_flags

Name
Value
_____________________________
SHF_WRITE
0x1
SHF_ALLOC
0x2

SHF_EXECINSTR 
0x4
SHF_MASKPROC  0xf0000000_____________________________


If a flag bit is set in sh_flags, the attribute is ‘‘on’’ for the section. Otherwise, theattribute is ‘‘off’’ or does not apply. Undefined attributes are set to zero.
SHF_WRITE

The section contains data that should be writable during process execution.

SHF_ALLOC

The section occupies memory during process execution.
Some control sections do not reside in the memory image ofan object file; this attribute is off for those sections.

SHF_EXECINSTR

The section contains executable machine instructions.

SHF_MASKPROC

All bits included in this mask are reserved for processorspecific semantics. If meanings are specified, the processor
supplement explains them.

Two members in the section header, sh_link and sh_info, hold special information, depending on section type.

4-16

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 60

Figure 4-12: sh_link and sh_info Interpretation

sh_typesh_link
sh_info_____________________________________________________________________SHT_DYNAMIC  The section header index of  0
 the string table used by_____________________________________________________________________
 entries in the section.
 The section header index of  0
SHT_HASH
 the symbol table to which the hash table applies.
_____________________________________________________________________

SHT_REL The section header index of  The section header index of the associated symbol table.  the section to which the
SHT_RELA relocation applies.
_____________________________________________________________________
SHT_SYMTAB  The section header index of  One greater than the symSHT_DYNSYM  the associated string table.
 bol table index of the last local symbol (binding STB_LOCAL).
_____________________________________________________________________


other
SHN_UNDEF
0_____________________________________________________________________


Special Sections
Various sections hold program and control information. Sections in the list below
are used by the system and have the indicated types and attributes.
Figure 4-13: Special Sections

Name
Type
Attributes________________________________________________________
 SHT_NOBITS SHF_ALLOC + SHF_WRITE.bss.comment  SHT_PROGBITS  none


.data
 SHT_PROGBITS  SHF_ALLOC + SHF_WRITE.data1 SHT_PROGBITS  SHF_ALLOC + SHF_WRITE.debug
 SHT_PROGBITS  none
.dynamic  SHT_DYNAMIC  see below
 SHT_STRTAB SHF_ALLOC.dynstr.dynsym SHT_DYNSYM SHF_ALLOC
.fini
S
H
T
_
P
R
O
G
B
I
T
S

 SHF_ALLOC + SHF_EXECINSTR.got
 SHT_PROGBITS  see below

Sections

4-17

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 61Figure 4-13: Special Sections (continued ).hash SHT_HASH SHF_ALLOC
 SHT_PROGBITS  SHF_ALLOC + SHF_EXECINSTR.init
 SHT_PROGBITS  see below.interp.line SHT_PROGBITS  none.note
 SHT_NOTE
 none.plt
 SHT_PROGBITS  see below
 see below.relname  SHT_REL see below.relaname
SHT_RELA.rodata SHT_PROGBITS  SHF_ALLOC.rodata1  SHT_PROGBITS  SHF_ALLOC.shstrtab  SHT_STRTAB
 none SHT_STRTAB
 see below.strtab see below.symtabSHT_SYMTAB


.text
SHT_PROGBITS SHF_ALLOC + SHF_EXECINSTR________________________________________________________



.bss

This section holds uninitialized data that contribute to theprogram’s memory image. By definition, the system initializes thedata with zeros when the program begins to run. The section occupies no file space, as indicated by the section type, SHT_NOBITS.

.comment

This section holds version control information.

.data and .data1
These sections hold initialized data that contribute to the program’s
memory image.
.debugThis section holds information for symbolic debugging. The contents are unspecified. All section names with the prefix .debug arereserved for future use in the ABI.

.dynamic

This section holds dynamic linking information. The section’s attributes will include the SHF_ALLOC bit. Whether the SHF_WRITE bit isset is processor specific. See Chapter 5 for more information.

.dynstr

This section holds strings needed for dynamic linking, most commonly the strings that represent the names associated with symbol
table entries. See Chapter 5 for more information.

.dynsymThis section holds the dynamic linking symbol table, as ‘‘Symbol
Table’’ describes. See Chapter 5 for more information.

4-18

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 62E

.finiThis section holds executable instructions that contribute to the process termination code. That is, when a program exits normally, thesystem arranges to execute the code in this section.

.got

This section holds the global offset table. See ‘‘Coding Examples’’in Chapter 3, ‘‘Special Sections’’ in Chapter 4, and ‘‘Global Offset
Table’’ in Chapter 5 of the processor supplement for more information.

.hashThis section holds a symbol hash table. See ‘‘Hash Table’’ in
Chapter 5 for more information.

.initThis section holds executable instructions that contribute to the process initialization code. That is, when a program starts to run, thesystem arranges to execute the code in this section before calling themain program entry point (called main for C programs).

.interp

This section holds the path name of a program interpreter. If thefile has a loadable segment that includes the section, the section’s
attributes will include the SHF_ALLOC bit; otherwise, that bit will beoff. See Chapter 5 for more information.

.line

This section holds line number information for symbolic debugging, which describes the correspondence between the source program and the machine code. The contents are unspecified.

.noteThis section holds information in the format that ‘‘Note Section’’ in
Chapter 5 describes.

.pltThis section holds the procedure linkage table. See ‘‘Special Sections’’ in Chapter 4 and ‘‘Procedure Linkage Table’’ in Chapter 5 ofthe processor supplement for more information.

.relname and .relaname
These sections hold relocation information, as ‘‘Relocation’’ below
describes. If the file has a loadable segment that includes relocation, the sections’ attributes will include the SHF_ALLOC bit; otherwise, that bit will be off. Conventionally, name is supplied by thesection to which the relocations apply. Thus a relocation section for.text normally would have the name .rel.text or .rela.text.
.rodata and .rodata1
These sections hold read-only data that typically contribute to a
non-writable segment in the process image. See ‘‘Program Header’’in Chapter 5 for more information.

Sections

4-19

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 63

.shstrtab

This section holds section names.

.strtabThis section holds strings, most commonly the strings that
represent the names associated with symbol table entries. If the file
has a loadable segment that includes the symbol string table, thesection’s attributes will include the SHF_ALLOC bit; otherwise, thatbit will be off.

.symtabThis section holds a symbol table, as ‘‘Symbol Table’’ in this chapter
describes. If the file has a loadable segment that includes the symbol table, the section’s attributes will include the SHF_ALLOC bit;otherwise, that bit will be off.

.text

This section holds the ‘‘text,’’ or executable instructions, of a program.

Section names with a dot (.) prefix are reserved for the system, although applications may use these sections if their existing meanings are satisfactory. Applications may use names without the prefix to avoid conflicts with system sections.
The object file format lets one define sections not in the list above. An object file
may have more than one section with the same name.
Section names reserved for a processor architecture are formed by placing anabbreviation of the architecture name ahead of the section name. The nameshould be taken from the architecture names used for e_machine. For instance.FOO.psect is the psect section defined by the FOO architecture. Existing extensions are called by their historical names.







Extensions_Pre-existing_____________________

.sdata.sbss.lit8.gptab.conflict







NOTE

.tdesc.lit4.reginfo.liblist

For information on processor-specific sections, see the ABI supplement forthe desired processor.

4-20

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 64

String Table
String table sections hold null-terminated character sequences, commonly called
strings. The object file uses these strings to represent symbol and section names.
One references a string as an index into the string table section. The first byte,
which is index zero, is defined to hold a null character. Likewise, a string table’s
last byte is defined to hold a null character, ensuring null termination for all
strings. A string whose index is zero specifies either no name or a null name,depending on the context. An empty string table section is permitted; its section
header’s sh_size member would contain zero. Non-zero indexes are invalid foran empty string table.
A section header’s sh_name member holds an index into the section header stringtable section, as designated by the e_shstrndx member of the ELF header. The
following figures show a string table with 25 bytes and the strings associated withvarious indexes.
Index
0
10
20

+0
+1
+2
+3
+4
+5
+6
+7
+8
+9
______________________________________________________
______________________________________________________









\0
n
a
m
e
.
\0
V
a
r 











i  a  b  l  e  \0  a  b  l  e 
______________________________________________________\0  \0  x  x  \0 
______________________________________________________






Figure 4-14: String Table Indexes

Index
String_________________
0none
 name.
17 Variable11 able16
 able null string24_________________As the example shows, a string table index may refer to any byte in the section. A
string may appear more than once; references to substrings may exist; and a single
string may be referenced multiple times. Unreferenced strings also are allowed.

String Table

4-21

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 65

Symbol Table
An object file’s symbol table holds information needed to locate and relocate a
program’s symbolic definitions and references. A symbol table index is a subscript into this array. Index 0 both designates the first entry in the table and serves
as the undefined symbol index. The contents of the initial entry are specified laterin this section.
Name
Value
___________________
STN_UNDEF  0___________________
A symbol table entry has the following format.
Figure 4-15: Symbol Table Entry

typedef struct {Elf32_Word
Elf32_Addr
Elf32_Word
unsigned char
unsigned charElf32_Half} Elf32_Sym;

st_namest_name;st_value;
st_size;
st_info;st_other;st_shndx;

This member holds an index into the object file’s symbol stringtable, which holds the character representations of the symbol
names. If the value is non-zero, it represents a string table index
that gives the symbol name. Otherwise, the symbol table entry
has no name.

External C symbols have the same names in C and object files’ symbol tables.



NOTE

st_value

This member gives the value of the associated symbol. Depending on the context, this may be an absolute value, an address, andso on; details appear below.

4-22

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 66st_size

Many symbols have associated sizes. For example, a data object’s
size is the number of bytes contained in the object. This member
holds 0 if the symbol has no size or an unknown size.

st_infoThis member specifies the symbol’s type and binding attributes.
A list of the values and meanings appears below. The following
code shows how to manipulate the values.

#define ELF32_ST_BIND(i)((i)>>4)#define ELF32_ST_TYPE(i)((i)&0xf)#define ELF32_ST_INFO(b,t) (((b)<<4)+((t)&0xf))

st_otherThis member currently holds 0 and has no defined meaning.

st_shndx

Every symbol table entry is ‘‘defined’’ in relation to some section;
this member holds the relevant section header table index. As
Figure 4-7 and the related text describe, some section indexes
indicate special meanings.

A symbol’s binding determines the linkage visibility and behavior.
Figure 4-16: Symbol Binding, ELF32_ST_BIND

Name
Value
____________________

STB_LOCAL
0
STB_GLOBAL 
1
STB_WEAK2
STB_LOPROC  13
STB_HIPROC  15____________________


STB_LOCAL

Local symbols are not visible outside the object file containing
their definition. Local symbols of the same name may exist in
multiple files without interfering with each other.

STB_GLOBAL

Global symbols are visible to all object files being combined. One
file’s definition of a global symbol will satisfy another file’s
undefined reference to the same global symbol.

Symbol Table

4-23

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 67

STB_WEAK

Weak symbols resemble global symbols, but their definitions
have lower precedence.

STB_LOPROC through STB_HIPROC
Values in this inclusive range are reserved for processor-specificsemantics. If meanings are specified, the processor supplement
explains them.
Global and weak symbols differ in two major ways.
When the link editor combines several relocatable object files, it does notallow multiple definitions of STB_GLOBAL symbols with the same name. On
the other hand, if a defined global symbol exists, the appearance of a weaksymbol with the same name will not cause an error. The link editor honors
the global definition and ignores the weak ones. Similarly, if a common
symbol exists (that is, a symbol whose st_shndx field holds SHN_COMMON),
the appearance of a weak symbol with the same name will not cause anerror. The link editor honors the common definition and ignores the weak
ones.
When the link editor searches archive libraries [see ‘‘Archive File’’ in
Chapter 7], it extracts archive members that contain definitions of undefined
global symbols. The member’s definition may be either a global or a weaksymbol. The link editor does not extract archive members to resolve
undefined weak symbols. Unresolved weak symbols have a zero value.
In each symbol table, all symbols with STB_LOCAL binding precede the weak andglobal symbols. As ‘‘Sections’’ above describes, a symbol table section’s sh_info
section header member holds the symbol table index for the first non-local symbol.
A symbol’s type provides a general classification for the associated entity.
Figure 4-17: Symbol Types, ELF32_ST_TYPE

Name
Value
_____________________

STT_NOTYPE
0
STT_OBJECT 
1
STT_FUNC
2

STT_SECTION 
3
STT_FILE
4
STT_LOPROC  13
STT_HIPROC  15_____________________


4-24

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 68

STT_NOTYPE

The symbol’s type is not specified.

STT_OBJECT

The symbol is associated with a data object, such as a variable,
an array, and so on.

STT_FUNC

The symbol is associated with a function or other executable
code.

STT_SECTION

The symbol is associated with a section. Symbol table entries ofthis type exist primarily for relocation and normally have
STB_LOCAL binding.

STT_FILE

Conventionally, the symbol’s name gives the name of the source
file associated with the object file. A file symbol has STB_LOCAL
binding, its section index is SHN_ABS, and it precedes the other
STB_LOCAL symbols for the file, if it is present.

STT_LOPROC through STT_HIPROC
Values in this inclusive range are reserved for processor-specificsemantics. If meanings are specified, the processor supplement
explains them.
Function symbols (those with type STT_FUNC) in shared object files have special
significance. When another object file references a function from a shared object,
the link editor automatically creates a procedure linkage table entry forthe referenced symbol. Shared object symbols with types other than STT_FUNC
will not be referenced automatically through the procedure linkage table.
If a symbol’s value refers to a specific location within a section, its section index
member, st_shndx, holds an index into the section header table. As the section
moves during relocation, the symbol’s value changes as well, and references to thesymbol continue to ‘‘point’’ to the same location in the program. Some special section index values give other semantics.
SHN_ABSThe symbol has an absolute value that will not change because of
relocation.

SHN_COMMON

The symbol labels a common block that has not yet been allocated. The symbol’s value gives alignment constraints, similar toa section’s sh_addralign member. That is, the link editor will
allocate the storage for the symbol at an address that is a multipleof st_value. The symbol’s size tells how many bytes are
required.

SHN_UNDEF

This section table index means the symbol is undefined. Whenthe link editor combines this object file with another that defines
the indicated symbol, this file’s references to the symbol will belinked to the actual definition.

Symbol Table

4-25

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 69

As mentioned above, the symbol table entry for index 0 (STN_UNDEF) is reserved; itholds the following.
Figure 4-18: Symbol Table Entry: Index 0

Name
Value
Note
_____________________________________________

st_name0
No name Zero value
st_value 0
st_size 0 No size
st_info 
0 No type, local binding
st_other 0st_shndx  SHN_UNDEF  No section_____________________________________________
Symbol Values
Symbol table entries for different object file types have slightly different interpretations for the st_value member.
In relocatable files, st_value holds alignment constraints for a symbol
whose section index is SHN_COMMON.
In relocatable files, st_value holds a section offset for a defined symbol.
That is, st_value is an offset from the beginning of the section thatst_shndx identifies.
In executable and shared object files, st_value holds a virtual address. To
make these files’ symbols more useful for the dynamic linker, the section
offset (file interpretation) gives way to a virtual address (memory interpretation) for which the section number is irrelevant.
Although the symbol table values have similar meanings for different object files,
the data allow efficient access by the appropriate programs.

4-26

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 70

Relocation
Relocation is the process of connecting symbolic references with symbolic
definitions. For example, when a program calls a function, the associated call
instruction must transfer control to the proper destination address at execution.
In other words, relocatable files must have information that describes how tomodify their section contents, thus allowing executable and shared object files tohold the right information for a process’s program image. Relocation entries arethese data.
Figure 4-19: Relocation Entries

typedef struct {Elf32_Addr
Elf32_Word} Elf32_Rel;

r_offset;
r_info;typedef struct {Elf32_Addr
Elf32_Word
Elf32_Sword} Elf32_Rela;r_offset;
r_info;r_addend;

r_offsetThis member gives the location at which to apply the relocation
action. For a relocatable file, the value is the byte offset from the
beginning of the section to the storage unit affected by the relocation.
For an executable file or a shared object, the value is the virtual
address of the storage unit affected by the relocation.

r_infoThis member gives both the symbol table index with respect towhich the relocation must be made, and the type of relocation to
apply. For example, a call instruction’s relocation entry would holdthe symbol table index of the function being called. If the index is
STN_UNDEF, the undefined symbol index, the relocation uses 0 as the‘‘symbol value.’’ Relocation types are processor-specific; descriptions of their behavior appear in the processor supplement. Whenthe text in the processor supplement refers to a relocation entry’s
relocation type or symbol table index, it means the result of applying
ELF32_R_TYPE or ELF32_R_SYM, respectively, to the entry’s r_info
member.

Relocation

4-27

DRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 71

#define ELF32_R_SYM(i)((i)>>8)#define ELF32_R_TYPE(i)((unsigned char)(i))#define ELF32_R_INFO(s,t) (((s)<<8)+(unsigned char)(t))

r_addend

This member specifies a constant addend used to compute the value
to be stored into the relocatable field.

As shown above, only Elf32_Rela entries contain an explicit addend. Entries oftype Elf32_Rel store an implicit addend in the location to be modified. Depending on the processor architecture, one form or the other might be necessary or
more convenient. Consequently, an implementation for a particular machine may
use one form exclusively or either form depending on context.
A relocation section references two other sections: a symbol table and a section tomodify. The section header’s sh_info and sh_link members, described in ‘‘Sections’’ above, specify these relationships. Relocation entries for different object
files have slightly different interpretations for the r_offset member.
In relocatable files, r_offset holds a section offset. That is, the relocation
section itself describes how to modify another section in the file; relocation
offsets designate a storage unit within the second section.
In executable and shared object files, r_offset holds a virtual address. To
make these files’ relocation entries more useful for the dynamic linker, thesection offset (file interpretation) gives way to a virtual address (memory
interpretation).
Although the interpretation of r_offset changes for different object files to allow
efficient access by the relevant programs, the relocation types’ meanings stay thesame.

Relocation Types (Processor-Specific)
NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

4-28

OBJECT FILESDRAFT COPY
March 18, 1997
File: chap4
386:adm.book:sum
Page: 72

5

PROGRAM LOADING AND
DYNAMIC LINKING

Introduction

5-1

Program Header
Base Address
Segment Permissions
Segment Contents
Note Section

5-2
5-5
5-5
5-7
5-8

Program Loading (Processor-Specific)

5-11

Dynamic Linking

5-12
5-12
5-13
5-14
5-19
5-21
5-21
5-21
5-22

Program Interpreter
Dynamic Linker
Dynamic Section
Shared Object Dependencies
Global Offset Table (Processor-Specific)
Procedure Linkage Table (Processor-Specific)
Hash Table
Initialization and Termination Functions

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cchap5
386:adm.book:sum
Page: 73

Introduction
This chapter describes the object file information and system actions that create
running programs. Some information here applies to all systems; information
specific to one processor resides in sections marked accordingly.
Executable and shared object files statically represent programs. To execute suchprograms, the system uses the files to create dynamic program representations, orprocess images. As section ‘‘Virtual Address Space’’ in Chapter 3 of the processor
supplement describes, a process image has segments that hold its text, data, stack,and so on. This chapter’s major sections discuss the following.
Program header. This section complements Chapter 4, describing object filestructures that relate directly to program execution. The primary data
structure, a program header table, locates segment images within the fileand contains other information necessary to create the memory image forthe program.
Program loading. Given an object file, the system must load it into memory
for the program to run.
Dynamic linking. After the system loads the program, it must complete theprocess image by resolving symbolic references among the object files thatcompose the process.

NOTE

The processor supplement defines a naming convention for ELF constants
that have processor ranges specified. Names such as DT_, PT_, for processor specific extensions, incorporate the name of the processor:
DT_M32_SPECIAL, for example. Pre–existing processor extensions notusing this convention will be supported.







Pre-existing
Extensions_____________________



DT_JMP_RELIntroduction

5-1

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 74

Program Header
An executable or shared object file’s program header table is an array of structures, each describing a segment or other information the system needs to prepare
the program for execution. An object file segment contains one or more sections, as‘‘Segment Contents’’ describes below. Program headers are meaningful only forexecutable and shared object files. A file specifies its own program header sizewith the ELF header’s e_phentsize and e_phnum members [see ‘‘ELF Header’’ in
Chapter 4].
Figure 5-1: Program Header

typedef struct {Elf32_Word
Elf32_Off
Elf32_Addr
Elf32_Addr
Elf32_Word
Elf32_Word
Elf32_Word
Elf32_Word} Elf32_Phdr;

p_type;p_offset;
p_vaddr;p_paddr;p_filesz;
p_memsz;
p_flags;p_align;p_typeThis member tells what kind of segment this array element
describes or how to interpret the array element’s information.
Type values and their meanings appear below.

p_offsetThis member gives the offset from the beginning of the file atwhich the first byte of the segment resides.

p_vaddrThis member gives the virtual address at which the first byte of
the segment resides in memory.

p_paddr

On systems for which physical addressing is relevant, thismember is reserved for the segment’s physical address. Because
System V ignores physical addressing for application programs,
this member has unspecified contents for executable files andshared objects.

5-2

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 75

p_fileszThis member gives the number of bytes in the file image of thesegment; it may be zero.

p_memsz

This member gives the number of bytes in the memory image ofthe segment; it may be zero.

p_flags

This member gives flags relevant to the segment. Defined flagvalues appear below.

p_alignAs ‘‘Program Loading’’ describes in this chapter of the processor
supplement, loadable process segments must have congruent
values for p_vaddr and p_offset, modulo the page size. Thismember gives the value to which the segments are aligned inmemory and in the file. Values 0 and 1 mean no alignment isrequired. Otherwise, p_align should be a positive, integral
power of 2, and p_vaddr should equal p_offset, modulo
p_align.

Some entries describe process segments; others give supplementary informationand do not contribute to the process image. Segment entries may appear in any
order, except as explicitly noted below. Defined type values follow; other values
are reserved for future use.
Figure 5-2: Segment Types, p_type

Name
Value
_________________________

PT_NULL
0
PT_LOAD1
PT_DYNAMIC 
2
PT_INTERP 
3
PT_NOTE4

PT_SHLIB
5
PT_PHDR
6

PT_LOPROC  0x70000000
PT_HIPROC  0x7fffffff_________________________


PT_NULL

The array element is unused; other members’ values are
undefined. This type lets the program header table have ignored
entries.

PT_LOAD

The array element specifies a loadable segment, described by
p_filesz and p_memsz. The bytes from the file are mapped tothe beginning of the memory segment. If the segment’s memory
size (p_memsz) is larger than the file size (p_filesz), the ‘‘extra’’

Program Header

5-3

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 76

bytes are defined to hold the value 0 and to follow the segment’s
initialized area. The file size may not be larger than the memory
size. Loadable segment entries in the program header tableappear in ascending order, sorted on the p_vaddr member.
PT_DYNAMIC

The array element specifies dynamic linking information. See‘‘Dynamic Section’’ below for more information.

PT_INTERP

The array element specifies the location and size of a nullterminated path name to invoke as an interpreter. This segment
type is meaningful only for executable files (though it may occur
for shared objects); it may not occur more than once in a file. If it
is present, it must precede any loadable segment entry. See ‘‘Program Interpreter’’ below for further information.

PT_NOTE

The array element specifies the location and size of auxiliary
information. See ‘‘Note Section’’ below for details.

PT_SHLIB

This segment type is reserved but has unspecified semantics. Programs that contain an array element of this type do not conformto the ABI.

PT_PHDR

The array element, if present, specifies the location and size of the
program header table itself, both in the file and in the memory
image of the program. This segment type may not occur morethan once in a file. Moreover, it may occur only if the program
header table is part of the memory image of the program. If it ispresent, it must precede any loadable segment entry. See ‘‘Program Interpreter’’ below for further information.

PT_LOPROC through PT_HIPROC
Values in this inclusive range are reserved for processor-specificsemantics. If meanings are specified, the processor supplement
explains them.

NOTE

5-4

Unless specifically required elsewhere, all program header segment types are
optional. That is, a file’s program header table may contain only those elements relevant to its contents.

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 77

Base AddressAs ‘‘Program Loading’’ in this chapter of the processor supplement describes, thevirtual addresses in the program headers might not represent the actual virtual
addresses of the program’s memory image. Executable files typically containabsolute code. To let the process execute correctly, the segments must reside atthe virtual addresses used to build the executable file. On the other hand, sharedobject segments typically contain position-independent code. This lets a segment’s
virtual address change from one process to another, without invalidating execution behavior. Though the system chooses virtual addresses for individual
processes, it maintains the segments’ relative positions. Because positionindependent code uses relative addressing between segments, the difference
between virtual addresses in memory must match the difference between virtual
addresses in the file. The difference between the virtual address of any segment inmemory and the corresponding virtual address in the file is thus a single constantvalue for any one executable or shared object in a given process. This difference isthe base address. One use of the base address is to relocate the memory image ofthe program during dynamic linking.
An executable or shared object file’s base address is calculated during execution
from three values: the virtual memory load address, the maximum page size, andthe lowest virtual address of a program’s loadable segment. To compute the baseaddress, one determines the memory address associated with the lowest p_vaddr
value for a PT_LOAD segment. This address is truncated to the nearest multiple ofthe maximum page size. The corresponding p_vaddr value itself is also truncatedto the nearest multiple of the maximum page size. The base address is the difference between the truncated memory address and the truncated p_vaddr value.
See this chapter in the processor supplement for more information and examples.
‘‘Operating System Interface’’ of Chapter 3 in the processor supplement contains
more information about the virtual address space and page size.

Segment Permissions
A program to be loaded by the system must must have at least one loadable segment (although this is not required by the file format). When the system createsloadable segments’ memory images, it gives access permissions as specified in the
p_flags member.

Program Header

5-5

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 78

E
E
E
E
E
E
E
E
E
E
E
E
E
E
E

M
E
E
E
E

Figure 5-3: Segment Flag Bits, p_flags

Name
Value
Meaning________________________________________
PF_X
0x1  Execute
PF_W
0x2  Write
PF_R
0x4  Read
PF_MASKPROC  0xf0000000  Unspecified________________________________________
All bits included in the PF_MASKPROC mask are reserved for processor-specificsemantics. If meanings are specified, the processor supplement explains them.
If a permission bit is 0, that type of access is denied. Actual memory permissions
depend on the memory management unit, which may vary from one system toanother. Although all flag combinations are valid, the system may grant moreaccess than requested. In no case, however, will a segment have write permission
unless it is specified explicitly. The following table shows both the exact flaginterpretation and the allowable flag interpretation. ABI-conforming systems may
provide either.
Figure 5-4: Segment Permissions

Flags
Value
Exact
Allowable___________________________________________________________________



none
0
All access denied
All access denied
 1
 Execute only
 Read, execute
PF_X



PF_W
 2
 Write only
 Read, write, execute
PF_W + PF_X
 3
 Write, execute Read, write, executePF_R 4 Read only
 Read, execute 5
 Read, execute Read, execute
PF_R + PF_X Read, write, execute
PF_R + PF_W
6
Read, write
PF_R + PF_W + PF_X
7
Read, write, execute
Read, write, execute___________________________________________________________________For example, typical text segments have read and execute—but not write—
permissions. Data segments normally have read, write, and execute permissions.

5-6

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 79

Segment Contents
An object file segment comprises one or more sections, though this fact is transparent to the program header. Whether the file segment holds one or many sections also is immaterial to program loading. Nonetheless, various data must bepresent for program execution, dynamic linking, and so on. The diagrams below
illustrate segment contents in general terms. The order and membership of sections within a segment may vary; moreover, processor-specific constraints mayalter the examples below. See the processor supplement for details.
Text segments contain read-only instructions and data, typically including the following sections described in Chapter 4. Other sections may also reside in loadable
segments; these examples are not meant to give complete and exclusive segment
contents.
Figure 5-5: Text Segment___________
___________.text .rodata 
___________.hash ___________
 .dynsym ___________
.dynstr 
___________
___________

.plt


.rel.got 
___________

Data segments contain writable data and instructions, typically including the following sections.
Figure 5-6: Data Segment___________
___________.data .dynamic 
___________.got___________
 .bss
___________

A PT_DYNAMIC program header element points at the .dynamic section, explainedin ‘‘Dynamic Section’’ below. The .got and .plt sections also hold information
related to position-independent code and dynamic linking. Although the .plt
appears in a text segment above, it may reside in a text or a data segment,

Program Header

5-7

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 80depending on the processor. See ‘‘Global Offset Table’’ and ‘‘Procedure Linkage
Table’’ in this chapter of the processor supplement for details.
As ‘‘Sections’’ in Chapter 4 describes, the .bss section has the type SHT_NOBITS.
Although it occupies no space in the file, it contributes to the segment’s memory
image. Normally, these uninitialized data reside at the end of the segment,
thereby making p_memsz larger than p_filesz in the associated program header
element.

Note Section
Sometimes a vendor or system builder needs to mark an object file with special
information that other programs will check for conformance, compatibility, etc.
Sections of type SHT_NOTE and program header elements of type PT_NOTE can beused for this purpose. The note information in sections and program header elements holds any number of entries, each of which is an array of 4-byte words inthe format of the target processor. Labels appear below to help explain note information organization, but they are not part of the specification.
Figure 5-7: Note Information_________
_________
namesz descsz 
_________
type 
_________
 name 
. . . 
_________ desc . . . _________


namesz and name
The first namesz bytes in name contain a null-terminated character
representation of the entry’s owner or originator. There is no formal
mechanism for avoiding name conflicts. By convention, vendors use
their own name, such as ‘‘XYZ Computer Company,’’ as the identifier.
If no name is present, namesz contains 0. Padding is present, if necessary, to ensure 4-byte alignment for the descriptor. Such padding is
not included in namesz.

5-8

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 81

descsz and desc
The first descsz bytes in desc hold the note descriptor. The ABI
places no constraints on a descriptor’s contents. If no descriptor ispresent, descsz contains 0. Padding is present, if necessary, to ensure
4-byte alignment for the next note entry. Such padding is notincluded in descsz.
typeThis word gives the interpretation of the descriptor. Each originator
controls its own types; multiple interpretations of a single type value
may exist. Thus, a program must recognize both the name and thetype to ‘‘understand’’ a descriptor. Types currently must be nonnegative. The ABI does not define what descriptors mean.

To illustrate, the following note segment holds two entries.
Figure 5-8: Example Note Segment

nameszdescsztype
namenameszdescsz
type
name
desc

NOTE

+0
+1
+2
+3
______________________
______________________

7


0
______________________
 No descriptor
1
______________________
 X  Y  Z ______________________C  o  \0  pad _____________________
_______________________
______________________

7


8
______________________3

______________________
 X  Y  Z ______________________C  o  \0  pad 
______________________
______________________
word 0word 1
______________________
The system reserves note information with no name (namesz= =0) and with azero-length name (name[0]= =’\0’) but currently defines no types. All othernames must have at least one non-null character.

Program Header

5-9

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 82

NOTE

5-10

Note information is optional. The presence of note information does not affecta program’s ABI conformance, provided the information does not affect the
program’s execution behavior. Otherwise, the program does not conform to
the ABI and has undefined behavior.

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 83

Program Loading (Processor-Specific)

NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

Program Loading (Processor-Specific)

5-11

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 84

Dynamic Linking
Program Interpreter
An executable file that participates in dynamic linking shall have one PT_INTERP
program header element. During the function exec, the system retrieves a pathname from the PT_INTERP segment and creates the initial process image from theinterpreter file’s segments. That is, instead of using the original executable file’s
segment images, the system composes a memory image for the interpreter. It thenis the interpreter’s responsibility to receive control from the system and provide
an environment for the application program.

E
XAs ‘‘Process Initialization’’ in Chapter 3 of the processor supplement mentions, theinterpreter receives control in one of two ways. First, it may receive a file descriptor to read the executable file, positioned at the beginning. It can use this filedescriptor to read and/or map the executable file’s segments into memory.
Second, depending on the executable file format, the system may load the executable file into memory instead of giving the interpreter an open file descriptor.
With the possible exception of the file descriptor, the interpreter’s initial processstate matches what the executable file would have received. The interpreter itself
may not require a second interpreter. An interpreter may be either a shared object
or an executable file.
A shared object (the normal case) is loaded as position-independent, withaddresses that may vary from one process to another; the system creates its
segments in the dynamic segment area used by the function mmap andrelated services [see ‘‘Virtual Address Space’’ in Chapter 3 of the processor
supplement]. Consequently, a shared object interpreter typically will notconflict with the original executable file’s original segment addresses.
An executable file is loaded at fixed addresses; the system creates its segments using the virtual addresses from the program header table. Consequently, an executable file interpreter’s virtual addresses may collide withthe first executable file; the interpreter is responsible for resolving conflicts.

5-12

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 85X

Dynamic Linker
When building an executable file that uses dynamic linking, the link editor adds a
program header element of type PT_INTERP to an executable file, telling the system to invoke the dynamic linker as the program interpreter.

The locations of the system provided dynamic linkers are processor–specific.
NOTE

Exec and the dynamic linker cooperate to create the process image for the program, which entails the following actions:
Adding the executable file’s memory segments to the process image;
Adding shared object memory segments to the process image;
Performing relocations for the executable file and its shared objects;
Closing the file descriptor that was used to read the executable file, if one
was given to the dynamic linker;
Transferring control to the program, making it look as if the program hadreceived control directly from the function exec
The link editor also constructs various data that assist the dynamic linker for executable and shared object files. As shown above in ‘‘Program Header,’’ these data
reside in loadable segments, making them available during execution. (Onceagain, recall the exact segment contents are processor-specific. See the processor
supplement for complete information.)A .dynamic section with type SHT_DYNAMIC holds various data. The structure residing at the beginning of the section holds the addresses of otherdynamic linking information.
The .hash section with type SHT_HASH holds a symbol hash table.
The .got and .plt sections with type SHT_PROGBITS hold two separate
tables: the global offset table and the procedure linkage table. Chapter 3
discusses how programs use the global offset table for position-independentcode. Sections below explain how the dynamic linker uses and changes thetables to create memory images for object files.

Dynamic Linking

5-13

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 86X

Because every ABI-conforming program imports the basic system services from ashared object library [see ‘‘System Library’’ in Chapter 6], the dynamic linker participates in every ABI-conforming program execution.
As ‘‘Program Loading’’ explains in the processor supplement, shared objects may
occupy virtual memory addresses that are different from the addresses recordedin the file’s program header table. The dynamic linker relocates the memory
image, updating absolute addresses before the application gains control.
Although the absolute address values would be correct if the library were loadedat the addresses specified in the program header table, this normally is not thecase.
If the process environment [see the function exec] contains a variable named
LD_BIND_NOW with a non-null value, the dynamic linker processes all relocation
before transferring control to the program. For example, all the following
environment entries would specify this behavior.
LD_BIND_NOW=1
LD_BIND_NOW=on
LD_BIND_NOW=off
Otherwise, LD_BIND_NOW either does not occur in the environment or has a nullvalue. The dynamic linker is permitted to evaluate procedure linkage table entries
lazily, thus avoiding symbol resolution and relocation overhead for functions thatare not called. See ‘‘Procedure Linkage Table’’ in this chapter of the processor
supplement for more information.

Dynamic Section
If an object file participates in dynamic linking, its program header table will havean element of type PT_DYNAMIC. This ‘‘segment’’ contains the .dynamic section.
A special symbol, _DYNAMIC, labels the section, which contains an array of the following structures.

5-14

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 87X

Figure 5-9: Dynamic Structure

typedef struct {Elf32_Swordd_tag;
union {
Elf32_Word
Elf32_Addr} d_un;} Elf32_Dyn;
extern Elf32_Dyn

d_val;
d_ptr;_DYNAMIC[];For each object with this type, d_tag controls the interpretation of d_un.
d_val

These Elf32_Word objects represent integer values with various
interpretations.

d_ptr

These Elf32_Addr objects represent program virtual addresses. As
mentioned previously, a file’s virtual addresses might not match thememory virtual addresses during execution. When interpreting
addresses contained in the dynamic structure, the dynamic linker
computes actual addresses, based on the original file value and thememory base address. For consistency, files do not contain relocation
entries to ‘‘correct’’ addresses in the dynamic structure.

The following table summarizes the tag requirements for executable and sharedobject files. If a tag is marked ‘‘mandatory,’’ then the dynamic linking array for an
ABI-conforming file must have an entry of that type. Likewise, ‘‘optional’’ meansan entry for the tag may appear but is not required.
Figure 5-10: Dynamic Array Tags, d_tag

Name
Value
d_un
Executable
Shared Object____________________________________________________________________
 mandatory  mandatory
DT_NULL
0  ignored optional optional
DT_NEEDED
1  d_val

DT_PLTRELSZ 
2  d_val
 optional optional
DT_PLTGOT
3
d
_
p
t
r
optional optional
DT_HASH4  d_ptr
 mandatory  mandatory mandatory  mandatory
DT_STRTAB
5  d_ptr
 mandatory  mandatory
DT_SYMTAB
6  d_ptr

Dynamic Linking

5-15

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 88

Figure 5-10: Dynamic Array Tags, d_tag (continued )

Name
Value
d_un
Executable
Shared Object____________________________________________________________________
 mandatory  optional
DT_RELA‡7  d_ptr
 mandatory  optional
DT_RELASZ
8  d_val

DT_RELAENT 
9  d_val
 mandatory  optional
DT_STRSZ
10  d_val
 mandatory  mandatory mandatory  mandatory
DT_SYMENT11  d_val optional optional
DT_INIT12  d_ptr
 optional optional
DT_FINI13  d_ptr

DT_SONAME
14  d_val
 ignored optional
DT_RPATH
1
5
d
_
v
a
l
optional ignored ignored optional
DT_SYMBOLIC 
16  ignored mandatory  optional
DT_REL†17  d_ptr mandatory  optional
DT_RELSZ
18  d_val

DT_RELENT
19  d_val
 mandatory  optional
DT_PLTREL
20  d_val optional optional optional ignored
DT_DEBUG
21  d_ptr
 optional optional
DT_TEXTREL 
22  ignored optional optional
DT_JMPREL
23  d_ptr

DT_BIND_NOW 
24  ignored optional optional
DT_LOPROC
0
x
7
0
0
0
0
0
0
0
unspecified
unspecified unspecified
DT_HIPROC
 0x7fffffff  unspecified  unspecified  unspecified____________________________________________________________________
† See the description of DT_RELA and DT_REL below for the relationship between these
two tags.

DT_NULL

An entry with a DT_NULL tag marks the end of the _DYNAMIC
array.

DT_NEEDEDThis element holds the string table offset of a null-terminatedstring, giving the name of a needed library. The offset is an index
into the table recorded in the DT_STRTAB entry. See ‘‘Shared
Object Dependencies’’ for more information about these names.
The dynamic array may contain multiple entries with this type.
These entries’ relative order is significant, though their relation to
entries of other types is not.

DT_PLTRELSZThis element holds the total size, in bytes, of the relocation entries
associated with the procedure linkage table. If an entry of type
DT_JMPREL is present, a DT_PLTRELSZ must accompany it.

5-16

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 89

M

M

DT_PLTGOTThis element holds an address associated with the procedure linkage table and/or the global offset table. See this section in theprocessor supplement for details.

DT_HASH

This element holds the address of the symbol hash table,
described in ‘‘Hash Table.’’ This hash table refers to the symbol
table referenced by the DT_SYMTAB element.

DT_STRTAB

This element holds the address of the string table, described in
Chapter 4. Symbol names, library names, and other strings residein this table.

DT_SYMTAB

This element holds the address of the symbol table, described in
Chapter 4, with Elf32_Sym entries for the 32-bit class of files.

DT_RELAThis element holds the address of a relocation table, described in
Chapter 4. Entries in the table have explicit addends, such as
Elf32_Rela for the 32-bit file class. An object file may have multiple relocation sections. When building the relocation table foran executable or shared object file, the link editor catenates thosesections to form a single table. Although the sections remain
independent in the object file, the dynamic linker sees a single
table. When the dynamic linker creates the process image for an
executable file or adds a shared object to the process image, it
reads the relocation table and performs the associated actions. If
this element is present, the dynamic structure must also have
DT_RELASZ and DT_RELAENT elements. When relocation is ‘‘mandatory’’ for a file, either DT_RELA or DT_REL must occur (both arepermitted but only one is required).

DT_RELASZThis element holds the total size, in bytes, of the DT_RELA relocation table.

DT_RELAENTThis element holds the size, in bytes, of the DT_RELA relocation
entry.

DT_STRSZThis element holds the size, in bytes, of the string table.

DT_SYMENTThis element holds the size, in bytes, of a symbol table entry.

DT_INIT

This element holds the address of the initialization function, discussed in ‘‘Initialization and Termination Functions’’ below.

DT_FINI

This element holds the address of the termination function, discussed in ‘‘Initialization and Termination Functions’’ below.

Dynamic Linking

5-17

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 90

M

DT_SONAME

This element holds the string table offset of a null-terminatedstring, giving the name of the shared object. The offset is an index
into the table recorded in the DT_STRTAB entry. See ‘‘Shared
Object Dependencies’’ below for more information about thesenames.

DT_RPATH

This element holds the string table offset of a null-terminatedsearch library search path string, discussed in ‘‘Shared Object
Dependencies.’’ The offset is an index into the table recorded in
the DT_STRTAB entry.

DT_SYMBOLIC

This element’s presence in a shared object library alters the
dynamic linker’s symbol resolution algorithm for references
within the library. Instead of starting a symbol search with theexecutable file, the dynamic linker starts from the shared object
itself. If the shared object fails to supply the referenced symbol,
the dynamic linker then searches the executable file and othershared objects as usual.

DT_REL

This element is similar to DT_RELA, except its table has implicit
addends, such as Elf32_Rel for the 32-bit file class. If this element is present, the dynamic structure must also have DT_RELSZ
and DT_RELENT elements.

DT_RELSZ

This element holds the total size, in bytes, of the DT_REL relocation table.

DT_RELENTThis element holds the size, in bytes, of the DT_REL relocation
entry.

DT_PLTREL

This member specifies the type of relocation entry to which theprocedure linkage table refers. The d_val member holds DT_REL
or DT_RELA, as appropriate. All relocations in a procedure linkage table must use the same relocation.

DT_DEBUG

This member is used for debugging. Its contents are not specified
for the ABI; programs that access this entry are not ABIconforming.

DT_TEXTRELThis member’s absence signifies that no relocation entry shouldcause a modification to a non-writable segment, as specified by
the segment permissions in the program header table. If thismember is present, one or more relocation entries might request
modifications to a non-writable segment, and the dynamic linker
can prepare accordingly.

5-18

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 91

DT_JMPREL

If present, this entries’ d_ptr member holds the address of relocation entries associated solely with the procedure linkage table.
Separating these relocation entries lets the dynamic linker ignore
them during process initialization, if lazy binding is enabled. If
this entry is present, the related entries of types DT_PLTRELSZ and
DT_PLTREL must also be present.

DT_BIND_NOW

If present in a shared object or executable, this entry instructs the
dynamic linker to process all relocations for the object containing
this entry before transferring control to the program. The presence of this entry takes precedence over a directive to use lazybinding for this object when specified through the environment or
via dlopen(BA_LIB).

M
M
M
M
M

DT_LOPROC through DT_HIPROC
Values in this inclusive range are reserved for processor-specificsemantics. If meanings are specified, the processor supplement
explains them.
Except for the DT_NULL element at the end of the array, and the relative order of
DT_NEEDED elements, entries may appear in any order. Tag values not appearing
in the table are reserved.

Shared Object Dependencies
When the link editor processes an archive library, it extracts library members andcopies them into the output object file. These statically linked services are available during execution without involving the dynamic linker. Shared objects also
provide services, and the dynamic linker must attach the proper shared object files
to the process image for execution.
When the dynamic linker creates the memory segments for an object file, thedependencies (recorded in DT_NEEDED entries of the dynamic structure) tell whatshared objects are needed to supply the program’s services. By repeatedly connecting referenced shared objects and their dependencies, the dynamic linker
builds a complete process image. When resolving symbolic references, thedynamic linker examines the symbol tables with a breadth-first search. That is, it
first looks at the symbol table of the executable program itself, then at the symbol
tables of the DT_NEEDED entries (in order), then at the second level DT_NEEDED
entries, and so on. Shared object files must be readable by the process; other permissions are not required.

Dynamic Linking

5-19

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 92

M

NOTE

Even when a shared object is referenced multiple times in the dependency
list, the dynamic linker will connect the object only once to the process.

Names in the dependency list are copies either of the DT_SONAME strings or thepath names of the shared objects used to build the object file. For example, if thelink editor builds an executable file using one shared object with a DT_SONAME
entry of lib1 and another shared object library with the path name/usr/lib/lib2, the executable file will contain lib1 and /usr/lib/lib2 in its
dependency list.
If a shared object name has one or more slash (/) characters anywhere in thename, such as /usr/lib/lib2 above or directory/file, the dynamic linker
uses that string directly as the path name. If the name has no slashes, such aslib1 above, three facilities specify shared object path searching, with the following precedence.
First, the dynamic array tag DT_RPATH may give a string that holds a list of
directories, separated by colons (:). For example, the string/home/dir/lib:/home/dir2/lib: tells the dynamic linker to search firstthe directory /home/dir/lib, then /home/dir2/lib, and then the current
directory to find dependencies.
Second, a variable called LD_LIBRARY_PATH in the process environment [seethe function exec] may hold a list of directories as above, optionally followed by a semicolon (;) and another directory list. The following values
would be equivalent to the previous example:
LD_LIBRARY_PATH=/home/dir/lib:/home/dir2/lib:
LD_LIBRARY_PATH=/home/dir/lib;/home/dir2/lib:
LD_LIBRARY_PATH=/home/dir/lib:/home/dir2/lib:;
All LD_LIBRARY_PATH directories are searched after those from DT_RPATH.
Although some programs (such as the link editor) treat the lists before andafter the semicolon differently, the dynamic linker does not. Nevertheless,the dynamic linker accepts the semicolon notation, with the semantics
described above.
Finally, if the other two groups of directories fail to locate the desired
library, the dynamic linker searches /usr/lib.

5-20

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 93XNOTE

For security, the dynamic linker ignores environmental search specifications(such as LD_LIBRARY_PATH) for set-user and set-group ID programs. It does,
however, search DT_RPATH directories and /usr/lib. The same restriction
may be applied to processes that have more than minimal privileges on systems with installed extended security systems.

M
M

Global Offset Table (Processor-Specific)
NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

Procedure Linkage Table (Processor-Specific)
NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

Hash Table
A hash table of Elf32_Word objects supports symbol table access. Labels appear
below to help explain the hash table organization, but they are not part of thespecification.
Figure 5-11: Symbol Hash Table______________________
______________________

nbucketnchain______________________

bucket[0]



. . .
 bucket[nbucket - 1] 
______________________
chain[0]



. . .

______________________
chain[nchain - 1] 

Dynamic Linking

5-21

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 94

The bucket array contains nbucket entries, and the chain array contains nchain
entries; indexes start at 0. Both bucket and chain hold symbol table indexes.
Chain table entries parallel the symbol table. The number of symbol table entries
should equal nchain; so symbol table indexes also select chain table entries. A
hashing function (shown below) accepts a symbol name and returns a value that
may be used to compute a bucket index. Consequently, if the hashing function
returns the value x for some name, bucket[x%nbucket] gives an index, y, into
both the symbol table and the chain table. If the symbol table entry is not the one
desired, chain[y] gives the next symbol table entry with the same hash value.
One can follow the chain links until either the selected symbol table entry holds
the desired name or the chain entry contains the value STN_UNDEF.
Figure 5-12: Hashing Function

unsigned long
elf_hash(const unsigned char *name){unsigned longh = 0, g;while (*name){h = (h << 4) + *name++;if (g = h & 0xf0000000)
h ˆ= g >> 24;
h &= ˜g;}return h;}Initialization and Termination Functions
After the dynamic linker has built the process image and performed the relocations, each shared object gets the opportunity to execute some initialization code.
All shared object initializations happen before the executable file gains control.
Before the initialization code for any object A is called, the initialization code forany other objects that object A depends on are called. For these purposes, anobject A depends on another object B, if B appears in A’s list of needed objects(recorded in the DT_NEEDED entries of the dynamic structure). The order of initialization for circular dependencies is undefined.

5-22

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 95

M
M
M
M
M

The initialization of objects occurs by recursing through the needed entries of eachobject. The initialization code for an object is invoked after the needed entries forthat object have been processed. The order of processing among the entries of aparticular list of needed objects is unspecified.
NOTE

Each processor supplement may optionally further restrict the algorithm used
to determine the order of initialization. Any such restriction, however, may not
conflict with the rules described by this specification.

MM
MM
M
MM

The following example illustrates two of the possible correct orderings which canbe generated for the example NEEDED lists. In this example the a.out is dependent on b, d, and e. b is dependent on d and f, while d is dependent on e and g.
From this information a dependency graph can be drawn. The above algorithm
on initialization will then allow the following specified initialization orderings
among others.

Dynamic Linking

5-23

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 96

M
M
M
M

M
M
M
M
M

Initialization Ordering Example

5-24

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 97

Figure 5-13: Initialization Ordering Example

NEEDED Lists

Dependency Graph

a.out

b

d

a.out

b

d

e

b

d

d

f

g

f

g

e

g

d

f

b

a.out

g

f

e

d

b

a.out

e

e

Init Orderings:

Dynamic Linking

5-25

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 98

Similarly, shared objects may have termination functions, which are executed withthe function atexit mechanism after the base process begins its termination
sequence. The order in which the dynamic linker calls termination functions is theexact reverse order of their corresponding initialization functions. If a sharedobject has a termination function, but no initialization function, the termination
function will execute in the order it would have as if the shared object’s initialization function was present. The dynamic linker ensures that it will not execute any
initialization or termination functions more than once.

X
M
M
M
M
M

Shared objects designate their initialization and termination functions through the
DT_INIT and DT_FINI entries in the dynamic structure, described in ‘‘Dynamic
Section’’ above. Typically, the code for these functions resides in the .init and.fini sections, mentioned in ‘‘Sections’’ of Chapter 4.
NOTE

Although the function atexit termination processing normally will be done, it
is not guaranteed to have executed upon process death. In particular, theprocess will not execute the termination processing if it calls _exit [see thefunction exit] or if the process dies because it received a signal that it neither
caught nor ignored.

X

The dynamic linker is not responsible for calling the executable file’s .init section or registering the executable file’s .fini section with the function atexit.
Termination functions specified by users via the atexit mechanism must be executed before any termination functions of shared objects.

5-26

PROGRAM LOADING AND DYNAMIC LINKING

DRAFT COPY
March 18, 1997
File: chap5
386:adm.book:sum
Page: 99

M
M
M

6

LIBRARIESIntroduction
Shared Library Names
Dependencies Among Libraries
System Service Synonyms

C Library

6-1
6-3
6-3
6-3

Implementation of libc Routines
Vendor Extensions

6-5
6-10
6-11
6-11
6-13
6-13
6-14

Threads Library

6-15

Dynamic Linking Library

6-17

Network Services Library

6-18

Socket Library

6-21

Additional Entry Points (Processor-Specific)
Support Routines (Processor-Specific)
Global Data Symbols
Application Constraints

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cchap6
386:adm.book:sum
Page: 100

Curses Library

6-22

X Window System Library

6-26

X11 Nonrectangular Window Shape
Extension Library

6-33

X Toolkit Intrinsics Library

6-34

Motif Libraries

6-38

System Data Interfaces

6-46
6-46
6-47

Required Sizes for Some Data Objects
Data Definitions (Processor-Specific)

ii

Table of Contents

DRAFT COPY
March 18, 1997
File: Cchap6
386:adm.book:sum
Page: 101

Introduction
Every ABI-conforming system supports some general-purpose libraries. Facilities
in these libraries manipulate system data files, trap to the operating system, and soon. Together, these libraries hold routines appearing in sections BA_OS, BA_LIB,
KE_OS, RS_LIB, and MT_LIB of the System V Interface Definition, Fourth Edition.
libc

The C library, containing various facilities defined by System V, ANSIC, ISO MSE, POSIX, and so on. It contains interfaces to basic systemservices.

M

The thread library, containing interfaces to support multiprocessing
applications and asynchronous I/O operations included in the MT
extension of the System V Interface Definition, Fourth Edition.

M
M
M
M

libthreadlibdl

The dynamic linking library, containing routines that give the user
direct access to the dynamic linking facilities.

M

libnslThe networking services library, contains the transport layer interface
routines, as well as routines for machine-independent data representation, remote procedure calls, and other networking support. Theseroutines are described in the Networking Services volume of the
X/Open CAE Specification, Issue 4.2, and the BA_OS and RS_LIB sectionsof the System V Interface Definition, Fourth Edition (see the Conformance
Rule in chapter1).

X
X
X
X
X
X

A library containing the sockets routines as described in the Networking Services volume of the X/Open CAE Specification, Issue 4.2.

XX

libsocket

X
X
X

libcurses
This library provides routines for updating character screens as
described in the X/Open Curses, Issue 4 of the X/Open CAE
Specification, Issue 4.2.
The following libraries may be supported as extensions to the ABI.

G

libX

A library for building applications using the X11 Window System protocol described in the Graphics chapter.

G
G

libXt

A library for building applications using the X Toolkit Intrinsics.

G

Introduction

6-1

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 102

libXext

A library for building applications using the X11 Nonrectangular Window Shape Extension.

M
M

libXm

A library for building applications using the Motif 1.2 Interface.

M

libMrmA library containing the resource manager for the Motif 1.2 Interface.

M

NOTE

libsys has been removed from the Application Binary Interface. Originallylibsys was devised as a subset of libc functionality comprised of a usefulsuperset of system calls. Difficulties in the division between the two libraries,
additional maintenance efforts and lack of use of libsys by applications
pointing to the ABI have led to the elimination of the library from the ABI.

M
M
M

As a binary specification, the ABI gives shared library organization; that is, it tells
what services reside in what shared libraries. Programs use the dynamic linking
mechanism described in Chapter 5 to access their services.
The ABI does not duplicate the descriptions available in the X/Open CAE
Specification, Issue 4.2 and the System V Interface Definition, Fourth Edition and otherreferences that tell what the facilities do, how to use them, and so on. However,
the interfaces to some services may have different names and syntax at the systemlevel than they do at the source level. When these differences exist, this document(the System V ABI) specifies the name of the source-level services that must be supported on conforming systems, and the names and descriptions of these interfaces
are given in each processor supplement to the ABI.

X

Shared libraries contribute to the application execution environment and thus
appear in the ABI. Functions that reside directly in application files are notspecified. For example, mathematical routines, such as sin, do not appear below.
They would be available in a System V development environment, but anapplication’s executable file would contain the associated code. Assuming theimplementations of the functions themselves are ABI-conforming, their presence
does not affect the conformance of the application. Moreover, the absence ofshared library versions of particular services does not imply a deprecation of thoseservices.
The ABI requires conforming applications to use the dynamic linking mechanism
described in Chapter 5 to access the services provided in the C Library, libc, theDynamic Linking Library, libdl, the threads Library, libthread, and in the Networking Services Library, libnsl. In addition, on systems that support thegraphical windowing terminal interface, the dynamic linking mechanism must be
used to access the X Window System Library services, libX. Use of the othershared libraries documented here is optional for applications; the services they
contain may be obtained through the use of equivalent archive library routines.
An application that accesses ABI services from both the shared library and thestatic archive version of the same library is not ABI conforming.

6-2

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 103

M
M
M

E
E

Shared Library Names
As Chapter 5 describes, executable and shared object files contain the names ofrequired shared libraries. In the names below, number represents the current version number of the library. The version number of each library is specified in the
ABI supplement for the desired processor.

M
M

Figure 6-1: Shared Library Names

Library
Reference Name_____________________________________________________________________________
 /usr/lib/libc.so.number
libc /usr/lib/libthread.so.numberM
libthread
libdlM /usr/lib/libdl.so.number
libnsl
/
u
s
r
/
l
i
b
/
l
i
b
n
s
l
.
s
o
.
n
u
m
b
e
r

libsocket/usr/lib/libsocket.so.2 Xlibcurses/usr/lib/libcurses.so.1 X /usr/lib/libX11.so.number
libX

libXt
G
 /usr/lib/libXt.so.number
libXext
/
u
s
r
/
l
i
b
/
l
i
b
X
e
x
t
.
s
o
.
n
u
m
b
e
r
M

 /usr/lib/libXm.so.number
libXm
M

l
i
b
M
r
m
/
u
s
r
/
l
i
b
/
l
i
b
M
r
m
.
s
o
.
n
u
m
b
e
r
M
_____________________________________________________________________________


Dependencies Among Libraries
System libraries may depend on other libraries both defined by the ABI and not
defined by the ABI. The runtime environment should not require that suchdependencies be reflected in the executable if the executable itself does not haveany dependencies on those libraries.

System Service Synonyms
In addition to the routine names listed in the tables below, the C library includes
synonyms for some of its services. These other symbols are available to conformto language and system standards. As an example, System V defines read as thename of an operating system facility. On the other hand, ANSI C does not define
read, and it prohibits a strictly conforming implementation from usurping application names without a leading underscore ( _ ). Thus if a synonym for read were
not available, the system could not support a strictly conforming implementationof the ANSI C language.

Introduction

6-3

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 104

M
M
M

name

This gives the traditional name, such as read.

_nameThis gives a system service name that follows the ANSI C conventionof reserving symbols beginning with an underscore, such as _read.

The title of each of the below tables specifies whether synonyms must exist for theentries in that table.
Although many system services have two names, two exceptions exist to thissynonym convention. System V defines both exit and _exit as different facilities. Consequently, the symbols exit and _exit have no synonyms and refer todifferent services.

6-4

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 105

C Library
The C library, libc, contains all of the symbols listed in the following two tables.
libc contains the basic system services. Although special instructions are necessary to change from user to kernel mode, the ABI explicitly does not specify thecorrespondence of these instructions to system calls. The tables below containroutines that correspond to basic system services, as well as to service routinesthat provide a functional interface to system data files.
Though all the function symbols listed in the tables below must be present in
libc, not all of the functions they reference may actually be implemented. See the‘‘Implementation of libc Routines’’ section that follows for more detail.
The first table lists routines associated with the ANSI C standard and the ISO MSE
routines as they are currently defined in the SVID.
NOTE

Although synonyms are not required for the following interfaces, they are permitted to exist. However applications that make use of the synonyms are notconsidered ABI compliant.

M

Figure 6-2: libc Contents, Names without Synonyms

abort
abs
asctimeatexit
atof
atoi
atol
bsearchcallocclearerr
clock
ctime
difftime
div
exit
fclosefeof

ferrorfflushfgetc
fgetpos
fgets
fgetwc *fgetws *fopen
fprintf
fputc
fputs
fputwc *fputws *fread
freefreopen
frexp

fscanffseek
fsetpos
ftell
fwprintf *fwritefwscanf *getc
getchargetenvgets
getwchar *getwc *
gmtimeisalnum
isalphaiscntrl

isdigitisgraphislower
isprint
ispunct
isspaceisupper
iswalnum *iswalpha *iswcntrl *iswctype *iswdigit *iswgraph *iswlower *iswprint *iswpunct *iswspace *C Libraryiswupper *iswxdigit *isxdigit
labs
ldexp
ldiv
localeconv
localtime
longjmpmallocmblen
mbrlen *mbrtowc *mbsinit *mbsrtowcs *mbstowcs
mbtowc6-5

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 106M

Figure 6-2: libc Contents, Names without Synonyms (continued )memchrmemcmpmemcpymemmovememsetmktimemodf
perrorprintfputc
putcharputs
putwchar *putwc *
qsort
raise
rand
realloc
removerenamerewindscanf
setbufsetjmpsetlocale
setvbuf
signalsprintf
srandsscanfstrcatstrchrstrcmpstrcoll
strcpystrcspnstrerror
strftime
strlenstrncatstrncmpstrncpy
strpbrk
strrchrstrspnstrstrstrtodstrtokstrtolstrtoul
strxfrmswprintf *swscanf *systemtmpfiletmpnamtolower
toupper
towlower *towupper *ungetcungetwc *vfprintf
vfwprintf *vprintf
vsprintf
vswprintf *vwprintf *wcrtomb *wcscat *wcschr *wcscmp *wcscoll *wcscpy *wcscspn *wcsftime *wcslen *wcsncat *wcsncmp *wcsncpy *wcspbrk *wcsrchr *wcsrtombs *wcsspn *wcsstr *wcstod *wcstok *wcstol *wcstombs
wcstoul *wcsxfrm *wctob *
wctombwctype *wprintf *wscanf *_exit*Function is new to the Fourth Edition of the ABI.

M

Each of the routines listed in the table below is present in libc in the listed form,
as well as in synonym form, as described in a following section.
Figure 6-3: libc Contents, Names with Synonyms

accessacct #
alarm
asctime_r *catclosecatgets
catopencfgetispeed
cfgetospeed
cfsetispeed
cfsetospeed

flockfile *fnmatch *fork
fork1 *
forkall *fpathconf
fstatvfs
fsync
ftok
ftrylockfile *funlockfile *getsubopt
gettxtgetuidgetw
glob *
globfree *gmtime_r *grantpthcreatehdestroyhsearch6-6

modload *modpath *modstat *moduload *monitormount
mprotect
msgctlmsggetmsgrcv
msgsndLIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 107

Figure 6-3: libc Contents, Names with Synonyms (continued )

chdir
chmod
chown
chrootclose
closedirconfstr *creat
ctermid
ctime_r *cuserid
dup
dup2
execl
execleexeclpexecv
execveexecvpfattachfchdirfchmodfchownfcntl
fdetachfdopenfilenorand_r *readreaddir
readdir_r *readlink
readv
regcomp *regerror *regexec *regfree *rewinddir

getc_unlocked *getchar_unlocked *getcontext
getcwdgetdategetegid
geteuid
getgidgetgrgid
getgrnamgetgroups
getksym *getlogin
getlogin_r *getmsggetoptgetpass
getpass_r *getpgid
getpgrpgetpidgetpmsg
getppid
getpwnam
getpwuid
getrlimit
getsidshmctlshmdt
shmgetsigaction
sigaddset
sigaltstacksigdelset
sigemptyset
sigfillset
sighold
sigignore

iconv *
iconv_close *iconv_open *initgroups
ioctl
isascii
isastream
isattyisnan
isnand #killlchownlfind
linklocaltime_r *
lockf
logb
lsearchlseek
makecontext
memccpymemcntl
mkdir
mkfifomktempmlock
mmap
strfmon *strptime *strtof *strtok_r *strtold *swab
swapcontext
symlinksync
sysconf
tcdrain

C Librarymsync
munlock
munmapnextafternftw
nice
nl_langinfo
open
opendir
pathconf
pause
pclose
pipe
poll
popen
pread *
priocntl *profil #ptraceptsnameputc_unlocked *putchar_unlocked *putenv
putmsgputpmsg
putw
pwrite *ttynamettyname_r *
twalk
tzset
ulimitumask
umountunlinkunlockpt
utime
vfscanf *6-7

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 108

Figure 6-3: libc Contents, Names with Synonyms (continued )

rmdir
scalb
seekdir
semctlsemgetsemop
setcat *setcontext
setgidsetgroups
setlabel #setpgid
setpgrpsetrlimit
setsidsetuidshmat

sigismember
siglongjmp
sigpause
sigpending
sigprocmask
sigrelse
sigsendsigsendset
sigsetsigsetjmp
sigsuspend
sigwait *sleep
snprintf *statvfs
stime
strduptcflow
tcflushtcgetattr
tcgetpgrp
tcgetsid
tcsendbreaktcsetattr
tcsetpgrp
tdeletetell #
telldir
tempnam
tfind
time
times
toascii
tsearchvfwscanf *vscanf *vsnprintf *vsscanf *vswscanf *vwscanf *wait
waitidwaitpid
wcstof *wcstold *wcswidth *wcwidth *wordexp *wordfree *write
writev*Function is new to the Fourth Edition of the ABI.
# Function is DEPRECATED
NOTE

M
X

Other than for use in streams devices, the specific devices supported by
ioctl are processor specific.

libc in the System V Application Binary Interface, Edition 4.1 also contains the following routines which are conformant to the System Interfaces and Headers
volume of the X/Open CAE Specification Guide, Issue 4.2 (see the Conformance Rulein Chapter 1). This table lists routines from the ANSI C standard.

X
X
X
X

Figure 6-4: libc Contents from XSH4.2, Names without Synonyms

Xadvance #compile #drand48

erand48
jrand48lcong48

lrand48
mrand48

nrand48
seed48

X
X
X

srand48
step ## Function is DEPRECATEDX

6-8

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 109

Additionally, libc holds the following services (not contained in the ANSI C standard).
Figure 6-5: libc Contents from XSH4.2, Names with Synonyms_longjmp_setjmpa64lbasename
bcmp
bcopy
brk
bsd_signal
bzero
closelog
dbm_clearerr
dbm_close
dbm_delete
dbm_error
dbm_fetchdbm_firstkey
dbm_nextkey
dbm_open

dbm_store
dirnameecvt
endgrent
endpwent
endutxent
fcvt
ffs
ftime
ftruncateftw
gcvt
getdtablesize
getgrent
gethostid
getitimer
getpagesize
getpriority

getpwent
getrusage
gettimeofday
getutxent
getutxid
getutxline
getwd
ilogb
index
initstate
insquekillpgl64a
log1p
mkstempopenlog
pututxline
randomre_compre_exec
realpathregcmpregex
regexpremquerindexrint
sbrk
selectsetgrent
setitimer
setlogmask
setpriority
setpwent
setregid
setreuid

setstate
setutxent
siginterrupt
signgamsigstack
srandomstrcasecmp
strncasecmp
syslogtruncate
ttyslotualarmusleeputimesvallocvfork
wait3
wcswcs

The routines listed in the table below are needed by the library to work properly.
These routines should not be used by applications.

E

Figure 6-6: libc Contents, Internal Names without Synonyms_cleanup_tolower_toupper_xftw_ _assert_ _filbuf_ _flsbuf_ _iswctype *_ _thr_errno *_ _trwctype *_ _ _errno **Function is new to the Fourth Edition of the ABI.

M

Of the routines listed in the table above, the following are not defined elsewhere.
E

void _cleanup(void);
Functionally equivalent to fflush(NULL).

C Library

6-9

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 110

int _ _filbuf(FILE *f);
This function returns the next input character for f, filling its buffer
as appropriate. _ _filbuf is intended to be called when its buffer is
empty, as it will return the first character added to the buffer, whatever the content of the buffer when the call to _ _filbuf is made. It
returns EOF if an error occurs.

EE

int _ _flsbuf(int x, FILE *f);
This function flushes the output characters for f as if putc(x,f) had
been called and then appends the value of x to the resulting output
stream. It returns EOF if an error occurs and x otherwise.
int _xftw(int, char *, int (*)(char *, struct stat *, int), int);
Calls to the ftw function are mapped to this function when applications are compiled. This function is identical to ftw, except that_xftw() takes an interposed first argument, which must have thevalue 2.

M

int * _ _thr_errno(void);This function returns a pointer to the location of the thread-specificerrno for a particular thread of control when multiple threads of control are being used in a program. Assignments to errno are mapped
to this function when multi-threaded applications are compiled.

M
M
M
M
M

int * _ _ _errno(void);
Functionally equivalent to _ _thr_errno(void) described above.

M

int_ _iswctype(wint_t wc, wctype_t charclass);
This function returns 0 if the wide character represented by thewint_t argument is a member of the wide character classification,
charclass, or a non-zero value if it is not. It is the underlying
engine for the isw* macros and functions.

wint_t_ _trwctype(wint_t wc, wctype_t charclass);
This function returns the value of the wide character wc, converted
to the corresponding character class as defined by charclass, or wc
if no transformation could be done. It is the underlying engine forthe tow* macros and functions.

See this chapter’s other library sections for more SVID, ANSI C, and POSIX facilities. See ‘‘System Data Interfaces’’ later in this chapter for more information.

6-10

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 111

M
M
M
M
M
M
M
M

Additional Entry Points (Processor-Specific)
ABI-conforming systems must provide a libc entry point for each of the sourcelevel services shown in the list below. The name and syntax of this entry point
may be the same as those characteristics of the source-level service or they mayvary across processor architectures. The actual names of the entry points are
specified in each processor’s supplement to the ABI, together with the entry
points’ syntax information if names differ from those of the source-level services.
This information is for the use of system implementors and compiler writers, anddoes not affect the source-level system interface used by application programmers.
Figure 6-7: libc Contents, Additional Services

fstat

NOTE

NOTE

lstat

mknod

stat

uname

This section requires processor–specific information. Consequently, the ABI
supplement for the desired processor describes the details.

Because the ABI specifies neither the correspondence of system calls to traps
nor the formats of system data files, ABI–conforming programs access libc
services through dynamic linking.

See ‘‘System Data Interfaces’’ later in this chapter for more information.

Support Routines (Processor-Specific)
NOTE

This section requires processor–specific information. The ABI supplement forthe desired processor describes the details.

C Library

6-11

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 112

Global Data Symbols
The libc library requires that some global external data symbols be defined for its
routines to work properly. All the data symbols listed in the table below must be
provided by the libc library.
For formal declarations of the data objects represented by these symbols, see the
X/Open CAE Specification, Issue 4.2 and the System V Interface Definition, Fourth Edition (see the Conformance Rule in chapter 1) or the ‘‘Data Definitions’’ section ofChapter 6 in the appropriate processor supplement to the System V ABI.
For entries in the following table that are in name - _name form, both symbols ineach pair represent the same data. The underscore synonyms are provided tosatisfy the ANSI C standard. If the application references a weak symbol that has
a global synonym, it must define both the weak symbol and the global synonym at
the same address. An ANSI C-conforming application can define its own namesymbols, unrelated to the X/Open CAE Specification, Issue 4.2 and the System V
Interface Definition, Fourth Edition meanings. If the application intends those symbols to have the X/Open CAE Specification, Issue 4.2 and the System V Interface
Definition, Fourth Edition semantics, it must also define the _name symbols so thatboth refer to the same data object.

X

E
E
X
X

Figure 6-8: libc Contents, Global External Data Symbols_ _ctype_ _iob_ _loc1_altzone_daylight_ _xpg4_getdate_err_numeric_timezone_tznamealtzone *daylight
errno
getdate_err
loc1

loc2
locs
optargopterroptindoptopttimezonetznameX*Function is new to the Fourth Edition of the ABI.

M

time_t _altzone;
This variable contains the difference, in seconds, between Universal Coordinated Time and the alternate time zone, as establishedwith the function tzset.

X

unsigned char _numeric[2];This array holds local-specific information, as established by thefunction setlocale. Specifically, _numeric[0] holds thedecimal-point character, and _numeric[1] holds the character
used to separate groups of digits to the left of the decimal-point
character in formatted non-monetary quantities. See the function
localeconv for more information.

6-12

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 113X

Xextern int _ _xpg4;
This variable’s value specifies the execution environment for the
program. If the value is 0 or unset, results are implementationspecific. Otherwise, if the value is 1, the application will get System V Application Binary Interface, Edition 4.1 functionality. Allother values for _ _xpg4 are reserved for future use.
NOTE

Typically, _ _xpg4 being initialized to 0 or uninitialized would
represent a backwards compatibility environment for System
V Application Binary Interface, Fourth Edition applications.

X

Application Constraints
As described above, libc provides symbols for applications. In a few cases, however, an application is obliged to provide symbols for the library.
extern char **environ;
Normally, this symbol is synonymous with environ, as the function
exec describes. This isn’t always true, though, because ANSI C does
not define environ. Thus, an ANSI C-conforming application candefine its own environ symbol, unrelated to the process environment. If the application defines environ and intends it to have the
X/Open CAE Specification, Issue 4.2 and the System V Interface
Definition, Fourth Edition semantics (see the Conformance Rule inchapter 1), it must also define _environ so that the two symbols
refer to the same data object.
extern const int _lib_version;
This variable’s value specifies the compilation and execution mode
for the program. If the value is zero, the program wants to preserve
the semantics of older (pre-ANSI) C, where conflicts exist with
ANSI. Otherwise, the value is non-zero, and the program wants
ANSI C semantics.

C Library

6-13

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 114

X

X
X
X

Implementation of libc Routines
All ABI-conforming systems must provide a libc entry point for all routines
listed as belonging to this library. However, only the routines necessary to provide the source-level programming interfaces defined in the X/Open CAE
Specification, Issue 4.2 and defined in the System V Interface Definition, Fourth Edition
sections BA_OS, BA_LIB, and KE_OS, as described in the introduction to the System V ABI, must be implemented on a conforming system. For example, thismeans that the routine memcntl(RT_OS) need not be fully implemented on an
ABI-conforming system, though the entry point for this function must be present
in the library.
Routines not required for the System V Interface Definition, Fourth Edition sections
listed above or X/Open CAE Specification, Issue 4.2 may or may not be implemented, at the discretion of the system implementor. Unimplemented routinesmust be represented in the library by a stub that when called causes failure andsets the the assignable lvalue errno to the value ENOSYS.

X

X
E
E

Vendor Extensions
Besides the services listed above, libc may contain other symbols. An ABIconforming system vendor may add a symbol to the C library to provide vendorspecific services. The ABI does not define these services, and programs using
these services are not ABI-conforming. Nonetheless, the ABI defines a recommended extension mechanism, providing a way to avoid conflict among the services from multiple vendors.
A symbol of the form _$vendor.company provides an operating system entry forthe vendor named company. The C library does not have unadorned alternatives
for these names. Conventionally, a vendor uses the single name to provide multiple services, letting the first argument to _$vendor.company select among thealternatives. As an example, the ‘‘XYZ Computer Company’’ might add_$vendor.xyz to the C library.

6-14

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 115

E

M

Threads Library

M

The Threads Library, libthread, contains interfaces supporting multithreaded
applications and asynchronous input/output which are defined in the MT extension of the System V Interface Definition, Fourth Edition. The multithreading interfaces in the SVID MT extension are semantically similar to those found in the IEEEPOSIX 1003.1c 1995 draft standard (formerly known as 1003.4a or the Pthreads
standard), although the MT extension is more powerful in terms of the synchronization and thread control interfaces provided. It is anticipated that a future version of the ABI and SVID will contain all interfaces in the completed POSIX multithreading standard.

M
M
M
M
M
M
M
M
M

The following multithreading functions reside in libthread and must be provided on all ABI-conforming systems.

M
M

Figure 6-9: libthread Contents *, Part 1 of 2

barrier_destroy
barrier_init
barrier_wait
cond_broadcast
cond_destroy
cond_init
cond_signal
cond_timedwait
cond_wait
mutex_destroy
mutex_init
mutex_lock
mutex_trylock
mutex_unlock
rmutex_destroy
rmutex_init
rmutex_lockrmutex_trylock

rmutex_unlock
rw_rdlockrw_tryrdlock
rw_trywrlock
rw_unlockrw_wrlockrwlock_destroy
rwlock_init
sema_destroy
sema_init
sema_post
sema_trywait
sema_wait
thr_continue
thr_create
thr_exit
thr_get_rr_interval

thr_getconcurrency
thr_getprio
thr_getscheduler
thr_getspecificthr_join
thr_keycreate
thr_keydelete
thr_kill
thr_minstack
thr_self
thr_setconcurrency
thr_setprio
thr_setscheduler
thr_setspecificthr_sigsetmask
thr_suspend
thr_yield* All functions in this table are new to the Fourth Edition of the ABI.

M

The following functions to support asynchronous I/O also reside in libthread
and must be provided on all ABI-conforming systems.

M
M

Threads Library

6-15

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 116

Figure 6-10: libthread Contents *, Part 2 of 2

aio_cancel
aio_error

aio_read
aio_return

aio_suspend
aio_write

lio_listio* All functions in this table are new to the Fourth Edition of the ABI.

6-16

M

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 117

Dynamic Linking Library

M

The Dynamic Linking library, libdl, contains the library routines that provide theuser direct access to the dynamic linking facilities. The following functions residein libdl and must be provided on all ABI-conforming systems.

M
M
M

Figure 6-11: libdl Contents *

M
dlsym

M

* All functions in this table are new to the Fourth Edition of the ABI.

M

dlclosedlerrordlopenDynamic Linking Library

6-17

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 118

Network Services Library
The Network Services library, libnsl, contains library routines that provide atransport-level interface to networking services for applications, facilities formachine-independent data representation, a remote procedure call mechanism,and other networking services useful for application programs. This library contains two sets of interfaces: one conforming to the Transport Level Interface (TLI)
specification and another to the X/Open Transport Interface (XTI) Version 2
specification. The TLI interface allows for binary compatibility with systems that
conform to previous editions of the ABI.

M
M
M
M

The following TLI conforming functions reside in libnsl and must be provided
on all ABI-conforming systems.
Figure 6-12: libnsl Contents, Part 1 of 3

t_acceptt_alloct_bindt_closet_connectt_errort_freet_getinfo
t_getstatet_listent_lookt_opent_optmgmt
t_rcv
t_rcvconnectt_rcvdist_rcvrelt_rcvudata
t_rcvuderr
t_snd
t_snddist_sndrelt_sndudata
t_synct_unbind

The following XTI interfaces also reside in libnsl and must be provided on all
ABI-conforming systems.
Figure 6-13: libnsl Contents *, Part 2 of 3

_xti_accept_xti_alloc_xti_bind_xti_close_xti_connect_xti_error_xti_free_xti_getinfo_xti_getprotaddr_xti_getstate_xti_listen_xti_look_xti_open_xti_rcv

6-18_xti_rcvconnect_xti_rcvdis_xti_rcvrel_xti_rcvudata_xti_rcvuderr_xti_snd_xti_snddis

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 119M
M

Figure 6-13: libnsl Contents *, Part 2 of 3 (continued )_xti_sndrel_xti_sndudata_xti_strerror_xti_sync_xti_unbind* All functions in this table are new to the Fourth Edition of the ABI.

M

In addition, the following functions must be provided in libnsl on all ABIconforming systems with a networking capability. Systems with no networking
capability are not required to implement these functions, but must provide an
entry point into libnsl for each of the following function names. Functions thatare present only as stubs and are not implemented must fail normally and perform no action other setting the external errno variable to the value ENOSYS when
they are called by an application.
Figure 6-14: libnsl Contents, Part 3 of 3
authdes_getucred
authdes_seccreate
authnone_create
authsys_create
authsys_create_default
clnt_create
clnt_dg_create
clnt_pcreateerror
clnt_perrno
clnt_perror
clnt_raw_create
clnt_spcreateerror
clnt_sperrno
clnt_sperror
clnt_tli_create
clnt_tp_create
clnt_vc_create
endnetconfig
endnetpath
freenetconfigent
getnetconfig
getnetconfigent
getnetname
getnetpath

getpublickey
getsecretkey
host2netname
key_decryptsession
key_encryptsession
key_gendes
key_setsecret
nc_perror
nc_sperror *netdir_free
netdir_getbyaddr
netdir_getbyname
netdir_options
netdir_perror *netdir_sperror *netname2host
netname2user
rpcb_getaddr
rpcb_getmaps
rpcb_gettime
rpcb_rmtcall
rpcb_set
rpcb_unset
rpc_broadcast

Network Services Library

rpc_broadcast_exp *rpc_call
rpc_regsetnetconfig
setnetpath
svcerr_authsvcerr_decode
svcerr_noproc
svcerr_noprog
svcerr_progvers
svcerr_systemerr
svcerr_weakauth
svc_create
svc_dg_create
svc_fd_create
svc_getreqset
svc_getreq_common *svc_getreq_poll *svc_raw_create
svc_reg
svc_runsvc_sendreply
svc_tli_create
svc_tp_create

6-19

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 120

E
E

Figure 6-14: libnsl Contents, Part 3 of 3 (continued )svc_unreg
svc_vc_create
taddr2uaddr
uaddr2taddr
user2netname
xdrmem_create
xdrrec_create
xdrrec_endofrecord *xdrrec_eof
xdrrec_skiprecord *xdrstdio_create
xdr_accepted_reply
xdr_array
xdr_authsys_parms
xdr_bool

xdr_bytes
xdr_callhdr
xdr_callmsg
xdr_charxdr_double
xdr_enum
xdr_float
xdr_free
xdr_int
xdr_long
xdr_opaque
xdr_opaque_authxdr_pointerxdr_reference

xdr_rejected_reply
xdr_replymsg
xdr_short
xdr_string
xdr_union
xdr_u_char
xdr_u_int *xdr_u_long
xdr_u_short
xdr_vector
xdr_void
xdr_wrapstring
xprt_register
xprt_unregister*Function is new to the Fourth Edition of the ABI.

M

Figure 6-15: libnsl Contents, Global External Data Symbols

rpc_createerr

svc_fdset

t_errno_nderrorSee ‘‘Data Definitions’’ later in this chapter for more information.

6-20

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 121

Socket Library
The socket library, libsocket, contains the socket functions as described in the
Networking Services volume of the X/Open CAE Specification, Issue 4.2. Thislibrary is required for all ABI-conforming systems.

X
X
X

Figure 6-16: libsocket Contents, Part 1 of 2

X

acceptbind
connect
getpeername
getsockname
getsockopt

listenpool
recv
recvfrom
recvmsg
send

X
X
X
X
X
X

sendmsg
sendtosetsockopt
shutdown
socketsocketpair

The socket library, libsocket, also contains these IP Address Resolution functions as described in the Networking Services volume of the X/Open CAE
Specification, Issue 4.2.

X
X
X
X

Figure 6-18: libsocket Contents, Part 2 of 2

X

endhostentendnetent
endprotoent
endservent
gethostbyaddr
gethostbyname
gethostent
gethostname
getnetbyaddr
getnetbyname
getnetent

getprotobyname
getprotobynumber
getprotoent
getservbyname
getservbyportgetservent
htonl
htons
inet_addr
inet_lnaof

Socket Library

X
X
X
X
X
X
X
X
X
X
X

inet_makeaddr
inet_netof
inet_network
inet_ntoa
ntohl
ntohs
sethostentsetnetent
setprotoentsetservent

6-21

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 122

Curses Library
The curses library, libcurses, contains functions that update character screens as
described in the Curses volume of the X/Open CAE Specification, Issue 4.2.

X
X

Figure 6-19: libcurses Contents

X

addch
addchnstr
addchstr
addnstraddnwstr
addstr
addwstr
add_wchadd_wchnstr
add_wchstr
attroff
attronattrsetattr_get
attr_off
attr_onattr_setbaudrate
beep
bkgd
bkgdsetbkgrndbkgrndset
borderborder_set
box
box_setcan_change_color
cbreakchgat
clear
clearokgetnstr
getn_wstr
getparyx
getstrgetwingetyx
get_wchget_wstr
halfdelay
has_colors
has_ichas_ilhline
hline_set
idcok
idlok
immedokinch
inchnstrinchstrinitscr
init_color
init_pairinnstrinnwstrinsch
insdelln
insertln
insnstr
insstrinstr
ins_nwstr

6-22

X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

mvgetnstr
mvgetn_wstr
mvgetstr
mvget_wch
mvget_wstr
mvhlinemvhline_set
mvinchmvinchnstr
mvinchstr
mvinnstr
mvinnwstr
mvinschmvinsnstr
mvinsstrmvinstrmvins_nwstr
mvins_wchmvins_wstr
mvinwstr
mvin_wchmvin_wchnstr
mvin_wchstr
mvprintw
mvscanw
mvvlinemvvline_set
mvwaddch
mvwaddchnstr
mvwaddchstr
mvwaddnstr
mvwaddnwstr

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 123

X

Figure 6-19: libcurses Contents (continued )clrtobotclrtoeolcolor_content
copywincurscrcurs_set
cur_term
def_prog_mode
def_shell_mode
delay_output
delch
deletelndelscreendelwindel_curtermderwindoupdate
dupwinecho
echocharecho_wchar
endwinerase
erasecharerasewchar
filterflash
flushinp
getbegyx
getbkgd
getbkgrnd
getcchargetchgetmaxyx
mvwvline
mvwvline_set
napms
newpadins_wchins_wstr
intrflush
inwstrin_wchin_wchnstr
in_wchstrisendwin
is_linetouchedis_wintouchedkeynamekeypadkey_name
killcharkillwcharleaveok
longname
meta
move
mvaddchmvaddchnstr
mvaddchstr
mvaddnstr
mvaddnwstr
mvaddstr
mvaddwstr
mvadd_wch
mvadd_wchnstr
mvadd_wchstr
mvchgatmvcur
mvdelchmvderwin
mvgetchslk_setslk_touch
slk_wset
standend

Curses Library

X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

mvwaddstr
mvwaddwstr
mvwadd_wch
mvwadd_wchnstr
mvwadd_wchstr
mvwchgat
mvwdelch
mvwgetch
mvwgetnstr
mvwgetn_wstr
mvwgetstr
mvwget_wch
mvwget_wstr
mvwhline
mvwhline_set
mvwin
mvwinchmvwinchnstr
mvwinchstr
mvwinnstr
mvwinnwstr
mvwinschmvwinsnstr
mvwinsstr
mvwinstr
mvwins_nwstr
mvwins_wch
mvwins_wstr
mvwinwstr
mvwin_wch
mvwin_wchnstr
mvwin_wchstr
mvwprintw
mvwscanw
wbkgdset
wbkgrndwbkgrndset
wborder

6-23

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 124

X

Figure 6-19: libcurses Contents (continued )newtermnewwinnl
nonocbreaknodelay
noechononl
noqiflush
noraw
notimeout
overlay
overwrite
pair_content
pechochar
pecho_wchar
pnoutrefresh
prefreshprintw
putp
putwinqiflushraw
redrawwin
refreshresettyreset_prog_mode
reset_shell_mode
restartterm
ripoffline
savettyscanw
scrl
scrollscrollok
scr_dump
scr_init
scr_restore

standout
start_color
stdscrsubpadsubwinsyncoktermattrs
termname
tgetent #tgetflag #tgetnum #tgetstr #tgoto #
tigetflag
tigetnum
tigetstr
timeout
touchline
touchwin
tparm
tputs
typeaheadunctrlungetchunget_wch
untouchwin
use_env
vidattrvidputs
vid_attr
vid_puts
vline
vline_set
vwprintw #vwscanw #vw_printw
vw_scanw
waddch

6-24

X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

wborder_set
wchgatwclear
wclrtobot
wclrtoeol
wcursyncup
wdelchwdeleteln
wechochar
wecho_wchar
werasewgetbkgrnd
wgetchwgetnstr
wgetn_wstr
wgetstrwget_wch
wget_wstr
whlinewhline_set
winch
winchnstr
winchstr
winnstrwinnwstr
winschwinsdelln
winsertln
winsnstr
winsstrwinstrwins_nwstr
wins_wch
wins_wstr
winwstr
win_wchwin_wchnstr
win_wchstr

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 125

X

Figure 6-19: libcurses Contents (continued )scr_setsetccharsetscrreg
setupterm
set_curterm
set_term
slk_attroff
slk_attron
slk_attrset
slk_attr_off
slk_attr_on
slk_attr_set
slk_clear
slk_init
slk_label
slk_noutrefresh
slk_refresh
slk_restore

waddchnstr
waddchstr
waddnstr
waddnwstr
waddstrwaddwstr
wadd_wch
wadd_wchnstr
wadd_wchstr
wattroff
wattronwattrset
wattr_get
wattr_off
wattr_on
wattr_set
wbkgd

X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

wmove
wnoutrefresh
wprintwwredrawln
wrefreshwscanw
wscrl
wsetscrreg
wstandend
wstandout
wsyncdown
wsyncup
wtimeout
wtouchlnwunctrl
wvlinewvline_set# Function is DEPRECATED

X

Figure 6-20: libcurses Contents, Global External Data Symbols

bit_attributes
boolcodes
boolfnames
boolnames
curs_errno
curs_parm_err
cur_bools
cur_nums

cur_strs
Mouse_status
numcodesnumfnames
numnamesoutchcountSP
strcodesCurses Library

X
X
X
X
X
X
X
X

strfnames
strnames
TABSIZE
term_errno
term_parm_err
ttytypewcolor_set

6-25

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 126

X Window System LibraryE

The X Window System library, libX, contains library routines that provide primitives for the operation of the X Window System. This library is required for all
ABI-conforming systems that implement a graphical windowing terminal interface. See Chapter 10 of the System V ABI, ‘‘Windowing and Terminal Interfaces’’
for more information on windowing software requirements on ABI-conforming
systems.

E
E
E
E
E
E

The following functions reside in libX and must be provided on all ABIconforming systems.

E
E

6-26

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 127

Figure 6-21: libX Contents
XActivateScreenSaver
XAddExtension
XAddHost
XAddHosts
XAddPixel
XAddToExtensionList
XAddToSaveSet
XAllocClassHint
XAllocColor
XAllocColorCells
XAllocColorPlanes
XAllocIconSize
XAllocNamedColor
XAllocSizeHints
XAllocStandardColormap
XAllocWMHints
XAllowEvents
XAllPlanes
XAutoRepeatOff
XAutoRepeatOn
XBaseFontNameListOfFontSet
XBell
XBitmapBitOrder
XBitmapPad
XBitmapUnit
XBlackPixel
XBlackPixelOfScreen
XCellsOfScreen
XChangeActivePointerGrab
XChangeGC
XChangeKeyboardControl
XChangeKeyboardMapping
XChangePointerControl
XChangeProperty
XChangeSaveSet
XChangeWindowAttributes
XCheckIfEvent
XCheckMaskEvent

XCheckTypedEvent
XCheckTypedWindowEvent
XCheckWindowEvent
XCirculateSubwindows
XCirculateSubwindowsDown
XCirculateSubwindowsUp
XClearArea
XClearWindow
XClipBox
XCloseDisplay
XCloseIM
XcmsAddColorSpace
XcmsAddFunctionSet
XcmsAllocColor
XcmsAllocNamedColor
XcmsCCCofColormap
XcmsCIELabClipab *XcmsCIELabClipLab *XcmsCIELabClipL *XcmsCIELabQueryMaxC
XcmsCIELabQueryMaxL
XcmsCIELabQueryMaxLC
XcmsCIELabQueryMinL
XcmsCIELabToCIEXYZ
XcmsCIELabWhiteShiftColors *XcmsCIELuvClipLuv *XcmsCIELuvClipL *XcmsCIELuvClipuv *XcmsCIELuvQueryMaxC
XcmsCIELuvQueryMaxL
XcmsCIELuvQueryMaxLC
XcmsCIELuvQueryMinL
XcmsCIELuvToCIEuvY
XcmsCIELuvWhiteShiftColors *XcmsCIEuvYToCIELuv
XcmsCIEuvYToCIEXYZ
XcmsCIEuvYToTekHVC
XcmsCIExyYToCIEXYZX Window System Library

XcmsCIEXYZToCIELab
XcmsCIEXYZToCIEuvY
XcmsCIEXYZToCIExyY
XcmsCIEXYZToRGBi
XcmsClientWhitePointOfCCC
XcmsConvertColors
XcmsCreateCCC
XcmsDefaultCCC
XcmsDisplayOfCCC
XcmsFormatOfPrefix
XcmsFreeCCC
XcmsLookupColor
XcmsPrefixOfFormat
XcmsQueryBlack
XcmsQueryBlue
XcmsQueryColor
XcmsQueryColors
XcmsQueryGreenXcmsQueryRed
XcmsQueryWhite
XcmsRGBiToCIEXYZ
XcmsRGBiToRGB
XcmsRGBToRGBi
XcmsScreenNumberOfCCC
XcmsScreenWhitePointOfCCC
XcmsSetCompressionProc
XcmsSetWhiteAdjustProc
XcmsSetWhitePoint
XcmsStoreColor
XcmsStoreColors
XcmsTekHVCClipC *XcmsTekHVCClipVC *XcmsTekHVCClipV *XcmsTekHVCQueryMaxC
XcmsTekHVCQueryMaxV
XcmsTekHVCQueryMaxVC
XcmsTekHVCQueryMaxVSamples
XcmsTekHVCQueryMinV

6-27

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 128

Figure 6-21: libX Contents (continued )XcmsTekHVCToCIEuvY
XcmsTekHVCWhiteShiftColors *XcmsVisualOfCCC
XConfigureWindow
XConnectionNumber
XContextDependentDrawing
XConvertSelection
XCopyArea
XCopyColormapAndFree
XCopyGC
XCopyPlane
XCreateBitmapFromData
XCreateColormap
XCreateFontCursor
XCreateFontSet
XCreateGC
XCreateGlyphCursor
XCreateIC
XCreateImage
XCreatePixmap
XCreatePixmapCursor
XCreatePixmapFromBitmapData
XCreateRegion
XCreateSimpleWindow
XCreateWindow
XDefaultColormap
XDefaultColormapOfScreen
XDefaultDepth
XDefaultDepthOfScreen
XDefaultGC
XDefaultGCOfScreen
XDefaultRootWindow
XDefaultScreen
XDefaultScreenOfDisplay
XDefaultString
XDefaultVisual
XDefaultVisualOfScreen
XDefineCursor

XDeleteContext
XDeleteModifiermapEntry
XDeleteProperty
XDestroyIC
XDestroyImage
XDestroyRegion
XDestroySubwindows
XDestroyWindow
XDisableAccessControl
XDisplayCells
XDisplayHeight
XDisplayHeightMM
XDisplayKeycodes
XDisplayMotionBufferSize
XDisplayName
XDisplayOfIM
XDisplayOfScreen
XDisplayPlanes
XDisplayString
XDisplayWidth
XDisplayWidthMM
XDoesBackingStoreXDoesSaveUnders
XDrawArc
XDrawArcs
XDrawImageString
XDrawImageString16
XDrawLine
XDrawLines
XDrawPoint
XDrawPoints
XDrawRectangle
XDrawRectangles
XDrawSegments
XDrawString
XDrawString16
XDrawText
XDrawText16

6-28

XEmptyRegion
XEnableAccessControl
XEqualRegion
XEventMaskOfScreen
XEventsQueued
XExtentsOfFontSet
XFetchBuffer
XFetchBytes
XFetchName
XFillArc
XFillArcs
XFillPolygon
XFillRectangle
XFillRectangles
XFilterEvent
XFindContext
XFindOnExtensionList *XFlushXFlushGC
XFontsOfFontSet
XForceScreenSaver
XFree
XFreeColormap
XFreeColors
XFreeCursor
XFreeExtensionList
XFreeFont
XFreeFontInfo
XFreeFontNames
XFreeFontPath
XFreeFontSet
XFreeGC
XFreeModifiermap
XFreePixmap
XFreeStringList
XGContextFromGC
XGeometry
XGetAtomName

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 129

Figure 6-21: libX Contents (continued )XGetClassHint
XGetCommand
XGetDefault
XGetErrorDatabaseText
XGetErrorText
XGetFontPath
XGetFontProperty
XGetGCValues
XGetGeometry
XGetIconName
XGetIconSizes
XGetICValues
XGetImage
XGetIMValues
XGetInputFocus
XGetKeyboardControl
XGetKeyboardMapping
XGetModifierMapping
XGetMotionEvents
XGetNormalHints
XGetPixel
XGetPointerControl
XGetPointerMapping
XGetRGBColormaps
XGetScreenSaver
XGetSelectionOwner
XGetSizeHints
XGetStandardColormap
XGetSubImageXGetTextProperty
XGetTransientForHint
XGetVisualInfo
XGetWindowAttributes
XGetWindowProperty
XGetWMClientMachine
XGetWMColormapWindows
XGetWMHints
XGetWMIconName

XGetWMName
XGetWMNormalHints
XGetWMProtocols
XGetWMSizeHints
XGrabButton
XGrabKeyXGrabKeyboard
XGrabPointer
XGrabServer
XHeightMMOfScreen
XHeightOfScreen
XIconifyWindow
XIfEvent
XImageByteOrder
XIMOfICXInitExtension
XInsertModifiermapEntry
XInstallColormap
XInternAtom
XIntersectRegion
XKeycodeToKeysym
XKeysymToKeycode
XKeysymToString
XKillClient
XLastKnownRequestProcessed
XListDepths
XListExtensions
XListFonts
XListFontsWithInfo
XListHosts
XListInstalledColormaps
XListPixmapFormats
XListProperties
XLoadFont
XLoadQueryFont
XLocaleOfFontSet
XLocaleOfIM
XLookupColorX Window System Library

XLookupKeysym
XLookupString
XLowerWindow
XMapRaised
XMapSubwindows
XMapWindow
XMaskEvent
XMatchVisualInfo
XMaxCmapsOfScreen
XMaxRequestSize
XmbDrawImageString
XmbDrawString
XmbDrawText
XmbLookupString
XmbResetIC
XmbSetWMProperties
XmbTextEscapement
XmbTextExtents
XmbTextListToTextProperty
XmbTextPerCharExtents
XmbTextPropertyToTextList
XMinCmapsOfScreen
XMoveResizeWindow
XMoveWindow
XNewModifiermap
XNextEvent
XNextRequest
XNoOp
XOffsetRegion
XOpenDisplay
XOpenIM
XParseColor
XParseGeometry
XPeekEvent
XPeekIfEvent
XPending
Xpermalloc
XPlanesOfScreen

6-29

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 130

Figure 6-21: libX Contents (continued )XPointInRegion
XPolygonRegion
XProtocolRevision
XProtocolVersion
XPutBackEvent
XPutImage
XPutPixel
XQLength
XQueryBestCursor
XQueryBestSize
XQueryBestStipple
XQueryBestTile
XQueryColor
XQueryColors
XQueryExtension
XQueryFont
XQueryKeymap
XQueryPointer
XQueryTextExtents
XQueryTextExtents16
XQueryTree
XRaiseWindow
XReadBitmapFile
XRebindKeysym
XRecolorCursor
XReconfigureWMWindow
XRectInRegion
XRefreshKeyboardMapping
XRemoveFromSaveSet
XRemoveHost
XRemoveHosts
XReparentWindow
XResetScreenSaver
XResizeWindow
XResourceManagerString
XRestackWindows
XrmCombineDatabase
XrmCombineFileDatabase

XrmDestroyDatabase
XrmEnumerateDatabase
XrmGetDatabase
XrmGetFileDatabase
XrmGetResource
XrmGetStringDatabase
XrmInitialize
XrmLocaleOfDatabase
XrmMergeDatabases
XrmParseCommand
XrmPermStringToQuark
XrmPutFileDatabase
XrmPutLineResource
XrmPutResource
XrmPutStringResource
XrmQGetResource
XrmQGetSearchList
XrmQGetSearchResource
XrmQPutResource
XrmQPutStringResource
XrmQuarkToString
XrmSetDatabase
XrmStringToBindingQuarkList
XrmStringToQuark
XrmStringToQuarkList
XrmUniqueQuark
XRootWindow
XRootWindowOfScreen
XRotateBuffers
XRotateWindowProperties
XSaveContext
XScreenCount
XScreenNumberOfScreen
XScreenOfDisplay
XScreenResourceString
XSelectInput
XSendEvent
XServerVendor

6-30

XSetAccessControl
XSetAfterFunction
XSetArcMode
XSetBackground
XSetClassHint
XSetClipMask
XSetClipOrigin
XSetClipRectangles
XSetCloseDownMode
XSetCommand
XSetDashes
XSetErrorHandler
XSetFillRule
XSetFillStyle
XSetFont
XSetFontPath
XSetForeground
XSetFunction
XSetGraphicsExposures
XSetICFocus
XSetIconName
XSetIconSizes
XSetICValues
XSetInputFocus
XSetIOErrorHandler
XSetLineAttributes
XSetLocaleModifiers
XSetModifierMapping
XSetNormalHints
XSetPlaneMask
XSetPointerMapping
XSetRegion
XSetRGBColormaps
XSetScreenSaver
XSetSelectionOwner
XSetSizeHints
XSetStandardColormap
XSetStandardProperties

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 131

Figure 6-21: libX Contents (continued )XSetState
XSetStipple
XSetSubwindowMode
XSetTextProperty
XSetTile
XSetTransientForHint
XSetTSOrigin
XSetWindowBackground
XSetWindowBackgroundPixmap
XSetWindowBorder
XSetWindowBorderPixmap
XSetWindowBorderWidth
XSetWindowColormap
XSetWMClientMachine
XSetWMColormapWindows
XSetWMHints
XSetWMIconName
XSetWMName
XSetWMNormalHints
XSetWMProperties
XSetWMProtocols
XSetWMSizeHints
XShrinkRegion
XStoreBuffer
XStoreBytes
XStoreColor
XStoreColors

XStoreName
XStoreNamedColorXStringListToTextProperty
XStringToKeysym
XSubImage
XSubtractRegion
XSupportsLocale
XSync
XSynchronize
XTextExtents
XTextExtents16
XTextPropertyToStringList
XTextWidth
XTextWidth16
XTranslateCoordinates
XUndefineCursor
XUngrabButton
XUngrabKey
XUngrabKeyboard
XUngrabPointer
XUngrabServer
XUninstallColormap
XUnionRectWithRegion
XUnionRegion
XUnloadFont
XUnmapSubwindows

XUnmapWindow
XUnsetICFocus
XVaCreateNestedList
XVendorRelease
XVisualIDFromVisual
XWarpPointerXwcDrawImageString
XwcDrawString
XwcDrawText
XwcFreeStringList
XwcLookupString
XwcResetIC
XwcTextEscapement
XwcTextExtents
XwcTextListToTextProperty
XwcTextPerCharExtents
XwcTextPropertyToTextList
XWhitePixel
XWhitePixelOfScreen
XWidthMMOfScreen
XWidthOfScreen
XWindowEvent
XWithdrawWindow
XWMGeometry
XWriteBitmapFile
XXorRegion*Function is new to the Fourth Edition of the ABI.

X Window System Library

M

6-31

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 132

The table below contains callback functions which are well known entry points in
libX. These can be defined and used by ABI conforming applications provided
that their definition and use complies with the X11R5 graphical user interface
specification.

M
M
M
E

Figure 6-22: libX Contents, Callback Function Names
GeometryCallback
PreeditCaretCallback
PreeditDoneCallback

PreeditDrawCallback
PreeditStartCallback
StatusDoneCallback

StatusDrawCallback
StatusStartCallback

The libX library requires that some global external data symbols be defined for its
routines to work properly. All the data symbols listed in the table below must be
provided by the libX library.

M
M
M

For formal declarations of the data objects represented by these symbols, see the‘‘Data Definitions’’ section of Chapter 6 in the appropriate processor supplement
to the System V ABI.

M
M
M

Figure 6-23: libX Contents *, Global External Data Symbols
XcmsCIELabColorSpace
XcmsCIELuvColorSpace
XcmsCIEuvYColorSpace
XcmsCIExyYColorSpace
XcmsCIEXYZColorSpace

XcmsLinearRGBFunctionSet
XcmsRGBColorSpace
XcmsRGBiColorSpace
XcmsTekHVCCColorSpace
XcmsUNDEFINEDColorSpace* All functions in this table are new to the Fourth Edition of the ABI.

6-32

M

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 133

X11 Nonrectangular Window Shape Extension
LibraryM

The X11 Nonrectangular Window Shape Extension Library Version 1.0, libXext,
contains library routines that provide mechanisms for changing the visible shapeof a window to an arbitrary, possibly disjoint, nonrectangular form. This library is
required for all ABI-conforming systems that implement a graphical windowing
terminal interface. See Chapter 10 of the System V ABI, ‘‘Windowing and Terminal Interfaces’’ for more information on windowing software requirements on
ABI-conforming systems.

M
M
M
M
M
M
M

The following functions reside in libXext and must be provided on all ABIconforming systems that implement a graphical windowing terminal interface.

M
M

M

Figure 6-24: libXext Contents *XShapeCombineMask
XShapeGetRectangles XShapeQueryExtents
XShapeCombineRectangles XShapeInputSelected XShapeQueryVersion
XShapeCombineRegion
XShapeOffsetShape
XShapeSelectInput
XShapeCombineShape
XShapeQueryExtension* All functions in this table are new to the Fourth Edition of the ABI.

X11 Nonrectangular Window Shape Extension Library

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 134

M

6-33

X Toolkit Intrinsics LibraryG

The X Toolkit Intrinsics library, libXt, contains library routines that provide
primitives for the operation of the X Toolkit Intrinsics of the X Window System.
This library is required for all ABI-conforming systems that implement a graphicalwindowing terminal interface. See Chapter 10 of the System V ABI, ‘‘Windowing
and Terminal Interfaces’’ for more information on windowing software requirements on ABI-conforming systems.

G
G
G
G
G
G

The following functions reside in libXt and must be provided on all ABIconforming systems that implement a graphical windowing terminal interface.

G
G

6-34

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 135

Figure 6-25: libXt Contents
XtAddCallback
XtCallbackExclusive
XtCvtStringToFloat
XtAddCallbacks
XtCallbackNone
XtCvtStringToFont
XtAddEventHandler
XtCallbackNonexclusive
XtCvtStringToFontSet
XtAddExposureToRegion
XtCallbackPopdown
XtCvtStringToFontStruct
XtAddGrab
XtCallbackReleaseCacheRef
XtCvtStringToInitialState
XtAddRawEventHandler
XtCallbackReleaseCacheRefList XtCvtStringToInt
XtAllocateGC
XtCallCallbackList
XtCvtStringToPixel
XtAppAddActionHook
XtCallCallbacks
XtCvtStringToShort
XtAppAddActions
XtCallConverter
XtCvtStringToTranslationTable
XtAppAddInput
XtCalloc
XtCvtStringToUnsignedChar
XtAppAddTimeOut
XtClass
XtCvtStringToVisual
XtAppAddWorkProc
XtCloseDisplay
XtDatabase
XtAppCreateShell
XtConfigureWidget
XtDestroyApplicationContext
XtAppError
XtConvertAndStore
XtDestroyWidget
XtAppErrorMsg
XtConvertCase
XtDisownSelection
XtAppGetErrorDatabase
XtCreateApplicationContext
XtDispatchEvent
XtAppGetErrorDatabaseText XtCreateManagedWidget
XtDisplay
XtAppGetSelectionTimeout XtCreatePopupShell
XtDisplayInitialize
XtAppInitialize
XtCreateWidget
XtDisplayOfObject
XtAppMainLoop
XtCreateWindow
XtDisplayStringConversionWarning
XtAppNextEvent
XtCvtColorToPixel
XtDisplayToApplicationContext
XtAppPeekEvent
XtCvtIntToBool
XtFindFile
XtAppPending
XtCvtIntToBoolean
XtFreeXtAppProcessEvent
XtCvtIntToColor
XtGetActionKeysym
XtAppReleaseCacheRefs
XtCvtIntToFloat
XtGetActionList
XtAppSetErrorHandler
XtCvtIntToFont
XtGetApplicationNameAndClass
XtAppSetErrorMsgHandler
XtCvtIntToPixel
XtGetApplicationResources
XtAppSetFallbackResources XtCvtIntToPixmap
XtGetConstraintResourceList
XtAppSetSelectionTimeout XtCvtIntToShort
XtGetGC
XtAppSetTypeConverter
XtCvtIntToUnsignedChar
XtGetKeysymTable
XtAppSetWarningHandler
XtCvtStringToAcceleratorTable XtGetMultiClickTime
XtAppSetWarningMsgHandler XtCvtStringToAtom
XtGetResourceList
XtAppWarning
XtCvtStringToBool
XtGetSelectionRequest
XtAppWarningMsg
XtCvtStringToBoolean
XtGetSelectionValue
XtAugmentTranslations
XtCvtStringToCursor
XtGetSelectionValueIncremental
XtBuildEventMask
XtCvtStringToDimension
XtGetSelectionValues
XtCallAcceptFocus
XtCvtStringToDisplay
XtGetSelectionValuesIncremental
XtCallActionProc
XtCvtStringToFile
XtGetSubresources

X Toolkit Intrinsics Library

6-35

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 136

Figure 6-25: libXt Contents (continued )XtGetSubvalues
XtGetValues
XtGrabButton
XtGrabKey
XtGrabKeyboard
XtGrapPointerXtHasCallbacks
XtInitializeWidgetClass
XtInsertEventHandler
XtInsertRawEventHandler
XtInstallAccelerators
XtInstallAllAccelerators
XtIsApplicationsShell *XtIsComposite *XtIsConstraint *XtIsManaged
XtIsObject
XtIsOverrideShell *XtIsRealized
XtIsRectObj *XtIsSensitive
XtIsShell *XtIsSubclass
XtIsTopLevelShell *XtIsTransientShell *XtIsVendorShell
XtIsWidget *XtIsWMShell *XtKeysymToKeycodeList
XtLastTimestampProcessed
XtMakeGeometryRequest
XtMakeResizeRequest
XtMalloc
XtManageChild
XtManageChildren
XtMapWidget
XtMenuPopupAction *XtMergeArgLists

XtMoveWidget
XtNameXtNameToWidget
XtOpenDisplay
XtOverrideTranslations
XtOwnSelection
XtOwnSelectionIncremental
XtParent
XtParseAcceleratorTable
XtParseTranslationTable
XtPopdown
XtPopup
XtPopupSpringLoaded
XtQueryGeometry
XtRealizeWidget
XtRealloc
XtRegisterCaseConverter
XtRegisterGrabAction
XtReleaseGC
XtRemoveActionHook
XtRemoveAllCallbacks
XtRemoveCallback
XtRemoveCallbacks
XtRemoveEventHandler
XtRemoveGrab
XtRemoveInput
XtRemoveRawEventHandler
XtRemoveTimeOut
XtRemoveWorkProc *XtResizeWidget
XtResizeWindow
XtResolvePathname
XtScreen
XtScreenDatabase
XtScreenOfObject
XtSetKeyboardFocus
XtSetKeyTranslator
XtSetLanguageProc

XtSetMappedWhenManaged
XtSetMultiClickTime
XtSetSensitive
XtSetSubvalues
XtSetTypeConverter
XtSetValues
XtSetWMColormapWindows
XtSuperclass
XtToolkitInitialize
XtTranslateCoords
XtTranslateKey
XtTranslateKeycode
XtUngrabButton
XtUngrabKey
XtUngrabKeyboard
XtUngrabPointer
XtUninstallTranslations
XtUnmanageChild
XtUnmanageChildren
XtUnmapWidget
XtUnrealizeWidget
XtVaAppCreateShell
XtVaAppInitialize
XtVaCreateArgsList
XtVaCreateManagedWidget
XtVaCreatePopupShell
XtVaCreateWidget
XtVaGetApplicationResources
XtVaGetSubresources
XtVaGetSubvalues
XtVaGetValues
XtVaSetSubvalues
XtVaSetValues
XtWidgetToApplicationContext
XtWindow
XtWindowOfObject
XtWindowToWidget*Function is new to the Fourth Edition of the ABI.

6-36

M

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 137

The libXt library requires that some global external data objects be defined forthe routines to work properly. The data symbols listed in the table below must be
provided by the libXt library.

G
GG

For formal declarations of the data objects represented by these symbols, see the‘‘Data Definitions’’ section of Chapter 6 in the appropriate processor supplement
to the System V ABI. The names of those symbols not defined in the Processor
Supplement are reserved for the implementation of libXt.

G
G
G
G

Figure 6-26: libXt Contents, Global External Data Symbols
applicationShellClassRec
overrideShellClassRec
transientShellWidgetClass
applicationShellWidgetClass overrideShellWidgetClass vendorShellClassReccolorConvertArgs
rectObjClass
vendorShellWidgetClass
compositeClassRec
rectObjClassRec
widgetClass
compositeWidgetClass
screenConvertArg
widgetClassRec
constraintClassRecshellClassRec
wmShellClassRec
constraintWidgetClassshellWidgetClass
wmShellWidgetClass
coreWidgetClass
topLevelShellClassRec
XtShellStrings
objectClass
topLevelShellWidgetClass XtStrings
objectClassRec
transientShellClassRec

NOTE

The Data Symbols XtShellStrings and XtStrings may not be maintainedin an upwardly compatible manner. Future treatment of these arrays may be
handled differently on each platform.

X Toolkit Intrinsics Library

G

6-37

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 138

Motif Libraries

M

The libraries libXm and libXMrm contains library routines that provide theGraphical User Interface components of the Motif interface. The current versionof Motif supported by the gABI is Motif 1.2 as defined in OSF’s Motif Programmer
Reference Revision 1.2. This library is required for all ABI-conforming systems
that implement a graphical windowing terminal interface. See Chapter 10 of the
System V ABI, ‘‘Windowing and Terminal Interfaces’’ for more information on
windowing software requirements on ABI-conforming systems.

M
M
M
M
M
M
M

The following functions reside in libXm and must be provided on all ABIconforming systems that implement a graphical windowing terminal interface.

M
M

6-38

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 139

Figure 6-27: libXm Contents *XmActivateProtocol
XmAddProtocolCallback
XmAddProtocols
XmAddTabGroup
XmCascadeButtonGadgetHighlight
XmCascadeButtonHighlight
XmChangeColor
XmClipboardCancelCopy
XmClipboardCopy
XmClipboardCopyByName
XmClipboardEndCopy
XmClipboardEndRetrieve
XmClipboardInquireCount
XmClipboardInquireFormat
XmClipboardInquireLength
XmClipboardInquirePendingItems
XmClipboardLock
XmClipboardRegisterFormat
XmClipboardRetrieve
XmClipboardStartCopy
XmClipboardStartRetrieve
XmClipboardUndoCopy
XmClipboardUnlock
XmClipboardWithdrawFormat
XmCommandAppendValue
XmCommandError
XmCommandGetChild
XmCommandSetValue
XmConvertUnits
XmCreateArrowButton
XmCreateArrowButtonGadget
XmCreateBulletinBoard
XmCreateBulletinBoardDialog
XmCreateCascadeButton
XmCreateCascadeButtonGadget
XmCreateCommand
XmCreateDialogShell
XmCreateDragIcon

XmCreateDrawingArea
XmCreateDrawnButton
XmCreateErrorDialog
XmCreateFileSelectionBox
XmCreateFileSelectionDialog
XmCreateForm
XmCreateFormDialog
XmCreateFrame
XmCreateInformationDialog
XmCreateLabel
XmCreateLabelGadget
XmCreateList
XmCreateMainWindow
XmCreateMenuBar
XmCreateMenuShell
XmCreateMessageBox
XmCreateMessageDialog
XmCreateOptionMenu
XmCreatePanedWindow
XmCreatePopupMenu
XmCreatePromptDialog
XmCreatePulldownMenu
XmCreatePushButton
XmCreatePushButtonGadget
XmCreateQuestionDialog
XmCreateRadioBox
XmCreateRowColumn
XmCreateScale
XmCreateScrollBar
XmCreateScrolledList
XmCreateScrolledText
XmCreateScrolledWindow
XmCreateSelectionBox
XmCreateSelectionDialog
XmCreateSeparator
XmCreateSeparatorGadget
XmCreateSimpleCheckBox
XmCreateSimpleMenuBar

Motif Libraries

6-39

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 140

Figure 6-27: libXm Contents * (continued )XmCreateSimpleOptionMenu
XmFontListEntryGetTag
XmCreateSimplePopupMenu
XmFontListEntryLoad
XmCreateSimplePulldownMenu
XmFontListFree
XmCreateSimpleRadioBox
XmFontListFreeFontContext
XmCreateTemplateDialog
XmFontListGetNextFont
XmCreateText
XmFontListInitFontContext
XmCreateTextField
XmFontListNextEntry
XmCreateToggleButton
XmFontListRemoveEntry
XmCreateToggleButtonGadget
XmGetAtomName
XmCreateWarningDialog
XmGetColorCalculation
XmCreateWorkArea
XmGetColors
XmCreateWorkingDialog
XmGetDestination
XmCvtCTToXmString
XmGetDragContext
XmCvtStringToUnitType
XmGetFocusWidget
XmCvtXmStringToCT
XmGetMenuCursor
XmDeactivateProtocol
XmGetPixmap
XmDestroyPixmap
XmGetPixmapByDepth
XmDragCancel
XmGetPostedFromWidget
XmDragStart
XmGetSecondaryResourceData
XmDropSiteConfigureStackingOrder XmGetTabGroup
XmDropSiteEndUpdate
XmGetTearOffControl
XmDropSiteQueryStackingOrder
XmGetVisibility
XmDropSiteRegister
XmGetXmDisplay
XmDropSiteRetrieve
XmGetXmScreen
XmDropSiteStartUpdate
XmInstallImage
XmDropSiteUnregister
XmInternAtom
XmDropSiteUpdate
XmIsMotifWMRunning
XmDropTransferAdd
XmIsTraversable
XmDropTransferStart
XmListAddItem
XmFileSelectionBoxGetChild
XmListAddItems
XmFileSelectionDoSearch
XmListAddItemsUnselected
XmFontListAdd
XmListAddItemUnselected
XmFontListAppendEntry
XmListDeleteAllItems
XmFontListCopy
XmListDeleteItem
XmFontListCreate
XmListDeleteItems
XmFontListEntryCreate
XmListDeleteItemsPos
XmFontListEntryFree
XmListDeletePos
XmFontListEntryGetFont
XmListDeletePositions

6-40

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 141

Figure 6-27: libXm Contents * (continued )XmListDeselectAllItems
XmListDeselectItem
XmListDeselectPos
XmListGetKbdItemPos
XmListGetMatchPos
XmListGetSelectedPos
XmListItemExists
XmListItemPos
XmListPosSelected
XmListPosToBounds
XmListReplaceItems
XmListReplaceItemsPos
XmListReplaceItemsPosUnselected
XmListReplaceItemsUnselected
XmListReplacePositions
XmListSelectItem
XmListSelectPos
XmListSetAddMode
XmListSetBottomItem
XmListSetBottomPos
XmListSetHorizPos
XmListSetItem
XmListSetKbdItemPos
XmListSetPos
XmListUpdateSelectedList
XmListYToPos
XmMainWindowSep1
XmMainWindowSep2
XmMainWindowSep3
XmMainWindowSetAreas
XmMapSegmentEncoding
XmMenuPosition
XmMessageBoxGetChild
XmOptionButtonGadget
XmOptionLabelGadget
XmProcessTraversal
XmRegisterSegmentEncoding
XmRemoveProtocolCallback

XmRemoveProtocols
XmRemoveTabGroup
XmRepTypeAddReverse
XmRepTypeGetId
XmRepTypeGetNameList
XmRepTypeGetRecord
XmRepTypeGetRegistered
XmRepTypeInstallTearOffModelConverter
XmRepTypeRegister
XmRepTypeValidValue
XmResolveAllPartOffsets
XmResolvePartOffsets
XmScaleGetValue
XmScaleSetValue
XmScrollBarGetValues
XmScrollBarSetValues
XmScrolledWindowSetAreas
XmScrollVisible
XmSelectionBoxGetChild
XmSetColorCalculation
XmSetFontUnit
XmSetFontUnits
XmSetMenuCursor
XmSetProtocolHooks
XmStringBaseline
XmStringByteCompare
XmStringCompare
XmStringConcat
XmStringCopy
XmStringCreate
XmStringCreateLocalized
XmStringCreateLtoR
XmStringCreateSimple
XmStringDirectionCreate
XmStringDraw
XmStringDrawImage
XmStringDrawUnderline
XmStringEmpty

Motif Libraries

6-41

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 142

Figure 6-27: libXm Contents * (continued )XmStringExtent
XmStringFree
XmStringFreeContext
XmStringGetLtoR
XmStringGetNextComponent
XmStringGetNextSegment
XmStringHasSubstring
XmStringHeight
XmStringInitContext
XmStringLength
XmStringLineCount
XmStringNConcat
XmStringNCopy
XmStringPeekNextComponent
XmStringSegmentCreate
XmStringSeparatorCreate
XmStringWidth
XmTargetsAreCompatible
XmTextClearSelection
XmTextCopy
XmTextCut
XmTextDisableRedisplay
XmTextEnableRedisplay
XmTextFieldClearSelection
XmTextFieldCopy
XmTextFieldCut
XmTextFieldGetBaseline
XmTextFieldGetEditable
XmTextFieldGetInsertionPosition
XmTextFieldGetLastPosition
XmTextFieldGetMaxLength
XmTextFieldGetSelection
XmTextFieldGetSelectionPosition
XmTextFieldGetSelectionWcs
XmTextFieldGetString
XmTextFieldGetStringWcs
XmTextFieldGetSubstring
XmTextFieldGetSubstringWcs

XmTextFieldInsert
XmTextFieldInsertWcs
XmTextFieldPaste
XmTextFieldPosToXY
XmTextFieldRemove
XmTextFieldReplace
XmTextFieldReplaceWcs
XmTextFieldSetAddMode
XmTextFieldSetEditable
XmTextFieldSetHighlight
XmTextFieldSetInsertionPosition
XmTextFieldSetMaxLength
XmTextFieldSetSelection
XmTextFieldSetString
XmTextFieldSetStringWcs
XmTextFieldShowPosition
XmTextFieldXYToPos
XmTextFindString
XmTextFindStringWcs
XmTextGetBaseLine
XmTextGetBaseline
XmTextGetEditable
XmTextGetInsertionPosition
XmTextGetLastPosition
XmTextGetMaxLength
XmTextGetSelection
XmTextGetSelectionPosition
XmTextGetSelectionWcs
XmTextGetSource
XmTextGetString
XmTextGetStringWcs
XmTextGetSubstring
XmTextGetSubstringWcs
XmTextGetTopCharacter
XmTextInsert
XmTextInsertWcs
XmTextPaste
XmTextPosToXY

6-42

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 143

Figure 6-27: libXm Contents * (continued )XmTextRemove
XmTextReplace
XmTextReplaceWcs
XmTextScroll
XmTextSetAddMode
XmTextSetEditable
XmTextSetHighlight
XmTextSetInsertionPosition
XmTextSetMaxLength
XmTextSetSelection
XmTextSetSource
XmTextSetString
XmTextSetStringWcs
XmTextSetTopCharacter
XmTextShowPosition
XmTextXYToPos
XmToggleButtonGadgetGetState

XmToggleButtonGadgetSetState
XmToggleButtonGetState
XmToggleButtonSetState
XmTrackingEvent
XmTrackingLocate
XmTranslateKey
XmUninstallImage
XmUpdateDisplay
XmVaCreateSimpleCheckBox
XmVaCreateSimpleMenuBar
XmVaCreateSimpleOptionMenu
XmVaCreateSimplePopupMenu
XmVaCreateSimplePulldownMenu
XmVaCreateSimpleRadioBox
XmWidgetGetBaselines
XmWidgetGetDisplayRect* All functions in this table are new to the Fourth Edition of the ABI. The libXm libraryrequires that some global external data objects be defined for the routines to work
properly. The data symbols listed in the table below must be provided by the
libXm library.

M
M
M
M

For formal declarations of the data objects represented by these symbols, see the‘‘Data Definitions’’ section of Chapter 6 in the appropriate processor supplement
to the System V ABI. The names of those symbols not defined in the Processor
Supplement are reserved for the implementation of libXm.

M
M
M
M

Motif Libraries

6-43

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 144

Figure 6-28: libXm Contents *, Global External Data Symbols
vendorShellClassRec
xmExtObjectClass
vendorShellWidgetClassxmFileSelectionBoxClassRec
xmArrowButtonClassRec
xmFileSelectionBoxWidgetClass
xmArrowButtonGadgetClassxmFormClassRec
xmArrowButtonGadgetClassRec
xmFormWidgetClass
xmArrowButtonWidgetClassxmFrameClassRec
xmBulletinBoardClassRec
xmFrameWidgetClass
xmBulletinBoardWidgetClass
xmGadgetClass
xmCascadeButtonClassRec
xmGadgetClassRec
xmCascadeButtonGadgetClassxmLabelClassRec
xmCascadeButtonGadgetClassRec
xmLabelGadgetClass
xmCascadeButtonGCacheObjClassRec xmLabelGadgetClassRec
xmCascadeButtonWidgetClassxmLabelGCacheObjClassRec
xmCommandClassRec
xmLabelWidgetClass
xmCommandWidgetClass
xmListClassRec
xmDesktopClass
xmListWidgetClass
xmDesktopClassRec
xmMainWindowClassRec
xmDialogShellClassRec
xmMainWindowWidgetClass
xmDialogShellExtClassRec
xmManagerClassRec
xmDialogShellExtObjectClass
xmManagerWidgetClass
xmDialogShellWidgetClass
xmMenuShellClassRec
xmDisplayClass
xmMenuShellWidgetClass
xmDisplayClassRec
xmMessageBoxClassRec
xmDragContextClass
xmMessageBoxWidgetClass
xmDragContextClassRec
xmPanedWindowClassRec
xmDragIconClassRec
xmPanedWindowWidgetClass
xmDragIconObjectClass
xmPrimitiveClassRec
xmDragOverShellClassRec
xmPrimitiveWidgetClass
xmDragOverShellWidgetClass
xmProtocolClassRec
xmDrawingAreaClassRec
xmProtocolObjectClass
xmDrawingAreaWidgetClass
xmPushButtonClassRec
xmDrawnButtonClassRec
xmPushButtonGadgetClass
xmDrawnButtonWidgetClass
xmPushButtonGadgetClassRec
xmDropSiteManagerClassRec
xmPushButtonGCacheObjClassRec
xmDropSiteManagerObjectClass
xmPushButtonWidgetClass
xmDropTransferClassRec
XmQmotif
xmDropTransferObjectClass
xmRowColumnClassRec
xmExtClassRec
xmRowColumnWidgetClass

6-44

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 145

Figure 6-28: libXm Contents *, Global External Data Symbols (continued )xmSashClassRec
xmSashWidgetClass
xmScaleClassRec
xmScaleWidgetClass
xmScreenClass
xmScreenClassRec
xmScrollBarClassRec
xmScrollBarWidgetClass
xmScrolledWindowClassRec
xmScrolledWindowWidgetClassxmSelectionBoxClassRec
xmSelectionBoxWidgetClass
xmSeparatorClassRec
xmSeparatorGadgetClass
xmSeparatorGadgetClassRec
xmSeparatorGCacheObjClassRec
xmSeparatorWidgetClass
xmShellExtClassRec

xmShellExtObjectClass
xmTearOffButtonClassRec
xmTearOffButtonWidgetClass
xmTextClassRec
xmTextFieldClassRec
xmTextFieldWidgetClass
xmTextWidgetClass
xmToggleButtonClassRec
xmToggleButtonGadgetClass
xmToggleButtonGadgetClassRec
xmToggleButtonGCacheObjClassRec
xmToggleButtonWidgetClass
xmUseVersion
xmVendorShellExtClassRec
xmVendorShellExtObjectClass
xmWorldClass
xmWorldClassRec* All functions in this table are new to the Fourth Edition of the ABI.

M

The following functions reside in libMrm and must be provided on all ABIconforming systems that implement a graphical windowing terminal interface.

M
M

Figure 6-29: libMrm Contents *MrmCloseHierarchy
MrmFetchWidgetOverride
MrmFetchBitmapLiteral MrmInitialize
MrmFetchColorLiteral MrmOpenHierarchy
MrmFetchIconLiteral
MrmOpenHierarchyPerDisplay
MrmFetchLiteral
MrmRegisterClass
MrmFetchSetValues
MrmRegisterNames
MrmFetchWidget
MrmRegisterNamesInHierarchy* All functions in this table are new to the Fourth Edition of the ABI.

Motif Libraries

M

6-45

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 146

System Data Interfaces
Standard header files that describe system data are available for C application
developers to use. These files are referred to by their name in angle brackets:<name.h>, <sys/name.h> and <X11/name.h>. Included in these headers aremacro definitions, data definitions, and function declarations. The parts of theheader files specified in the ANSI C standard are the only parts available tostrictly-conforming ANSI C applications. Similarly, only the portions of theheader files defined in the POSIX P1003.1 Operating System Standard are available to strictly POSIX-conforming applications.
Some of the following header files define interfaces directly available to applications, and those interfaces will be common to systems on all processors. Other
header files show specific implementations of standard interfaces, where theimplementation or data definitions might change from one processor to another.
The ABI does not distinguish between these files. It gives data definitions to promote binary application portability, not to repeat source interface definitions
available elsewhere. System providers and application developers should use the
ABI to supplement—not to replace—source interface definition documents.
NOTE

Some type and data definitions appear in multiple headers. Special
definitions are included in the headers to avoid conflicts.

The application execution environment presents the interfaces described below,
but the ABI does not require the presence of the header files themselves. In otherwords, an ABI-conforming system is not required to provide an application
development environment.

Required Sizes for Some Data Objects
The continued evolution of System V requires that some fundamental data objects
be expanded so that the operating system will work more efficiently with systemsof different sizes and with networks of systems. To promote both binary portability for applications and interoperability for networks of systems, the System V ABI
requires that all conforming implementations use the expanded data object sizes
shown in the table below at a minimum.

6-46

LIBRARIESDRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 147

M

A given architecture may expand one or more of the following objects’ sizes, but
any such further expansion must be made explicit in the processor supplement to
the System V ABI for that processor architecture. Further, the sizes in the tablebelow should be considered as absolute (not minimal) for purposes of interoperation among networks of heterogeneous systems.
Figure 6-30: Minimum Sizes of Fundamental Data Objects

Data
ObjectType Definition
Size (bits)________________________________________________
User identifier
uid_t
32
Group Identifier
gid_t
32
Process identifier
pid_t
32
Inode identifier
ino_t
32
Device identifier
dev_t
32
File system identifier dev_t
32
Error identifier
int
32
time_t32
Time
File mode indicator
mode_t32
countnlink_t32_Link_______________________________________________

Data Definitions (Processor-Specific)
NOTE

This section requires processor-specific information. The ABI supplement forthe desired processor describes the details.

System Data Interfaces

6-47

DRAFT COPY
March 18, 1997
File: chap6
386:adm.book:sum
Page: 148

7

FORMATS AND PROTOCOLSIntroduction

7-1

Archive File

7-2

Other Archive Formats

7-6

Terminfo Data Base

7-7

Formats and Protocols for Networking

7-10
7-10
7-11
7-22
7-22
7-22
7-22
7-23
7-23
7-24
7-25
7-25
7-26
7-26
7-26
7-27
7-33
7-36

XDR: External Data RepresentationXDR Data Types

Messaging Catalogues
RPC: Remote Procedure Call Protocol
Terminology
Transports and Semantics
Binding and Rendezvous Independence
Authentication
Programs and Procedures
Authentication
Program Number Assignment
Other Uses of the RPC Protocol
Batching
Broadcast RPC
The RPC Message Protocol
DES Authentication Protocol (in XDR language)
Record Marking Standard

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cchap7
386:adm.book:sum
Page: 149

rpcbind Mechanism

ii

7-37

Table of Contents

DRAFT COPY
March 18, 1997
File: Cchap7
386:adm.book:sum
Page: 150

Introduction
This chapter describes file and data formats and protocols that are visible to applications or that must be portable across System V implementations. Although thesystem provides standard programs to manipulate files in the formats described
here, portability is important enough to warrant descriptions of their formats.
This does not mean applications are encouraged to circumvent the system programs and manipulate the files directly. Instead, it means an ABI for any target
processor architecture must provide the system programs and library routines for
manipulating these file formats and implementing these protocols. Moreover,those programs must accept formats compatible with the ones described here.
Some system file formats explicitly do not appear in this chapter. For example,
the mount table file, traditionally called /etc/mnttab, is not a documented format. For information such as this, the system libraries described in Chapter 6 provide functions that applications may use to access the data. Programs that depend
on undocumented formats—or that depend on the existence of undocumented
files—are not ABI-conforming. Other files, such as the password file in/etc/passwd, have formats defined in other documents. These cases therefore do
not appear in the ABI, because the ABI does not replicate information available inother standards documents. Nonetheless, an ABI-conforming program may use
the files when the file names and formats are defined implicitly for the ABI
through references to other documents.

Introduction

7-1

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 151

Archive File
Archives package multiple files into one. They are commonly used as libraries ofrelocatable object files to be searched by the link editor. An archive file has the following format:
An archive magic string, ARMAG below;
An optional archive symbol table (created only if at least one member is anobject file that defines non-local symbols);
An optional archive string table (created only if at least one archive
member’s name is more than 15 bytes long);
For each ‘‘normal’’ file in the archive, an archive header and the unchanged
contents of the file.
The archive file’s magic string contains SARMAG bytes and does not include a terminating null byte.
Figure 7-1: <ar.h>#define ARMAG#define SARMAG#define ARFMAG"!<arch>\n"8"‘\n"struct ar_hdr {
char
char
char
char
char
char
char
};

ar_name[16];ar_date[12];ar_uid[6];ar_gid[6];ar_mode[8];ar_size[10];ar_fmag[2];All information in the member headers is printable ASCII.
ar_nameThis member represents the member’s file name. If the name fits,
it resides in the member directly, terminated with slash (/) andpadded with blanks on the right. If the member’s name is toolong to fit, the member contains a slash, followed by the decimal
representation of the name’s offset in the archive string table.

7-2

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 152

ar_date

This member holds the decimal representation of themodification date of the file at the time of its insertion into thearchive. Stat and time describe the modification time value.

X

ar_uidThis member holds the decimal representation of the member’suser identification number.

ar_gidThis member holds the decimal representation of the member’sgroup identification number.

ar_modeThis member holds the octal representation of the file systemmode.

ar_size

This member holds the decimal representation of the member’s
size in bytes.

ar_fmag

This member holds the first two bytes of the ARFMAG string,defined above.

Each member begins on an even byte boundary; a newline is inserted between
files if necessary. Nevertheless the ar_size member reflects the actual size of themember exclusive of padding. There is no provision for empty areas in an archive
file.
If some archive member’s name is more than 15 bytes long, a special archive
member contains a table of file names, each followed by a slash and a newline.
This string table member, if present, will precede all ‘‘normal’’ archive members.
The special archive symbol table is not a ‘‘normal’’ member, and must be first if itexists (see below). The ar_name entry of the string table’s member header holds azero length name (ar_name[0]= =’/’), followed by one trailing slash(ar_name[1]= =’/’), followed by blanks (ar_name[2]==’ ’, and so on). Offsets
into the string table begin at zero. Example ar_name values for short and long filenames appear below.
Offset
0
10
20
30

+0
+1
+2
+3
+4
+5
+6
+7
+8
+9
_____________________________________________________
_____________________________________________________f  i  l  e  n  a  m  e  s  a 











m  p  l  e  /  \n  l  o  n  g _____________________________________________________e  r  f  i  l  e  n  a  m  e 
_____________________________________________________
 x  a  m  p  l  e  /  \n 
_____________________________________________________











Archive File

7-3

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 153

Figure 7-2: Example String Table

Member Namear_nameNote_____________________________________________________________
 short-name/  Not in string table
short-name /0 Offset 0 in string table
filenamesamplelongerfilenamexample  /16_____________________________________________________________
 Offset 16 in string table

If an archive file has one or more object file members, its first member will be anarchive symbol table. This archive member has a zero length name, followed byblanks (ar_name[0]= =’/’, ar_name[1]==’ ’, and so on). All words in thissymbol table have four bytes, using the machine-independent encoding shown
below.
NOTE

All machines use the encoding described here for the symbol table, even if themachine’s ‘‘natural’’ byte order is different.

Figure 7-3: Archive Word Encoding

0x01020304

0

01

1

02

2

03

3

04

The symbol table holds the following:
A word containing the number of symbols in the symbol table (which is thesame as the number of entries in the file offset array);An array of words, holding file offsets into the archive;
The string table containing ar_size-4*(number symbols+1) bytes, whose
initial byte is numbered 0 and whose last byte holds a 0 value.
Entries in the string table and in the file offset array exactly correspond to eachother, and they both parallel the order of archive members. Thus if two or morearchive members define symbols with the same name (which is allowed), theirstring table entries will appear in the same order as their corresponding membersin the archive file. Each array entry associates a symbol with the archive memberthat defines the symbol; the file offset is the location of the archive header for thedesignated archive member.

7-4

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 154

As an example, the following symbol table defines 4 symbols. The archive
member at file offset 114 defines name and object. The archive member at fileoffset 426 defines function and a second version of name.
Figure 7-4: Example Symbol Table

Offset
0
4
8
12
16
20
24
28
32
36
40
44

+0
+1
+2
+3
_____________________
_____________________
 4 offset entries
4


114
_ ____________________
 name object114_ ____________________


4
2
6
_ ____________________ function426
_____________________
 name_____________________n  a  m  e 





\0  o  b  j _ ____________________
_____________________e  c  t  \0 
 f  u  n  c _ ____________________t  i  o  n 
_____________________
_____________________\0  n  a  m 





e  \0 
_____________________


Archive File

7-5

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 155

Other Archive Formats
ABI-conforming systems support archives created by the cpio command. Thesearchives are commonly used as a vehicle for collecting ASCII files for storage ortransmission.
For more information about these archives see the cpio manual page in the
X/Open CAE Specification, Issue 4.2 and the System V Interface Definition, Fourth Edition (see the Conformance Rule in chapter 1). The format of the archives the command creates is included in the IEEE POSIX P1003.1 specification. Also supported
are archives in the ASC/CRC format, created using the cpio command with the‘‘-H crc’’ option.

7-6

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 156

X
X
E
E

Terminfo Data Base
Each terminal’s capabilities are stored in a separate file named/usr/share/lib/terminfo/L/terminal_name, where terminal_name is the name of
the terminal, and L is the first letter of the terminal’s name. The specific capabilities described in the database and their names are given in the System V Interface
Definition, Fourth Edition on the terminfo(TI_ENV) pages. The format of this fileis given in the separate section that follows.
The terminfo database format is hardware-independent. An 8-bit byte is
assumed. Short integers are stored in two contiguous 8-bit bytes. The first byte
contains the least significant 8 bits of the value, and the second byte contains themost significant 8 bits. (Thus, the value represented is 256∗second+first.) The
value –1 is represented by 0377, 0377, and the value –2 is represented by 0376,
0377; other negative values are illegal. Computers where this does notcorrespond to the hardware read the integers as two bytes and compute the result,making the compiled entries portable across machine types. A –1 or a –2 in acapability field means that the capability is missing from a terminal.
The file contains six sections:header

The header contains six short integers in the format described
below. These integers are (1) the magic number (octal 0432);(2) the size, in bytes, of the names section; (3) the number ofbytes in the boolean section; (4) the number of short integers in
the numbers section; (5) the number of offsets (short integers)in the strings section; (6) the size, in bytes, of the string table.

terminal names

The terminal names section contains the first line of theterminfo(TI_ENV) description, listing the various names forthe terminal, separated by the ’|’ character. The section is terminated with an ASCII NUL character.

boolean flags

The boolean flags contain one byte for each flag. This byte iseither 0 or 1 to indicate whether a capability is present orabsent. The terminal capabilities are stored here in the sameorder in which that are listed under the Booleans heading of
the capability table in the terminfo(TI_ENV) section of the
System V Interface Definition, Fourth Edition. The flag value of 2means that the flag is invalid.

Terminfo Data Base

7-7

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 157



Between the boolean section and the number section, a nullbyte will be inserted, if necessary, to insure that the number
section begins on a byte with an even-numbered address. All
short integers are aligned on a short word boundary.
numbers

The numbers section is similar to the preceding boolean flags
section. Each capability is stored in two bytes as a short
integer. Terminal capabilities are stored here in the same orderin which they are listed under the Numbers heading of thecapability table in the terminfo(TI_ENV) section of the System
V Interface Definition, Fourth Edition. If the value represented is–1 or –2, the capability is missing.

strings

In the strings section, each capability is stored as a short
integer, in the same format given for preceding section. Terminal capabilities are stored here in the same order in which they
are listed under the Strings heading of the capability table in
the terminfo(TI_ENV) section of the System V Interface
Definition, Fourth Edition. A value of –1 or –2 means that acapability is missing. Otherwise, the value is taken as an offset
from the beginning of the string table.

string table

The final section is the string table. It contains all the values ofstring capabilities referenced in the string section. Each capability is stored as a null terminated string. Special characters in
ˆX or \ notation are stored in their interpreted form, not theprinting representation. Padding information ($<nn>) andparameter information (%x) are stored intact in uninterpretedform.

As an example, an octal dump of the compiled description for an AT&T Model 37
KSR is included:

7-8

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 158

∗






37|tty37|AT&T model 37 teletype,hc, os, xon,
bel=ˆG, cr=\r, cub1=\b, cud1=\n, cuu1=\E7, hd=\E9,
hu=\E8, ind=\n,0000000 032 001\0 032 \0 013 \0 021 001
3 \0
3
7
|
t
0000020
t
y
3
7
|
A
T
&
T
m
o
d
e
l
0000040
3
7
t
e
l
e
t
y
p
e \0 \0 \0 \0 \00000060 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \00000100 001 \0 \0 \0 \0 \0 377 377 377 377 377 377 377 377 377 377
0000120 377 377 377 377 377 377 377 377 377 377 377 377 377 377& \00000140\0 377 377 377 377 377 377 377 377 377 377 377 377 377 377
0000160 377 377" \0 377 377 377 377( \0 377 377 377 377 377 377
0000200 377 377
0 \0 377 377 377 377 377 377 377 377- \0 377 377
0000220 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377*
0000520 377 377 377 377 377 377 377 377 377 377 377 377 377 377$ \00000540 377 377 377 377 377 377 377 377 377 377 377 377 377 377* \00000560 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377*
0001160 377 377 377 377 377 377 377 377 377 377 377 377 377 377
370001200
|
t
t
y
3
7
|
A
T
&
T
m
o
d
e
0001220
l
3
7
t
e
l
e
t
y
p
e \0 \r \00001240 \n \0 \n \0 007 \0 \b \0 033
8 \0 033
9 \0 033
70001260 \0 \00001261
Some limitations: total compiled entries cannot exceed 4096 bytes and all entries in
the name field cannot exceed 128 bytes.

Terminfo Data Base

7-9

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 159

Formats and Protocols for Networking
This section describes a language for machine-independent data representationand two protocols used in remote procedure call service. All ABI-conforming systems that provide these services must implement these formats and protocols in
the appropriate routines in the libnsl library. See Chapter 6 of the System V ABI
for a list of the routines in this library.

XDR: External Data Representation
XDR is a method for the description and encoding of data. It is useful for transferring data between different computer architectures, where such characteristics asinternal byte-ordering may vary.
XDR uses a language to describe data formats. This language allows one todescribe intricate data formats in a concise manner.
The XDR language assumes that bytes (or octets) are portable, where a byte isdefined to be 8 bits of data. A given hardware device should encode the bytes
onto the various media in such a way that other hardware devices may decode thebytes without loss of meaning.
Basic Block Size
The representation of all items requires a multiple of four bytes (or 32 bits) of data.
The bytes are numbered 0 through n-1. The bytes are read or written to some byte
stream such that byte m always precedes byte m+1. If the n bytes needed to contain the data are not a multiple of four, then the n bytes are followed by enough (0to 3) residual zero bytes, r, to make the total byte count a multiple of 4.
The familiar graphic box notation has been used for illustration and comparison.
In most illustrations, each box (delimited by a plus sign at the 4 corners and vertical bars and dashes) depicts a byte. Ellipses (. . .) between boxes show zero or
more additional bytes where required.
A Block+--------+--------+...+--------+--------+...+--------+| byte 0 | byte 1 |...|byte n-1|
0
|...|
0
|
+--------+--------+...+--------+--------+...+--------+|<-----------n bytes---------->|<------r bytes------>||<-----------n+r (where (n+r) mod 4 = 0)>----------->|

7-10

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 160

XDR Data Types
Each of the sections that follow describes a data type defined in the XDR language,shows how it is declared in the language, and includes a graphic illustration of its
encoding.
For each defined data type we show a general paradigm declaration. Note thatangle brackets (< and >) denote variable length sequences of data and square
brackets ([ and ]) denote fixed-length sequences of data. ‘‘n’’, ‘‘m’’ and ‘‘r’’ denote
integers. For the full language specification and more formal definitions of terms
such as ‘‘identifier’’ and ‘‘declaration,’’ refer to ‘‘The XDR Language
Specification’’ , given in the System V Interface Definition, Fourth Edition.
For some data types, more specific examples are included below.
Integer
An XDR signed integer is a 32-bit datum that encodes an integer in the range[-2147483648,2147483647]. The integer is represented in two’s complement notation. The most and least significant bytes are 0 and 3, respectively. Integers are
declared as follows:Integer(MSB)(LSB)+-------+-------+-------+-------+|byte 0 |byte 1 |byte 2 |byte 3 |+-------+-------+-------+-------+<------------32 bits------------>
Unsigned Integer
An XDR unsigned integer is a 32-bit datum that encodes a nonnegative integer inthe range [0,4294967295]. It is represented by an unsigned binary number whose
most and least significant bytes are 0 and 3, respectively. An unsigned integer isdeclared as follows:
Unsigned Integer
(MSB)
(LSB)
+-------+-------+-------+-------+|byte 0 |byte 1 |byte 2 |byte 3 |+-------+-------+-------+-------+<------------32 bits------------>

Formats and Protocols for Networking

7-11

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 161

Enumeration
Enumerations have the same representation as signed integers. Enumerations are
handy for describing subsets of the integers. Enumerated data is declared as follows:enum { name-identifier = constant, . . . } identifier;For example, the three colors red, yellow, and blue could be described by anenumerated type:enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
It is an error to encode as an enum any other integer than those that have been
given assignments in the enum declaration.
BooleanBooleans are important enough and occur frequently enough to warrant their own
explicit type in the language. Booleans are declared as follows:
bool identifier;This is equivalent to:enum { FALSE = 0, TRUE = 1 } identifier;Floating-pointXDR defines the floating-point data type ‘‘float’’ (32 bits or 4 bytes). The encoding
used is the IEEE standard for normalized single-precision floating-point numbers.
The following three fields describe the single-precision floating-point number:S:

The sign of the number. Values 0 and 1 represent positive andnegative, respectively. One bit.

E:

The exponent of the number, base 2. 8 bits are devoted to thisfield. The exponent is biased by 127.

F:

The fractional part of the number’s mantissa, base 2. 23 bits are
devoted to this field.

Therefore, the floating-point number is described by:(-1)**S * 2**(E-Bias) * 1.F
It is declared as follows:

7-12

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 162

Single-Precision Floating-Point+-------+-------+-------+-------+|byte 0 |byte 1 |byte 2 |byte 3 |
S|
E
|
F
|
+-------+-------+-------+-------+
1|<- 8 ->|<-------23 bits------>|<------------32 bits------------>
Just as the most and least significant bytes of a number are 0 and 3, the most andleast significant bits of a single-precision floating- point number are 0 and 31. The
beginning bit (and most significant bit) offsets of S, E, and F are 0, 1, and 9, respectively. Note that these numbers refer to the mathematical positions of the bits,
and NOT to their actual physical locations (which vary from medium to medium).
The IEEE specifications should be consulted concerning the encoding for signed
zero, signed infinity (overflow), and denormalized numbers (underflow). According to IEEE specifications, the ‘‘NaN’’ (not a number) is system dependent andshould not be used externally.
Double-precision Floating-pointXDR defines the encoding for the double-precision floating- point data type ‘‘double’’ (64 bits or 8 bytes). The encoding used is the IEEE standard for normalized
double-precision floating-point numbers. XDR encodes the following three fields,
which describe the double-precision floating-point number:S:

The sign of the number. Values 0 and 1 represent positive andnegative, respectively. One bit.

E:

The exponent of the number, base 2. 11 bits are devoted to thisfield. The exponent is biased by 1023.

F:

The fractional part of the number’s mantissa, base 2. 52 bits are
devoted to this field.

Therefore, the floating-point number is described by:(-1)**S * 2**(E-Bias) * 1.F
It is declared as follows:

Formats and Protocols for Networking

7-13

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 163

Double-Precision Floating-Point+------+------+------+------+------+------+------+------+|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
S|
E
|
F
|
+------+------+------+------+------+------+------+------+
1|<--11-->|<-----------------52 bits------------------->|<-----------------------64 bits------------------------->
Just as the most and least significant bytes of a number are 0 and 3, the most andleast significant bits of a double-precision floating- point number are 0 and 63.
The beginning bit (and most significant bit) offsets of S, E , and F are 0, 1, and 12,
respectively. Note that these numbers refer to the mathematical positions of thebits, and NOT to their actual physical locations (which vary from medium tomedium).
The IEEE specifications should be consulted concerning the encoding for signed
zero, signed infinity (overflow), and denormalized numbers (underflow). According to IEEE specifications, the ‘‘NaN’’ (not a number) is system dependent andshould not be used externally.
Fixed-length Opaque Data
At times, fixed-length uninterpreted data needs to be passed among machines.
This data is called ‘‘opaque’’ and is declared as follows:
opaque identifier[n];where the constant n is the (static) number of bytes necessary to contain theopaque data. If n is not a multiple of four, then the n bytes are followed byenough (0 to 3) residual zero bytes, r, to make the total byte count of the opaqueobject a multiple of four.
Fixed-Length Opaque01...
+--------+--------+...+--------+--------+...+--------+| byte 0 | byte 1 |...|byte n-1|
0
|...|
0
|
+--------+--------+...+--------+--------+...+--------+|<-----------n bytes---------->|<------r bytes------>||<-----------n+r (where (n+r) mod 4 = 0)------------>|
Variable-length Opaque Data
XDR also provides for variable-length (counted) opaque data, defined as asequence of n (numbered 0 through n-1) arbitrary bytes to be the number n
encoded as an unsigned integer (as described below), and followed by the n bytesof the sequence.

7-14

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 164

Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of
the sequence always follows the sequence’s length (count). If n is not a multiple offour, the the n bytes are followed by enough (0 to 3) residual zero bytes, r, to makethe total byte count a multiple of four. Variable-length opaque data is declared in
the following way:
opaque identifier<m>;or
opaque identifier<>;
The constant m denotes an upper bound of the number of bytes that the sequence
may contain. If m is not specified, as in the second declaration, it is assumed to be(2**32) - 1, the maximum length. The constant m would normally be found in a
protocol specification. For example, a filing protocol may state that the maximum
data transfer size is 8192 bytes, as follows:
opaque filedata<8192>;
This can be illustrated as follows:
Variable-Length Opaque
0
1
2
3
4
5
...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+|
length n|byte0|byte1|...| n-1 | 0 |...| 0 |+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+|<-------4 bytes------->|<------n bytes------>|<---r bytes--->||<----n+r (where (n+r) mod 4 = 0)---->|
It is an error to encode a length greater than the maximum described in thespecification.
StringXDR defines a string of n (numbered 0 through n-1) ASCII bytes to be the number
n encoded as an unsigned integer (as described above), and followed by the nbytes of the string. Byte m of the string always precedes byte m+1 of the string,and byte 0 of the string always follows the string’s length. If n is not a multiple offour, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, tomake the total byte count a multiple of four. Counted byte strings are declared asfollows:
string object<m>;orstring object<>;

Formats and Protocols for Networking

7-15

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 165

The constant m denotes an upper bound of the number of bytes that a string may
contain. If m is not specified, as in the second declaration, it is assumed to be(2**32) - 1, the maximum length. The constant m would normally be found in a
protocol specification. For example, a filing protocol may state that a file namecan be no longer than 255 bytes, as follows:
string filename<255>;
Which can be illustrated as:
A String
0
1
2
3
4
5
...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+|
length n|byte0|byte1|...| n-1 | 0 |...| 0 |+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+|<-------4 bytes------->|<------n bytes------>|<---r bytes--->||<----n+r (where (n+r) mod 4 = 0)---->|
It is an error to encode a length greater than the maximum described in thespecification.
Fixed-length Array
Declarations for fixed-length arrays of homogeneous elements are in the following
form:
type-name identifier[n];Fixed-length arrays of elements numbered 0 through n-1 are encoded by individually encoding the elements of the array in their natural order, 0 through n-1. Eachelement’s size is a multiple of four bytes. Though all elements are of the same
type, the elements may have different sizes. For example, in a fixed-length arrayof strings, all elements are of ‘‘type string,’’ yet each element will vary in its
length.
Fixed-Length Array+---+---+---+---+---+---+---+---+...+---+---+---+---+|
element 0|
element 1|...| element n-1 |+---+---+---+---+---+---+---+---+...+---+---+---+---+|<--------------------n elements------------------->|

7-16

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 166

Variable-length Array
Counted arrays provide the ability to encode variable-length arrays of homogeneous elements. The array is encoded as the element count n (an unsigned integer)
followed by the encoding of each of the array’s elements, starting with element 0
and progressing through element n- 1. The declaration for variable-length arrays
follows this form:
type-name identifier<m>;or
type-name identifier<>;
The constant m specifies the maximum acceptable element count of an array; if m
is not specified, as in the second declaration, it is assumed to be (2**32) - 1.
Counted Array
0 1 2 3+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+|n| element 0 | element 1 |...|element n-1|+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+|<-4 bytes->|<--------------n elements------------->|
It is an error to encode a value of n that is greater than the maximum described in
the specification.
Structure
Structures are declared as follows:

struct {component-declaration-A;
component-declaration-B;...
} identifier;

The components of the structure are encoded in the order of their declaration in
the structure. Each component’s size is a multiple of four bytes, though the components may be different sizes.

Formats and Protocols for Networking

7-17

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 167

Structure+-------------+-------------+...
| component A | component B |...
+-------------+-------------+...
Discriminated Union
A discriminated union is a type composed of a discriminant followed by a typeselected from a set of prearranged types according to the value of the discriminant. The type of discriminant is either ‘‘int,’’ ‘‘unsigned int,’’ or an enumerated
type, such as ‘‘bool’’. The component types are called ‘‘arms’’ of the union, andare preceded by the value of the discriminant which implies their encoding.
Discriminated unions are declared as follows:

union switch (discriminant-declaration) {case discriminant-value-A:
arm-declaration-A;
case discriminant-value-B:
arm-declaration-B;...
default: default-declaration;} identifier;

Each ‘‘case’’ keyword is followed by a legal value of the discriminant. The default
arm is optional. If it is not specified, then a valid encoding of the union cannot
take on unspecified discriminant values. The size of the implied arm is always amultiple of four bytes.
The discriminated union is encoded as its discriminant followed by the encodingof the implied arm.
Discriminated Union0123+---+---+---+---+---+---+---+---+| discriminant | implied arm |+---+---+---+---+---+---+---+---+|<---4 bytes--->|

7-18

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 168

Void
An XDR void is a 0-byte quantity. Voids are useful for describing operations thattake no data as input or no data as output. They are also useful in unions, wheresome arms may contain data and others do not. The declaration is simply as follows:
void;
Voids are illustrated as follows:++++--><-- 0 bytes
Constant
The data declaration for a constant follows this form:
const name-identifier = n;‘‘const’’ is used to define a symbolic name for a constant; it does not declare any
data. The symbolic constant may be used anywhere a regular constant may be
used. For example, the following defines a symbolic constant DOZEN, equal to
12.
const DOZEN = 12;
Typedef‘‘"typedef’’ does not declare any data either, but serves to define new identifiers
for declaring data. The syntax is:
typedef declaration;
The new type name is actually the variable name in the declaration part of thetypedef. For example, the following defines a new type called ‘‘eggbox’’ using an
existing type called ‘‘egg’’:
typedef egg eggbox[DOZEN];
Variables declared using the new type name have the same type as the new typename would have in the typedef, if it was considered a variable. For example, thefollowing two declarations are equivalent in declaring the variable ‘‘fresheggs’’:
eggbox fresheggs;
egg fresheggs[DOZEN];

Formats and Protocols for Networking

7-19

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 169

When a typedef involves a struct, enum, or union definition, there is another (preferred) syntax that may be used to define the same type. In general, a typedef ofthe following form:
typedef <<struct, union, or enum definition>> identifier;may be converted to the alternative form by removing the ‘‘typedef’’ part andplacing the identifier after the ‘‘struct,’’ ‘‘union,’’ or ‘‘enum’’ keyword, instead ofat the end. For example, here are the two ways to define the type ‘‘bool’’:

typedef enum {/* using typedef */FALSE = 0,
TRUE = 1} bool;enum bool {/* preferred alternative */FALSE = 0,
TRUE = 1};

The reason this syntax is preferred is one does not have to wait until the end of adeclaration to figure out the name of the new type.
Optional-data
Optional-data is one kind of union that occurs so frequently that we give it a special syntax of its own for declaring it. It is declared as follows:
type-name *identifier;This is equivalent to the following union:

union switch (bool opted) {case TRUE:
type-name element;case FALSE:
void;} identifier;

It is also equivalent to the following variable-length array declaration, since theboolean ‘‘opted’’ can be interpreted as the length of the array:
type-name identifier<1>;

7-20

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 170

Optional-data is not so interesting in itself, but it is very useful for describing
recursive data-structures such as linked-lists and trees. For example, the following defines a type ‘‘stringlist’’ that encodes lists of arbitrary length strings:

struct *stringlist {string item<>;stringlist next;};

It could have been equivalently declared as the following union:

union stringlist switch (bool opted) {case TRUE:
struct {string item<>;stringlist next;} element;case FALSE:
void;
};

or as a variable-length array:

struct stringlist<1> {string item<>;stringlist next;};

Both of these declarations obscure the intention of the stringlist type, so theoptional-data declaration is preferred over both of them. The optional-data typealso has a close correlation to how recursive data structures are represented inhigh-level languages such as Pascal or C by use of pointers. In fact, the syntax isthe same as that of the C language for pointers.

Formats and Protocols for Networking

7-21

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 171E

Messaging Catalogues

E

An ABI conforming implementation will include the gencat utility to convert thesource of XPG3 conforming source message catalogues into a form understandable by the run-time system. Applications that attempt to provide message catalogues in any other format are not ABI conforming.

E
E
E

RPC: Remote Procedure Call Protocol
This section specifies the protocol to be used in the remote procedure call package
implemented by routines in the libnsl library described in Chapter 6. The protocol is specified with the external data representation (XDR) language partly
described in the preceding section of the System V ABI.

Terminology
This section discusses servers, services, programs, procedures, clients, and versions. A server is a piece of software where network services are implemented. A
network service is a collection of one or more remote programs. A remote program implements one or more remote procedures; the procedures, their parameters, and results are documented in the specific program’s protocol specification(see the rpcbind protocol, below, for an example). Network clients are pieces ofsoftware that initiate remote procedure calls to services. A server may support
more than one version of a remote program in order to be forward compatible
with changing protocols.

Transports and Semantics
The RPC protocol is independent of transport protocols. That is, RPC does notcare how a message is passed from one process to another. The protocol deals
only with specification and interpretation of messages.
It is important to point out that RPC does not try to implement any kind of reliability and that the application must be aware of the type of transport protocol
underneath RPC. If it knows it is running on top of a reliable transport such as
TCP/IP, then most of the work is already done for it. On the other hand, if it isrunning on top of an unreliable transport such as UDP/IP, it must implement is
own retransmission and time-out policy as the RPC layer does not provide thisservice.
Because of transport independence, the RPC protocol does not attach specificsemantics to the remote procedures or their execution. Semantics can be inferredfrom (but should be explicitly specified by) the underlying transport protocol. For
example, consider RPC running on top of an unreliable transport such as UDP/IP.

7-22

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 172

If an application retransmits RPC messages after short time-outs, the only thing it
can infer if it receives no reply is that the procedure was executed zero or moretimes. If it does receive a reply, then it can infer that the procedure was executedat least once.
A server may wish to remember previously granted requests from a client and notregrant them in order to insure some degree of execute-at-most-once semantics. A
server can do this by taking advantage of the transaction ID that is packaged withevery RPC request. The main use of this transaction is by the client RPC layer inmatching replies to requests. However, a client application may choose to reuseits previous transaction ID when retransmitting a request. The server application,
knowing this fact, may choose to remember this ID after granting a request andnot regrant requests with the same ID in order to achieve some degree of executeat-most-once semantics. The server is not allowed to examine this ID in any otherway except as a test for equality.
On the other hand, if using a reliable transport such as TCP/IP, the application
can infer from a reply message that the procedure was executed exactly once, but
if it receives no reply message, it cannot assume the remote procedure was not
executed. Note that even if a connection-oriented protocol like TCP is used, anapplication still needs time-outs and reconnection to handle server crashes.
There are other possibilities for transports besides datagram- or connectionoriented protocols. For example, a request-reply protocol such as VMTP isperhaps the most natural transport for RPC.

Binding and Rendezvous Independence
The act of binding a client to a service is NOT part of the remote procedure callspecification. This important and necessary function is left up to some higherlevel software. (The software may use RPC itself—see the rpcbind protocol, below).
Implementors should think of the RPC protocol as the jump-subroutine instruction ("JSR") of a network; the loader (binder) makes JSR useful, and the loader
itself uses JSR to accomplish its task. Likewise, the network makes RPC useful,using RPC to accomplish this task.

Authentication
The RPC protocol provides the fields necessary for a client to identify itself to aservice and vice-versa. Security and access control mechanisms can be built on topof the message authentication. Several different authentication protocols can besupported. A field in the RPC header indicates which protocol is being used.
More information on specific authentication protocols can be found in the Authentication Protocols, below.

Formats and Protocols for Networking

7-23

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 173

Programs and Procedures
The RPC call message has three unsigned fields: remote program number, remote
program version number, and remote procedure number. The three fields
uniquely identify the procedure to be called. Program numbers are administeredby some central authority. Once an implementor has a program number, he canimplement his remote program; the first implementation would most likely havethe version number of 1. Because most new protocols evolve into better, stable,
and mature protocols, a version field of the call message identifies which versionof the protocol the caller is using. Version numbers make speaking old and new
protocols through the same server process possible.
The procedure number identifies the procedure to be called. These numbers are
documented in the specific program’s protocol specification. For example, a fileservice’s protocol specification may state that its procedure number 5 is ‘‘read’’and procedure number 12 is ‘‘write’’.
Just as remote program protocols may change over several versions, the actual
RPC message protocol could also change. Therefore, the call message also has in it
the RPC version number, which is equal to two for the version of RPC described
here.

E
E

The reply message to a request message has enough information to distinguish thefollowing error conditions:
1 . The remote implementation of RPC does not speak the requested protocol
version number. The lowest and highest supported RPC version numbers
are returned.

EE

2 . The remote program is not available on the remote system.
3 . The remote program does not support the requested version number. The
lowest and highest supported remote program version numbers are
returned.
4 . The requested procedure number does not exist. (This is usually a callerside protocol or programming error.)
5 . The parameters to the remote procedure appear to be garbage from theserver’s point of view. (Again, this is usually caused by a disagreement
about the protocol between client and service.)
The remote implementation of RPC supports protocol version 2.

7-24

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 174

E

Authentication
Provisions for authentication of caller to service and vice-versa are provided as apart of the RPC protocol. The call message has two authentication fields, thecredentials and verifier. The reply message has one authentication field, theresponse verifier. The RPC protocol specification defines all three fields to be thefollowing opaque type:enum auth_flavor {AUTH_NULL = 0,
AUTH_SYS= 1,
AUTH_DES= 3/* and more to be defined */};struct opaque_auth {auth_flavor flavor;
opaque body<400>;};

Any opaque_auth structure is an auth_flavor enumeration followed by bytes
which are opaque to the RPC protocol implementation.
The interpretation and semantics of the data contained within the authentication
fields is specified by individual, independent authentication protocol
specifications. (See Authentication Protocols, below, for definitions of the various
authentication protocols.)
If authentication parameters were rejected, the response message contains information stating why they were rejected.

Program Number Assignment
Program numbers are given out in groups of 0x20000000 (decimal 536870912)
according to the following chart:

Formats and Protocols for Networking

7-25

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 175

___________________________________________________

Program Numbers
Description___________________________________________________

0 - 1fffffff Defined by a central authority  20000000 - 3fffffff Defined by user
 40000000 - 5fffffff Transient 60000000 - 7fffffff Reserved 80000000 - 9fffffff Reserved a0000000 - bfffffff Reserved c0000000 - dfffffff Reserved
e0000000 - ffffffff Reserved
___________________________________________________
The first group is a range of numbers administered by a central authority andshould be identical for all sites. The second range is for applications peculiar to aparticular site. This range is intended primarily for debugging new programs.
When a site develops an application that might be of general interest, that application should be given an assigned number in the first range. The third group is forapplications that generate program numbers dynamically. The final groups arereserved for future use, and should not be used.

Other Uses of the RPC Protocol
The intended use of this protocol is for calling remote procedures. That is, eachcall message is matched with a response message. However, the protocol itself is amessage-passing protocol with which other (non-RPC) protocols can be implemented. Here are two examples:

Batching
Batching allows a client to send an arbitrarily large sequence of call messages to aserver; batching typically uses reliable byte stream protocols (like TCP/IP) for its
transport. In the case of batching, the client never waits for a reply from theserver, and the server does not send replies to batch requests. A sequence of batch
calls is usually terminated by a legitimate RPC in order to flush the pipeline (withpositive acknowledgement).

Broadcast RPC
In broadcast RPC-based protocols, the client sends a broadcast packet to the network and waits for numerous replies. Broadcast RPC uses unreliable, packetbased protocols (like UDP/IP) as its transports. Servers that support broadcast
protocols only respond when the request is successfully processed, and are silent
in the face of errors. Broadcast RPC uses the rpcbind service to achieve its
semantics. See the rpcbind protocol, below, for more information.

7-26

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 176

The RPC Message Protocol
This section defines the RPC message protocol in the XDR data description
language. The message is defined in a top-down style.

enum msg_type {CALL = 0,
REPLY = 1};/*
* A reply to a call message can take on two forms:* The message was either accepted or rejected.
*/
enum reply_stat {MSG_ACCEPTED = 0,
MSG_DENIED
= 1
};
/*
* Given that a call message was accepted, the following is the* status of an attempt to call a remote procedure.
*/enum accept_stat {SUCCESS= 0, /* RPC executed successfully*/
PROG_UNAVAIL = 1, /* remote hasn’t exported program */PROG_MISMATCH = 2, /* remote can’t support version # */PROC_UNAVAIL = 3, /* program can’t support procedure */GARBAGE_ARGS = 4 /* procedure can’t decode params */};/** Reasons why a call message was rejected:*/
enum reject_stat {RPC_MISMATCH = 0, /* RPC version number != 2*/
AUTH_ERROR = 1/* remote can’t authenticate caller */};/** Why authentication failed:*/enum auth_stat {AUTH_BADCRED= 1,
AUTH_REJECTEDCRED = 2,
AUTH_BADVERF= 3,
AUTH_REJECTEDVERF = 4,
AUTH_TOOWEAK= 5};/* bad credentials *//* client must begin new session *//* bad verifier *//* verifier expired or replayed *//* rejected for security reasons */(continued on next page )Formats and Protocols for Networking

7-27

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 177/** The RPC message:* All messages start with a transaction identifier, xid,
* followed by a two-armed discriminated union. The union’s* discriminant is a msg_type which switches to one of the two* types of the message. The xid of a REPLY message always* matches that of the initiating CALL message. NB: The xid* field is only used for clients matching reply messages with* call messages or for servers detecting retransmissions; the* service side cannot treat this id as any type of sequence* number.
*/struct rpc_msg {unsigned int xid;
union switch (msg_type mtype) {case CALL:
call_body cbody;case REPLY:
reply_body rbody;} body;};/** Body of an RPC request call:* rpcvers may* be equal to 2 or 3. The fields prog, vers, and proc specify the* remote program, its version number, and the procedure within* the remote program to be called. After these fields are two* authentication parameters: cred (authentication credentials)* and verf (authentication verifier). The two authentication* parameters are followed by the parameters to the remote* procedure, which are specified by the specific program* protocol.
*/
struct call_body {unsigned int rpcvers; /* must be equal to two (2) */unsigned int prog;
unsigned int vers;
unsigned int proc;
opaque_auth cred;opaque_auth verf;/* procedure specific parameters start here */};E(continued on next page )7-28

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 178/** Body of a reply to an RPC request:* The call message was either accepted or rejected.
*/
union reply_body switch (reply_stat stat) {case MSG_ACCEPTED:
accepted_reply areply;
case MSG_DENIED:
rejected_reply rreply;} reply;/** Reply to an RPC request that was accepted by the server:* there could be an error even though the request was accepted.
* The first field is an authentication verifier that the server* generates in order to validate itself to the caller. It is* followed by a union whose discriminant is an enum
* accept_stat. The SUCCESS arm of the union is protocol* specific. The PROG_UNAVAIL, PROC_UNAVAIL, and GARBAGE_ARGP* arms of the union are void. The PROG_MISMATCH arm specifies* the lowest and highest version numbers of the remote program* supported by the server.
*/
struct accepted_reply {opaque_auth verf;
union switch (accept_stat stat) {case SUCCESS:
opaque results[0];/* procedure-specific results start here */case PROG_MISMATCH:
struct {unsigned int low;
unsigned int high;} mismatch_info;
default:/** Void. Cases include PROG_UNAVAIL, PROC_UNAVAIL,* and GARBAGE_ARGS.
*/void;} reply_data;};(continued on next page )Formats and Protocols for Networking

7-29

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 179

/*
* Reply to an RPC request that was rejected by the server:* The request can be rejected for two reasons: either the* server is not running a compatible version of the RPC* protocol (RPC_MISMATCH), or the server refuses to* authenticate the caller (AUTH_ERROR). In case of an RPC* version mismatch, the server returns the lowest and highest* supported RPC version numbers. In case of refused* authentication, failure status is returned.
*/
union rejected_reply switch (reject_stat stat) {case RPC_MISMATCH:
struct {unsigned int low;
unsigned int high;} mismatch_info;case AUTH_ERROR:
auth_stat stat;};

Authentication Protocols
As previously stated, authentication parameters are opaque, but open-ended to
the rest of the RPC protocol. This section defines some ‘‘flavors’’ of authentication
which are already implemented. Other sites are free to invent new authentication
types, with the same rules of flavor number assignment as there is for program
number assignment.
Null Authentication
Often calls must be made where the caller does not know who he is or the server
does not care who the caller is. In this case, the flavor value (the discriminant of
the opaque_auth’s union) of the RPC message’s credentials, verifier, and response
verifier is AUTH_NULL. The bytes of the opaque_auth’s body are undefined. It is
recommended that the opaque length be zero.
Basic Authentication for UNIX Systems
The callers of a remote procedure may wish to identify themselves as they are
identified on a UNIX system. The value of the credential’s discriminant of an RPC
call message is AUTH_SYS. The bytes of the credential’s opaque body encode thefollowing structure:

7-30

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 180











struct authsys_parms {u_long aup_time;char *aup_machname;uid_t aup_uid;
gid_t aup_gid;
u_int aup_len;
gid_t *aup_gids;};

The aup_machname is the name of the caller’s machine (like ‘‘krypton’’). The
aup_uid is the caller’s effective user ID. The aup_gid is the caller’s effective
group ID. The aup_gids is a counted array of groups which contain the caller as amember. The verifier accompanying the credentials should be of AUTH_NULL(defined above).
The value of the discriminant of the response verifier received in the reply message from the server may be AUTH_NULL.
DES Authentication
Basic authentication for UNIX systems suffers from two major problems:
1 . The naming is oriented for UNIX systems.
2 . There is no verifier, so credentials can easily be faked.
DES authentication attempts to fix these two problems.
Naming
The first problem is handled by addressing the caller by a simple string of characters instead of by an operating system specific integer. This string of characters is
known as the ‘‘netname’’ or network name of the caller. The server is not allowed
to interpret the contents of the caller’s name in any other way except to identify
the caller. Thus, netnames should be unique for every caller in the naming
domain.
It is up to each operating system’s implementation of DES authentication to generate netnames for its users that insure this uniqueness when they call upon
remote servers. Operating systems already know how to distinguish users local totheir systems. It is usually a simple matter to extend this mechanism to the network. For example, a user with a user ID of 515 might be assigned the following
netname: ‘‘unix.515@sun.com’’. This netname contains three items that serve toinsure it is unique. Going backwards, there is only one naming domain called‘‘sun.com’’ in the internet. Within this domain, there is only one user with user ID
515. However, there may be another user on another operating system within thesame naming domain that, by coincidence, happens to have the same user ID. To

Formats and Protocols for Networking

7-31

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 181

insure that these two users can be distinguished we add the operating systemname. So one user is ‘‘unix.515@sun.com’’ and the other could be‘‘vms.515@sun.com’’.
The first field is actually a naming method rather than an operating system name.
It just happens that today there is almost a one-to-one correspondence between
naming methods and operating systems. If the world could agree on a naming
standard, the first field could be the name of that standard, instead of an operating
system name.
DES Authentication Verifiers
Unlike authentication for UNIX systems, DES authentication does have a verifier
so the server can validate the client’s credential (and vice-versa). The contents ofthis verifier is primarily an encrypted timestamp. The server can decrypt thistimestamp, and if it is close to what the real time is, then the client must haveencrypted it correctly. The only way the client could encrypt it correctly is toknow the ‘‘conversation key’’ of the RPC session. And if the client knows theconversation key, then it must be the real client.
The conversation key is a DES key which the client generates and notifies theserver of in its first RPC call. The conversation key is encrypted using a public key
scheme in this first transaction. The particular public key scheme used in DES
authentication is Diffie-Hellman with 192-bit keys. The details of this encryption
method are described later.
The client and the server need the same notion of the current time in order for allof this to work. If network time synchronization cannot be guaranteed, then client
can synchronize with the server before beginning the conversation.
The way a server determines if a client timestamp is valid is somewhat complicated. For any other transaction but the first, the server just checks for two things:
1 . The timestamp is greater than the one previously seen from the same client.
2 . The timestamp has not expired.
A timestamp is expired if the server’s time is later than the sum of the client’s
timestamp plus what is known as the client’s "window". The ‘‘window’’ is anumber the client passes (encrypted) to the server in its first transaction. It can bethought of as a lifetime for the credential.
This explains everything but the first transaction. In the first transaction, theserver checks only that the timestamp has not expired. If this was all that wasdone though, then it would be quite easy for the client to send random data inplace of the timestamp with a fairly good chance of succeeding. As an added
check, the client sends an encrypted item in the first transaction known as the‘‘window verifier’’ which must be equal to the window minus 1, or the server will
reject the credential.

7-32

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 182

The client too must check the verifier returned from the server to be sure it is legitimate. The server sends back to the client the encrypted timestamp it received
from the client, minus one second. If the client gets anything different than this, itwill reject it.
Nicknames and Clock Synchronization
After the first transaction, the server’s DES authentication subsystem returns in its
verifier to the client an integer ‘‘nickname’’ which the client may use in its furthertransactions instead of passing its netname, encrypted DES key and window every
time. The nickname is most likely an index into a table on the server which storesfor each client its netname, decrypted DES key and window.
Though they originally were synchronized, the client’s and server’s clocks can getout of sync again. When this happens the client RPC subsystem most likely will
get back RPC_AUTHERROR at which point it should resynchronize.
A client may still get the RPC_AUTHERROR error even though it is synchronizedwith the server. The reason is that the server’s nickname table is a limited size,
and it may flush entries whenever it wants. A client should resend its original
credential in this case and the server will give it a new nickname. If a server
crashes, the entire nickname table gets flushed, and all clients will have to resend
their original credentials.

DES Authentication Protocol (in XDR language)/** There are two kinds of credentials: one in which the client uses
* its full network name, and one in which it uses its "nickname"* (just an unsigned integer) given to it by the server. The* client must use its fullname in its first transaction with the* server, in which the server will return to the client its* nickname. The client may use its nickname in all further* transactions with the server. There is no requirement to use the* nickname, but it is wise to use it for performance reasons.
*/enum authdes_namekind {ADN_FULLNAME = 0,
ADN_NICKNAME = 1};/** A 64-bit block of encrypted DES data*/
typedef opaque des_block[8];(continued on next page )Formats and Protocols for Networking

7-33

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 183/*
* Maximum length of a network user’s name*/const MAXNETNAMELEN = 255;/*
* A fullname contains the network name of the client, an encrypted* conversation key and the window. The window is actually a* lifetime for the credential. If the time indicated in the* verifier timestamp plus the window has past, then the server* should expire the request and not grant it. To insure that* requests are not replayed, the server should insist that
* timestamps are greater than the previous one seen, unless it is* the first transaction. In the first transaction, the server* checks instead that the window verifier is one less than the* window.
*/
struct authdes_fullname {string name<MAXNETNAMELEN>; /* name of client */des_block key;/* PK encrypted conversation key */unsigned int window;/* encrypted window */};/** A credential is either a fullname or a nickname*/
union authdes_cred switch (authdes_namekind adc_namekind) {case ADN_FULLNAME:
authdes_fullname adc_fullname;case ADN_NICKNAME:
unsigned int adc_nickname;};/** A timestamp encodes the time since midnight, January 1, 1970.
*/
struct timestamp {unsigned int seconds;/* seconds */unsigned int useconds;/* and microseconds */};/** Verifier: client variety* The window verifier is only used in the first transaction. In* conjunction with a fullname credential, these items are packed* into the following structure before being encrypted:** struct {* adv_timestamp;-- one DES block* adv_fullname.window;-- one half DES block(continued on next page )7-34

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 184

* adv_winverf;-- one half DES block*}* This structure is encrypted using CBC mode encryption with an* input vector of zero. All other encryptions of timestamps use* ECB mode encryption.
*/
struct authdes_verf_clnt {timestamp adv_timestamp;/* encrypted timestamp*/
unsigned int adv_winverf;/* encrypted window verifier */};/** Verifier: server variety* The server returns (encrypted) the same timestamp the client* gave it minus one second. It also tells the client its nickname* to be used in future transactions (unencrypted).
*/
struct authdes_verf_svr {timestamp adv_timeverf;/* encrypted verifier*/
unsigned int adv_nickname; /* new nickname for client */};Diffie-Hellman Encryption
In this scheme, there are two constants, BASE and MODULUS. The particular values
chosen for these for the DES authentication protocol are:const BASE = 3;
const MODULUS ="d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b";
The way this scheme works is best explained by an example. Suppose there are
two persons ‘‘A’’ and ‘‘B’’ who want to send encrypted messages to each other.
So, A and B both generate ‘‘secret’’ keys at random which they do not reveal toanyone. Let these keys be represented as SK(A) and SK(B). They also publish in a
public directory their ‘‘public’’ keys. These keys are computed as follows:
PK(A) = ( BASE ** SK(A) ) mod MODULUS
PK(B) = ( BASE ** SK(B) ) mod MODULUS
The ‘‘**’’ notation is used here to represent exponentiation. Now, both A and B
can arrive at the ‘‘common’’ key between them, represented here as CK(A, B),
without revealing their secret keys.
A computes:
CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS

Formats and Protocols for Networking

7-35

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 185

while B computes:
CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS
These two can be shown to be equivalent:(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS
We drop the ‘‘mod MODULUS’’ parts and assume modulo arithmetic to simplify
things:PK(B) ** SK(A) = PK(A) ** SK(B)
Then, replace PK(B) by what B computed earlier and likewise for PK(A).
((BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B)which leads to:
BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))
This common key CK(A, B) is not used to encrypt the timestamps used in the protocol. Rather, it is used only to encrypt a conversation key which is then used toencrypt the timestamps. The reason for doing this is to use the common key as little as possible, for fear that it could be broken. Breaking the conversation key is a
far less serious offense, since conversations are relatively short-lived.
The conversation key is encrypted using 56-bit DES keys, yet the common key is
192 bits. To reduce the number of bits, 56 bits are selected from the common key
as follows. The middle-most 8-bytes are selected from the common key, and thenparity is added to the lower order bit of each byte, producing a 56-bit key with 8
bits of parity.

Record Marking Standard
When RPC messages are passed on top of a byte stream protocol (like TCP/IP), it
is necessary, or at least desirable, to delimit one message from another in order todetect and possibly recover from user protocol errors. This is called record marking (RM). One RPC message fits into one RM record.
A record is composed of one or more record fragments. A record fragment is afour-byte header followed by 0 to (2**31) - 1 bytes of fragment data. The bytes
encode an unsigned binary number; as with XDR integers, the byte order is fromhighest to lowest. The number encodes two values—a boolean which indicates
whether the fragment is the last fragment of the record (bit value 1 implies thefragment is the last fragment) and a 31-bit unsigned binary value which is thelength in bytes of the fragment’s data. The boolean value is the highest-order bitof the header; the length is the 31 low-order bits. (Note that this record
specification is NOT in XDR standard form!)

7-36

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 186

rpcbind Mechanism
An rpcbind mechanism maps RPC program and version numbers to universal
addresses, thus making dynamic binding of remote programs possible. Thismechanism should run at a well-known address, and other programs register theirdynamically allocated network addresses with it. It then makes those addresses
publically available. Universal addresses are defined by the addressing authorityof the given transport. They are NULL-terminated strings.
rpcbind also aids in broadcast RPC. There is no fixed relationship between theaddresses which a given RPC program will have on different machines, so there’s
no way to directly broadcast to all of these programs. The rpcbind mechanism,however, has a well-known address. So, to broadcast to a given program, theclient actually sends its message to the rpcbind process on the machine it wishes
to reach. rpcbind picks up the broadcast and calls the local service specified by
the client. When rpcbind gets a reply from the local service, it passes it on to theclient.
rpcbind Protocol Specification (in RPC Language)/** rpcbind procedures*/
program RPCBPROG {version RPCBVERS {void
RPCBPROC_NULL(void) = 0;bool
RPCBPROC_SET(rpcb) = 1;bool
RPCBPROC_UNSET(rpcb) = 2;
stringRPCBPROC_GETADDR(rpcb) = 3;
rpcblist
RPCBPROC_DUMP(void) = 4;
rpcb_rmtcallres
RPCBPROC_CALLIT(rpcb_rmtcallargs) = 5;
unsigned int
RPCBPROC_GETTIME(void) = 6;
} = 3;} = 100000;

Formats and Protocols for Networking

7-37

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 187

rpcbind Operation
The rpcbind mechanism is contacted by way of an assigned address specific to
the transport which is used. In case of IP, for example, it is port number 111. Eachtransport has such an assigned well known address. The following is a description of each of the procedures supported by rpcbind:
RPCBPROC_NULL:
This procedure does no work. By convention, procedure zero of any protocol takes no parameters and returns no results.
RPCBPROC_SET:
When a program first becomes available on a machine, it registers itself
with the rpcbind program running on the same machine. The program
passes its program number, version number, network identifier and theuniversal address on which it awaits service requests. The procedure
returns a boolean response whose value is TRUE if the procedure successfully established the mapping and FALSE otherwise. The procedurerefuses to establish a mapping if one already exists for the tuple. Notethat neither network identifier nor universal address can be NULL, andthat network identifier should be valid on the machine making the call.
RPCBPROC_UNSET:
When a program becomes unavailable, it should unregister itself with therpcbind program on the same machine. The parameters and results havemeanings identical to those of RPCBPROC_SET. The mapping of the program number, version number and network identifier tuple with universal address is deleted. If network identifier is NULL, all mappings
specified by the tuple (program number, version number, *) and thecorresponding universal addresses are deleted.
RPCBPROC_GETADDR:
Given a program number, version number and network identifier, thisprocedure returns the universal address on which the program is awaiting
call requests.
RPCBPROC_DUMP:
This procedure enumerates all entries in rpcbind’s database. The procedure takes no parameters and returns a list of program, version, netid,
and universal addresses.
RPCBPROC_CALLIT:
This procedure allows a caller to call another remote procedure on thesame machine without knowing the remote procedure’s universal
address. It is intended for supporting broadcasts to arbitrary remote programs via rpcbind’s well-known address.

7-38

FORMATS AND PROTOCOLSDRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 188

The parameters and the argument pointer are the program number, version number, procedure number, and parameters of the remote procedure. Note:
1 . This procedure only sends a response if the procedure was successfully executed and is silent (no response) otherwise.
2 . rpcbind can communicates with remote programs only byusing connectionless transports.
The procedure returns the remote program’s universal address, and theresults of the remote procedure.
RPCBPROC_GETTIME:
This procedure returns the local time on its own machine.
rpcbind can also supports version 2 of the rpcbind (portmapper) program protocol; version 3 should be used.

Formats and Protocols for Networking

7-39

DRAFT COPY
March 18, 1997
File: chap7
386:adm.book:sum
Page: 189

E

8

SYSTEM COMMANDS

Commands for Application Programs

Table of Contents

8-1

i

DRAFT COPY
March 18, 1997
File: Cchap8
386:adm.book:sum
Page: 190

Commands for Application Programs
Programs running on ABI-conforming system are capable of creating newprocesses and executing programs provided by the system. They can also executea shell in a new process, and then use that shell to interpret a script that causes
many system programs to be executed.
The system commands listed below must be available to applications executing on
an ABI-conforming system. They include commands from the X/Open CAE
Specification, Issue 4.2 and the System V Interface Definition, Fourth Edition, Basic andAdvanced Utilities Extensions (see Conformance Rule in chapter 1).
The following commands are available to application programs running on ABIconforming systems. All the commands must be accessible through the default
PATH environment variable provided by the system (see, section 2.5.3 of the
Commands and Utilities volume of the X/Open CAE Specification, Issue 4.2 or theenvvar(BA_ENV) manual page in the System V Interface Definition, Fourth Edition,
for more information on execution environment variables).

X

X

Figure 8-1: Commands required in an ABI Run-time Environment

cat
cd
chgrp
chmod
chown
cmp
cp
cpio #
date
dd
df
echo
ed
ex
expr
make
gencatfalse
find
fmtmsg #gettxtgrep
idkillline #
ln
logname
lp
ls
mkdir
mv
passwd
ar
sum #

pg #
pr
priocntl
pwd
rm
rmdir
sed
sh
sleep
sort
stty
su
tail
tee
compressbasename
wc

test
touch
tr
true
tty
umask
uname
uucp
uulog
uustat
uux
vi
wait
who
uncompress
dirname# Command is DEPRECATEDX

Commands for Application Programs

8-1

DRAFT COPY
March 18, 1997
File: chap8
386:adm.book:sum
Page: 191

The following new commands, now required by the X/Open CAE Specification,
Issue 4.2, are available to application programs running on ABI-conforming systems. All the commands must be accessible through the default PATH environment variable provided by the system.

X
X
X
X

Figure 8-2: XPG4.2 Commands required in an ABI Run-time Environment

X

alias
asa
at
awk
batch
bc
bg
c89
cal
calendar #
cksum
col #
comm
commandcrontabcsplitcut
diff
dircmp #
du

egrep
env
expand
fc
fg
fgrep
file
fold
getconf
getopts
hash
head
iconv
jobs
join
localelocaledef
loggermailx
mail #

manmesg
mkfifomore
newgrp
nice
nl
nohup
od
pack #
paste
patch
pathchkpax
pcat #
printfps
readrenicespell #

X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

split
strings
tabs
talk
tar #
time
tput
tsort
type
ulimitunaliasunexpand
uniq
unpack #uudecode
uuencode
write
xargs
zcat

# Command is DEPRECATEDNOTE

XSH4.2 conforming commands are accessed by setting the PATH variableequal to the value of the _CS_PATH variable as defined by XSH4.2 If an
implementation offers full System V Application Binary Interface, Fourth Edition
compatibility, the default command set including the shell in the system will be
System V Application Binary Interface, Fourth Edition compatible. Applications
that have strict compatibility requirements for their command usage, should
consider only relying on the default command set.

X
X
X
X
X

The following commands are available to application programs running on ABI-conforming systems that implement a graphical windowing terminal interface and therefore provide the Motif interface.

8-2

SYSTEM COMMANDSDRAFT COPY
March 18, 1997
File: chap8
386:adm.book:sum
Page: 192

M

Figure 8-3: Commands required in an ABI Run-time Environment for Motif *

uil

M

mwm

M

*Function is new to the Fourth Edition of the ABI.

Commands for Application Programs

8-3

DRAFT COPY
March 18, 1997
File: chap8
386:adm.book:sum
Page: 193

9

EXECUTION ENVIRONMENT

Application Environment

9-1File System Structure and Contents

9-3
9-3
9-4
9-5
9-5
9-6

Root subtree
The /etc subtree
The /opt subtree
The /usr subtree
The /var subtree

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cchap9
386:adm.book:sum
Page: 194

Application Environment
This section specifies the execution environment information available to application programs running on ABI-conforming computers. It also specifies the programs’ interface to that information.
The execution environment contains certain information that is provided by theoperating system and is available to executing application programs. Generally
speaking, this includes system-wide environment information and per-process
information that is meaningful and accessible only to the single process to which it
applies. This environment information and the utilities used to retrieve it are
specified in detail in the X/Open CAE Specification, Issue 4.2 and the System V Interface Definition, Fourth Edition (see the Conformance Rule in chapter 1).

X

The environment information available to application programs on an ABIconforming system includes the following:
System identification
Application programs may obtain system identification information
through the uname function or the system command uname.
Date and time
The current calendar date and time are available to application programs
through the date system command and the time function.
Numerical Limits
This refers to the maximum and minimum values of operating system variables and C language limits that application programs require. Most important values are accessible through the sysconf and pathconf functions
defined in the X/Open CAE Specification, Issue 4.2 and the System V Interface
Definition, Fourth Edition and in the POSIX P1003.1 Portable Operating System
Specification (see the Conformance Rule in chapter 1) . These interfaces are
the correct method for application programs to retrieve numerical values
related to the configuration of their host system. Guaranteed minimum
values for these parameters are specified in the ‘‘Data Definition’’ section in
Chapter 6 of the ABI. Other system parameters are accessible through thegetrlimit function.

Application Environment

9-1

DRAFT COPY
March 18, 1997
File: chap9
386:adm.book:sum
Page: 195

X
X

Per-process environment information
When an application program first begins execution an environment ismade available to it. The X/Open CAE Specification, Issue 4.2 and the System
V Interface Definition, Fourth Edition (see the Conformance Rule in Chapter 1)
pages for envvar, exec, and system contain detailed descriptions of thisinformation.
The X/Open CAE Specification, Issue 4.2 and the System V Interface Definition, Fourth
Edition (see the Conformance Rule in Chapter 1) are the definitive reference for
information about the execution environment of processes; all of this information
applies to ABI-conforming systems. The specific references given above will leadan interested reader to all appropriate information, but are not exhaustive inthemselves.

9-2

EXECUTION ENVIRONMENTDRAFT COPY
March 18, 1997
File: chap9
386:adm.book:sum
Page: 196

X

X

File System Structure and Contents
The file system on an ABI-conforming system is a tree-like structure. All ABIconforming systems have a ‘‘root’’ (or /) directory that contains a /usr directory,
a /var directory, a /etc directory, and a /opt directory.
The following are primary characteristics of the file system tree:/

This directory contains machine-specific files and executable files
required to boot the system, to check, and to repair file systems.
It also contains other directories. No application may install files
in the / directory.

/etc

This directory subtree contains machine-specific configuration
files and some executable files, including one command usedduring application package installation. Application programs
should never execute applications in this directory subtree, andshould never access directly any data files in this subtree, except
for the files they install themselves in the /etc/opt directory.

/opt

This subtree contains add-on software application packages.

E

/tmp

This directory contains temporary files created by system utilities.

E

/usr

This subtree contains only sharable files and executable files provided by the system.

/varThis subtree contains files that change.

Applications should install or create files only in designated places within the tree,
as noted below.
This section describes those aspects of the root, user and var file systems thatapplication programs can rely on being present.

Root subtree
The / directory contains executable programs and other files necessary to boot thesystem, check and repair file systems, and files describing the identity of a particular machine. The following components must be present in the root file system:

File System Structure and Contents

9-3

DRAFT COPY
March 18, 1997
File: chap9
386:adm.book:sum
Page: 197

/

The root directory of the file system.

/dev

The top directory of the devices subtree containing block andcharacter device files. All terminal and terminal-related
device files must be in the /dev directory or in subdirectories
of /dev. The following files are required to be present in the/dev directory.

E

Figure 9-1: Required Devices in an ABI Run-time Environment____________________________________
____________________________________/dev/tty /dev/null /dev/lpX 

Where X may be any integer value. Note that further devices
specifically required for networking support are defined in
Chapter 12. The following sub-directories of /dev are
required to be present.
/dev/rmt/dev/mt
The names of other files present in /dev and naming conventions for sub-directories of /dev are processor-specific.
/etc

The top directory of the /etc subtree.

/opt

The top directory of the /opt subtree.

/usr

The top directory of the /usr subtree.

/var

The top directory of the /var subtree.

The /dev, /usr, and /tmp directories are for the use of the system. Applications
should never create files in any of these directories, though they contain subdirectories that may be used by applications, as described below.

The /etc subtree
The directory /etc of the / file system is the point of access to the /etc subtree.
This directory contains machine-specific configuration files.
The following describes the structure of the /etc subtree:

9-4

EXECUTION ENVIRONMENTDRAFT COPY
March 18, 1997
File: chap9
386:adm.book:sum
Page: 198

E

E
E

/etc

The top directory of the /etc subtree.

E/etc/opt/pkg

This directory contains machine-specific configuration files
provided by application packages.

E

The /opt subtree
The directory /opt of the / file system is the point of access to the /opt subtree.
This directory subtree contains files installed by add-on application packages.
The following describes the structure of the /opt subtree:/opt

The top directory of the /opt subtree.

E/opt/pkg/bin

Executable files provided by application packages andinvoked directly by users.

E/opt/pkg

Where pkg is the abbreviated name of an add-on software
package, contains all the static files installed on the system aspart of that package.

The /usr subtree
The directory /usr of the / file system is the point of access to the /usr subtree.
The following describes the structure of the /usr subtree:/usr

The top directory in the /usr subtree.

/usr/bin

Utility programs and commands for the use of all applications
and users.

/usr/share

The architecture-independent sharable files.

/usr/share/lib

Architecture-independent databases.

M/usr/lib/X11

The directory where X11 Window System libraries reside.

M/usr/lib/X11/locale
The directory where X11 Window System localization packages are installed.

M
M
M/usr/lib/X11/app-defaults
The directory where X11 Window System default application
resource files are installed.

M
M

File System Structure and Contents

9-5

DRAFT COPY
March 18, 1997
File: chap9
386:adm.book:sum
Page: 199

Application programs may execute commands in the /usr/bin directory.

The /var subtree
The directory /var of the / file system is the point of access to the /var subtree.
The /var subtree contains all files that vary in size or presence during normal system operations, including logging, accounting and temporary files created by thesystem and applications.
The following components of the /var subtree are important for application programs:/var/opt/pkg

The top level directory used by application packages.

/var/tmp

Directory for temporary files created by applications.

Applications should always use /var/tmp for creation of temporary files.

9-6

EXECUTION ENVIRONMENTDRAFT COPY
March 18, 1997
File: chap9
386:adm.book:sum
Page: 200

E

E

10

WINDOWING AND TERMINALINTERFACESThe System V Window System
X Window System Overview

System V Window System Components
Summary of Requirements

Table of Contents

10-1
10-2

10-3
10-5

i

DRAFT COPY
March 18, 1997
File: Cchap10
386:adm.book:sum
Page: 201

The System V Window System

NOTEThis chapter, ‘‘Windowing and Terminal Interfaces’’ , describes the optional
ABI extension for the System V Window System.

The System V window system is a graphical window system, and is used as aninterface for high-resolution bitmapped display devices. The window systemallows multiple cooperating applications to appear on a display screen simultaneously. A server process arbitrates a shared display, a keyboard, and a pointing
device, and performs I/O on behalf of one or more client applications. Client
applications may execute in the local processor’s memory space, or may run on aremote processor and communicate with the server through a network connection.
The System V window system supports concurrent, overlapping windows, andwindows can be created within other windows. The system supports text, twodimensional graphics, and imaging.
The System V window system is completely network-transparent, in that a client
program can be running on any machine in a network and the client and server
programs need not be executing on machines sharing a common architecture.
When the client and server reside on different machines, messages are transmitted
over the network. When the client and server reside on the same machine, messages are transmitted using a local inter-process communication (IPC) mechanism.
Applications for the System V window system may be written to either the X11
Window System interface, the X11 Toolkit Intrinsics, the X11 Nonrectangular Window Shape Extension, or Motif.
The X11 interface contains mandatory parts of the System V Window System. All
implementations that include a window system extension must support
the X11 interface, the X Toolkit Intrinsics interface, the X11 Nonrectangular Window Shape Extension, and Motif. The X11 interface has base and optional components.

The System V Window System

10-1

DRAFT COPY
March 18, 1997
File: chap10
386:adm.book:sum
Page: 202

E
E

M
M

M
M

X Window System Overview
A client application communicates with the X capabilities of the System V window
system server using the X11 protocol. The X11 protocol specifies exchange format,
rules for data exchange, and message semantics, but is policy-free and does not
impose any specific appearance on the interface. The look and feel of a particularinterface is defined by the window manager and different toolkits that define ahigher-level program interface to the X capabilities.
The X Version 11 protocol defines the format, syntax, common types, errors codes,
keyboard keycodes, pointers, predefined atoms, connection setup, requests, connection close, and events. A detailed description of these can be found in the X
Window System Protocol, Version 11 Specification (Massachusetts Institute of Technology, 1991).

10-2

WINDOWING AND TERMINAL INTERFACES

DRAFT COPY
March 18, 1997
File: chap10
386:adm.book:sum
Page: 203

System V Window System Components
The System V Window System includes the following components. Some components of the window system are base components of the ABI and must bepresent, and others are optional components. Because of this mixture, eachcomponent’s status has been explicitly marked in the list below, together with thecomponent’s description.
libX
NOTE

The libX library is a base ABI component and must bepresent on an ABI-conforming system which has a window system extension.

The X library, libX, generates the X11 protocol and buffers
traffic between each client application and the server. A full
specification of the X library and its contents can be found in
Xlib - C Language Interface, X Window System, X Version 11,
Release 5, (Massachusetts Institute of Technology, 1991). The
ABI will track upward-compatible future releases of the X
library.

G

X Toolkit Intrinsics
NOTE

The libXt library is a base ABI component and must
be present on an ABI-conforming system which has awindow system extension.

G

The X Toolkit Intrinsics library libXt provides a framework
for building X-based toolkits. A full specification of the X
Toolkit Intrinsics can be found in X Toolkit Intrinsics - C
Language X Interface, X Window System, X Version 11, Release 5,(Massachusetts Institute of Technology, 1991).
X11 Nonrectangular Window Shape Extension

System V Window System Components

10-3

DRAFT COPY
March 18, 1997
File: chap10
386:adm.book:sum
Page: 204

G


NOTE

The libXext library is a base ABI component andmust be present on an ABI-conforming system which
has a window system extension.

M

The X11 Nonrectangular Window Shape Extension library
Version 1.0, libXext, provides support for irregularly shaped
windows under X11. A full specification of the X11 Nonrectangular Window Shape Extension can be found in X11 Nonrectangular Window Shape Extension Version 1.0, X Version 11,
Release 5, (Massachusetts Institute of Technology, 1991).
Motif

M
M
M
M
M
M
M

NOTE

The libXm and libMrm libraries are base ABI components and must be present on an ABI-conforming
system which has a window system extension.

The Motif libraries, libXm and libMrm provide support forwindowing applications. A full specification of the Motiflibraries can be found in the Motif Programmer’s Reference Revision 1.2, (Open Software Foundation,1992).

M
M
M

The following programs are not required to be present on an ABI-conforming system. However, the protocols that these programs use to communicate are considered part of the ABI and must be present in an environment which supports
window systems. Hence all ABI-conforming systems which offer these services
must provide them as follows.
server

The server controls the user’s display. As such, a server is usuallyavailable for each type of display that can be connected to a system. It
manages device dependencies, enabling client applications to be
device-independent, although some client applications may need to beaware of the resolution, aspect ratio, or depth of the display device
being used. Servers include protocol interpretation facilities for X andPostScript extensions. All ABI-conforming window servers which support X must support the entire X protocol referenced above. (Theserver side of X protocol communicates with libX).

window manager
The window manager program allows a user to manipulate (for example, move and resize) windows. All client applications that use the windowing system use the facilities of the window manager. Well-behaved
clients must follow the ICCCM. All ABI-conforming window managers
which support X must support the entire X window manager protocol.

10-4

WINDOWING AND TERMINAL INTERFACES

DRAFT COPY
March 18, 1997
File: chap10
386:adm.book:sum
Page: 205

M

E
M

Summary of Requirements
The ‘‘Windowing and Terminal Interfaces’’ section of the System V ABI has a layered set of requirements for conforming systems. Those requirements are summarized here.
The presence of a windowing system is optional on an ABI-conforming system.
If a windowing system is present on a conforming system, libX, libXt,
libext, libXm, and libMrm must be provided.

System V Window System Components

G
M

10-5

DRAFT COPY
March 18, 1997
File: chap10
386:adm.book:sum
Page: 206

11

DEVELOPMENT ENVIRONMENTS
FOR AN ABI SYSTEM

Development Environments
Commands
Software Packaging Tools
Static Archives

Table of Contents

11-1
11-1
11-3
11-4

i

DRAFT COPY
March 18, 1997
File: Cchap11
386:adm.book:sum
Page: 207

Development Environments

NOTE

THE FACILITIES AND INTERFACES DESCRIBED IN THIS SECTION ARE
OPTIONAL COMPONENTS OF THE System V Application Binary Interface.

Any system may be used to provide a development environment for ABI conforming applications. This chapter describes the commands, options, libraries,
and path mechanisms necessary to produce an ABI conforming application. Thisdevelopment environment need not be hosted on an ABI conforming implementation.

Commands
The following commands, defined in the X/Open CAE Specification, Issue 4.2 andthe SD_CMD section of the System V Interface Definition, Fourth Edition (see the
Conformance Rule of Chapter 1) are a part of an ABI development environment.
All commands defined here are mandatory in ABI Development Environments,
except that the command as need not be present when ABI conformant code is
generated directly by the compiler.
ABI
Development Commands___________________________
as #
cc #
ld
m4
lex
yacc
c89 †

X
X

X

# Command is DEPRECATEDX†As defined in the Commands and Utilities volume of the X/Open CAE Specification, Issue
4.2.

X

Each command shall accept the following required options and provide the functionality required for each option listed, in the X/Open CAE Specification, Issue 4.2
and the System V Interface Definition, Fourth Edition (see the Conformance Rule inchapter 1).

Development Environments

11-1

DRAFT COPY
March 18, 1997
File: chap11
386:adm.book:sum
Page: 208

X
X

as
SVID
Fourth Edition Options to AS________________________________om
The as command if present shall produce output compliant to chapters 4 and 5 ofthis document, and chapters 4 and 5 of the appropriate Processor-specific Supplement.
cc
SVID
Fourth Edition Options to CC________________________________
B
c
d
D
G
I
K
l
L
o
O
U
Y
The cc command shall generate output compliant to Chapter 4 and 5 of this document and Chapter 4 and 5 of the appropriate Processor-specific Supplement.
ld
SVID
Fourth Edition Options to ld_______________________________
a
B
d
e
G
h
l
o
r
s
u
L
Y
z
The command ld shall generate output compliant to Chapters 4 and 5 of thisdocument and Chapters 4 and 5 of the appropriate Processor-specific Supplement.
lex
SVID
Fourth Edition Options to lex________________________________
c
t
v
n
m4
Fourth Edition Options to m4_SVID______________________________
s
D
U

11-2

DEVELOPMENT ENVIRONMENTS FOR AN ABI SYSTEMDRAFT COPY
March 18, 1997
File: chap11
386:adm.book:sum
Page: 209

M

yacc
SVID
Fourth Edition Options to yacc__________________________________vdlt
As there may be multiple development environments hosted on a system, different values for PATH may be required to access each development environment,
but all required commands shall be accessible by at least one value of PATH. The
processor supplement for each architecture shall state how the value of PATH is to
be used to find the location of a development environment for that architecture
when it is not the native development environment. If the system is itself ABI conforming and hosts a development environment for its run-time system, thedevelopment environment for the run-time system shall be accessible using thesystem default value for PATH.
To enable the System V Application Binary Interface, Edition 4.1 environment andfunctionality, applications must use the cc compiler driver. This driver will havean implementation-specific sequence of -D directives, include files or libraries toenable access to System V Application Binary Interface, Edition 4.1 features. As aresult the executable created will have the _ _xpg4 flag set to a value appropriate
to the base API the application wishes to conform to.
NOTE

All .o’s should be compiled such that they either don’t assume any specificshell (or other syntactic feature), or they presume the same shell (or othersyntactic feature) across all .o’s. Information is contained in linked executables, not in individual .o’s.

X
X
X
X
X
X
X

Software Packaging Tools
A development environment for ABI applications shall include each of the following commands as defined in the AS_CMD section of SVID Fourth Edition.
pkgproto

pkgtranspkgmk

The pkgtrans command shall generate output compliant with Chapter 2 of thisdocument.

Development Environments

11-3

DRAFT COPY
March 18, 1997
File: chap11
386:adm.book:sum
Page: 210

Static Archives
Frequently applications must rely on groups of object files not required to bepresent on an ABI conforming implementation. These may be provided in static
archives provided with the development environment. If each member of thearchive is itself ABI conforming, then an ABI conforming application may statically link members from this archive and still be ABI conforming. If extensions toan archive are not ABI conforming, then an ABI conforming application may notinclude that extension in an executable.
All development environments for ABI applications shall contain ABI conforming
versions of each of the following libraries.
libm
libcurses

M

The relevant processor supplement for each architecture shall define the path tothe directory that contains these libraries. The following are entry-points thatmust be defined for each respective library as defined in SVID Fourth Edition.
Figure 11-1: Required libm Functions

acos
acosh
asin
asinh
atan
atan2

atanh
cbrt
ceil
cos
cosh
erf

erfc
exp
fabs
floor
fmod #
gamma #

hypot
j0
j1
jn
lgamma
log

log10
pow
remainder
sin
sinh
sqrt

# Function is DEPRECATED

11-4

X

DEVELOPMENT ENVIRONMENTS FOR AN ABI SYSTEMDRAFT COPY
March 18, 1997
File: chap11
386:adm.book:sum
Page: 211

M

Figure 11-2: Required libcurses Functions

addch
addchnstr
addchstr
addnstraddnwstr
addstr
addwchaddwchnstr
addwchstraddwstr
attroff
attronattrsetbaudrate
beep
bkgd
bkgdsetborderbox
can_change_color
cbreakclear
clearokclrtobotclrtoeolcolor_content
copywincurs_set
def_prog_mode
def_shell_mode
del_curterm
delay_output
delch
deletelndelscreendelwinderwindoupdate

dupwinecho
echocharechowcharendwinerase
erasecharfilterflash
flushinp
getbegyx
getchgetmaxyx
getnwstr
getparyx
getstrgetsyxgetwchgetwingetwstrgetyx
halfdelay
has_colors
has_ichas_il
hline
idcok
idlok
immedokinch
inchnstrinchstr
init_color
init_pairinitscr
innstrinnwstrinsch

insdelln
insertln
insnstrinsnwstr
insstr
instr
inswchinswstr
intrflush
inwch
inwchnstr
inwchstr
inwstris_linetouchedis_wintouchedisendwin
keynamekeypadkillcharleaveok
longname
meta
move
mvaddchmvaddchnstr
mvaddchstr
mvaddnstr
mvaddnwstr
mvaddstr
mvaddwch
mvaddwchnstr
mvaddwchstr
mvaddwstr
mvcur
mvdelchmvderwin
mvgetchmvgetnwstr

Development Environments

mvgetstr
mvgetwch
mvgetwstr
mvinchmvinchnstr
mvinchstr
mvinnstr
mvinnwstr
mvinschmvinsnstr
mvinsnwstr
mvinsstrmvinstrmvinswchmvinswstr
mvinwchmvinwchnstr
mvinwchstr
mvinwstr
mvprintw
mvscanw
mvwaddch
mvwaddchnstr
mvwaddchstr
mvwaddnstr
mvwaddnwstr
mvwaddstr
mvwaddwch
mvwaddwchnstr
mvwaddwchstr
mvwaddwstr
mvwdelch
mvwgetch
mvwgetnwstr
mvwgetstr
mvwgetwch
mvwgetwstr
mvwin

11-5

DRAFT COPY
March 18, 1997
File: chap11
386:adm.book:sum
Page: 212

M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M

M

Figure 11-2: Required libcurses Functions (continued )mvwinchmvwinchnstr
mvwinchstr
mvwinnstr
mvwinnwstr
mvwinschmvwinsnstr
mvwinsnwstr
mvwinsstr
mvwinstr
mvwinswch
mvwinswstr
mvwinwch
mvwinwchnstr
mvwinwchstr
mvwinwstr
mvwprintw
mvwscanw
napms
newpadnewtermnewwinnl
nocbreaknodelay
noechononl
noqiflush
noraw
notimeout
overlay
overwrite
pair_content
pechochar
pechowchar
pnoutrefresh
prefreshprintw

11-6

putp
putwinqiflushraw
redrawwin
refreshreset_prog_mode
reset_shell_mode
resettyrestartterm
ripoffline
savettyscanw
scr_dump
scr_init
scr_restore
scr_setscrl
scrollscrollok
set_curterm
set_term
setscrreg
setsyxsetterm
setupterm
slk_attroff
slk_attron
slk_attrset
slk_clear
slk_init
slk_label
slk_noutrefresh
slk_refresh
slk_restore
slk_setslk_touchstandend

standout
start_color
subpadsubwinsyncoktermattrs
termname
tgetent
tgetflagtgetnumtgetstrtgoto
tigetflag
tigetnum
tigetstr
timeout
touchline
touchwin
tparm
tputs
tputs
typeaheadunctrlungetchungetwch
untouchwin
use_env
vidattrvidputs
vline
vwprintw
vwscanw
waddchwaddchnstr
waddchstr
waddnstr
waddnwstr
waddstrwaddwchwaddwchnstr
waddwchstr
waddwstr
wattroff
wattronwattrset
wbkgd
wbkgdset
wborder
wclear
wclrtobot
wclrtoeol
wcursyncup
wdelchwdeleteln
wechochar
wechowchar
werasewgetchwgetnstr
wgetnwstr
wgetstrwgetwchwgetwstr
whlinewinch
winchnstr
winchstr
winnstrwinnwstr
winschwinsdelln
winsertln
winsnstr
winsnwstr
winsstrwinstrDEVELOPMENT ENVIRONMENTS FOR AN ABI SYSTEMDRAFT COPY
March 18, 1997
File: chap11
386:adm.book:sum
Page: 213

M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M

M

Figure 11-2: Required libcurses Functions (continued )winswchwinswstr
winwchwinwchnstr
winwchstr
winwstrwmove
wnoutrefresh
wprintwwredrawln
wrefreshwscanw
wscrl
wsetscrreg
wstandend
wstandout

Development Environments

wsyncdown
wsyncup
wtimeout
wtouchln
wvline

11-7

DRAFT COPY
March 18, 1997
File: chap11
386:adm.book:sum
Page: 214

M
M
M
M
M
M

12

NETWORKING

Networking

12-1

Required STREAMS Devices and Modules

12-2

Required Interprocess Communication
SupportPseudo Terminal Support
STREAM Based Pipe Support

12-3
12-3
12-3

Required Transport Layer Support

12-4

Required Transport Loopback Support

12-7

Optional Internet Transport Support

12-8
12-8
12-8
12-8
12-8
12-8
12-9
12-9
12-9
12-10

Address Format
Programming Interfacest_acceptt_bindt_connectt_getinfo
t_listent_opent_optmgmt

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cchap12
386:adm.book:sum
Page: 215

t_rcvt_rcvconnectt_rcvudata
t_rcvuderr
t_snd
t_snddist_sndrelt_sndudata

12-12
12-12
12-12
12-12
12-12
12-13
12-13
12-13
12-13

Data Structuresii

Table of Contents

DRAFT COPY
March 18, 1997
File: Cchap12
386:adm.book:sum
Page: 216

Networking
This chapter is new to the System V Application Binary Interface, Third Edition.
NOTE

ABI-conforming systems may support some level of networking, ranging frompeer-to-peer to loopback networks. This section describes the network transportlevel services needed to support the Internet and ISO transport protocols. In addition, it defines required support for basic process to process communication over a
network.

Networking

12-1

DRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 217

Required STREAMS Devices and Modules
The following device drivers must exist on an ABI-conforming system. Theirrequired functionality shall be that specified in the System V Interface Definition,
Fourth Edition and the DDN Protocol Handbook, DARPA Internet Protocols.
Figure 12-1: Required STREAMS Devices______________________________________________________________________________
 /dev/ticlts /dev/ticots/dev/ticotsord transport loopback support  /dev/tcp
/dev/udp
internet support/dev/ptmx/dev/pts/digits
pseudo terminal support
______________________________________________________________________________
Where digits are decimal numbers.
The following required STREAMS modules shall be present on conforming systems and their functionality shall be that defined in section BA_DEV of the System
V Interface Definition, Fourth Edition.
Figure 12-2: Required STREAMS Modules____________________________________________________
 ldterm ptem
pckt pseudo terminal support  tirdwr timodtransport level support connld pipemod
IPC support
____________________________________________________


Binary interface support for these modules and drivers are defined in the following sections.

12-2

NETWORKINGDRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 218

Required Interprocess Communication Support
Pseudo Terminal Support
There shall be an appropriate entry in the /dev/pts directory for each slave-side
pseudo-terminal available on the implementation. Conforming systems shall provide a minimum of 16 pseudo-terminals. The default initial state of a pseudoterminal, as reported by tcgetattr, shall be the same as the default initial state ofa terminal as specified in termio(BA_DEV).
NOTE

The default baud rate as specified by termio(BA_DEV) is 300 baud. As thismay be inappropriate for pseudo terminals, there are exceptions.

STREAM Based Pipe Support
Functionality for interprocess communication by way of STREAMS-based pipes
shall be supported by ABI-conforming systems. STREAMS modules connld andpipemod must be present in support of this.

Required Interprocess Communication Support

DRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 219

12-3

Required Transport Layer Support
A transport layer application may access transport services through the ISO or
Internet frameworks. This document supports transport access via the XTI interface as it makes use of the timod module. The required functionality for thesemodules is defined in the BA_DEV section of the System V Interface Definition,
Fourth Edition. The definition of XTI is described in the Networking Services
volume of the X/Open CAE Specification, Issue 4.

X
X

In order to improve standards conformance and take advantage of the latest technology in XTI interfaces, the TLI interfaces have been DEPRECATED. Applications which make use of TLI should migrate to XTI as a replacement. TLI is a subset of XTI except where noted.
To achieve binary interoperability, an ABI-conforming system must consistently
define variables and data structures. The next few displays contain mnemonics
required on ABI-conforming systems. Their associated values are specified in theprocessor specific ABI.
Figure 12-3: TLI-XTI Error Codes______________________________________________________________ TACCESTBADQLEN * TNODATATPROTO * TADDRBUSY * TBADSEQTNODISTPROVMISMATCH * 
TBUFOVFLW TNORELTQFULL * TBADADDRTFLOWTNOSTRUCTYPE * TRESADDR * TBADDATA TBADFTINDOUT *TNOTSUPPORTTRESQLEN * TBADFLAGTLOOKTNOUDERRTSTATECHNG
 TBADNAME *TNOADDRTOUTSTATETSYSERRTBADOPT
______________________________________________________________
*Function is new to System V ABI Edition 4.1.

X

Figure 12-4: t_look Events_____________________________________________________
 T_LISTEN
T_EXDATA
T_UDERR T_CONNECT  T_DISCONNECT T_ORDREL
T_DATA
T_ERROR T_EVENTS
T_GODATA
T_GOEXDATA
_____________________________________________________


12-4

NETWORKINGDRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 220

M

Figure 12-5: XTI Flag Definitions____________________________________________________________________
 T_MORE T_NEGOTIATE

T_DEFAULT
T_EXPEDITED T_CHECK T_SUCCESS
T_FAILURE

T_CURRENT T_NOTSUPPORT T_PARTSUCCESS T_READONLY
____________________________________________________________________


X

Figure 12-6: XTI Service Types____________________________________
 T_COTS T_COTS_ORD T_CLTS____________________________________

The following are required structure types and bit fields used when dynamicallyallocating XTI structures via the function t_alloc call:Figure 12-7: Flags to be used with t_alloc_____________________________________
 T_BIND

T_OPTMGMT
T_CALL T_DIS
T_UNITDATA T_UDERROR 
T_ADDR
T_OPT
 T_INFO
T_UDATA T_ALL
_____________________________________


Figure 12-8: XTI Application States_________________________________________________
 T_UNINIT T_UNBND
T_IDLE
T_OUTCON  T_INCON
T_DATAXFER T_OUTREL T_INREL 
T_FAKE
T_NOSTATES
_________________________________________________


Required Transport Layer Support

12-5

DRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 221X

Figure 12-9: XTI values for t_info flags member_____________
 T_SENDZERO _____________

12-6

NETWORKINGDRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 222

Required Transport Loopback Support
An ABI-conforming system shall support a transport level loopback facility. The
device driver support is as defined by ticlts(BA_DEV), ticots(BA_DEV) andticotsord(BA_DEV) of the System V Application Binary Interface, Fourth Edition.

Required Transport Loopback Support

12-7

DRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 223X

Optional Internet Transport Support
A tcp implementation conforming to RFC 793 (as revised by by RFC 1122) shallsupport a device driver implementing the T_COTS_ORD service type. A udp implementation conforming to RFC 768 shall support a device driver implementing the
T_CLTS service type. These services shall be available to the TLI / XTI functions
and the provided functionality shall be consistent with TCP (RFC 793) and UDP(RFC 768).

Address Format
The XTI netbuf structure is used to pass TCP/IP addresses. The addr.buf component should point to a struct sockaddr_in. When used by XTI requests, thesin_zero field of this structure shall be zero and the sin_family field shall contain AF_INET.

Programming Interfaces
A conforming TCP/IP implementation shall implement the following transport
provider-specific functionality in addition to that required by RFC 793 and 791 (asrevised by RFC 1122 and RFC 1349).

t_accept
Under TLI no options shall be supported. The returned udata length shall be
zero.

t_bindThe INADDR_ANY address may be used. If INADDR_ANY is supplied as the address,
then the loopback or a local address will be used.

t_connect
No data shall be sent with the connection. The sin_addr field of the structsockaddr_in pointed to by sndcall->addr.buf may contain a valid TCP/IP
address. If rcvcall is not NULL, then the buffer identified by rcvcall>addr.buf shall be filled in with a sockaddr_in structure.

12-8

NETWORKINGDRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 224X

t_getinfo
The following default values shall be returned from the devices associated with
the TCP/IP transport provider.
Values Returned by /dev/tcp_______________________________
 addr varies options  varies tsdu 0 (byte stream) etsdu –1 connect  –2 (not supported)  discon –2 (not supported)  servtype  T_COTS_ORD




flags
_______________________________
 T_SENDZEROXXValues Returned by /dev/udp_______________________________
 addr varies options  varies tsdu varies etsdu –2 (not supported)  connect  –2 (not supported)  discon –2 (not supported)  servtype  T_CLTS




flags
_______________________________
 T_SENDZERO


X
X
X

t_listen
The result udata variable shall have zero length. Under TLI the result opt variable shall have zero length. The buffer identified by call->addr.buf shallreceive a struct sockaddr_in that identifies the host originating the connection.

t_openThe returned transport characteristics shall be the same as those returned byt_getinfo.

Optional Internet Transport Support

12-9

DRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 225X

t_optmgmt
TLI
Under TLI the following options may be accessible through t_optmgmt:
Figure 12-10: TCP Options__________________
 TCP_NODELAY__________________

Figure 12-11: IP Options___________________________________________
 IPOPT_EOLEnd of options list
 IPOPT_NOP
No operation
 IPOPT_LSRR Loose source and record route 
IPOPT_SSRR Strict source and record route 
___________________________________________

Options are specified in an options buffer with the opthdr data structure format.
An options buffer contains one or more options, with each followed by 0 or morevalues. The len field of opthdr specifies the length of the option value in bytes.
This length must be a multiple of sizeof(long)
Options may be manipulated at the TCP level and the IP level via the TLI
t_optmgmt call. To manipulate options at the TCP level, IPPROTO_TCP is specified
to t_optmgmt. For the IP level, IPPROTO_IP should be specified for t_optmgmt.
The header <netinet/tcp.h> contains the definitions for TCP level options,while the IP level options are defined in <netinet/ip.h>.
All TCP level options are 4 bytes long. A boolean option is either set or reset.
Any non-zero value will assert (set) the option while only zero will clear the
option.
The IP options consist of a string of IPOPT_* values. These options will be set inevery outgoing datagram. Options whose function is not explicitly specified
above are copied directly into the output. See IP and RFC 1122 for details.
TCP Level Options If the TCP_NODELAY option is set, a conforming system shall notdelay sending data in order to coalesce small packets. When the option is reset, asystem may defer sending data in an effort to coalesce small packets to conserve
network bandwidth.

12-10

NETWORKINGDRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 226

X

IP Level Options

IPOPT_LSRR

The IPOPT_LSRR option enables the loose source and record route
option as specified in RFC 1122.

IPOPT_SSRR

The IPOPT_SSRR option enables the strict source and record route
option as specified in RFC 1122.

IPOPT_NOPThe IPOPT_NOP does nothing. Since the length of the IP options
must be a multiple of 4, this option is useful as a pad.

IPOPT_EOL

This option identifies the end of an IP option sequence.

XTI
The following information is relevant under XTI. The following options may beaccessible through t_optmgmt:

X
X

Figure 12-12: TCP Options

X
X
X
X
X
X

Figure 12-13: UDP Options

X________________________________________
 TCP LevelINET_TCP TCP Level Options TCP_NODELAY 
TCP_MAXSEG
TCP_KEEPALIVE 
_________________________________________________________________________________
 UDP LevelINET_UDP UDP Level Options UDP_CHECKSUM 
_________________________________________

Optional Internet Transport Support

X
X

12-11

DRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 227

X

Figure 12-14: IP Options________________________________________
 IP LevelINET_IP UDP Level Options IP_OPTIONS
IP_TTL
IP_TOS
IP_REUSEADDR IP_DONTROUTE 
IP_BROADCAST 
________________________________________

X
X
X
X
X
X
X

t_rcv
TCP/IP urgent data shall be returned as expedited data with the semantics
described in t_rcv for expedited data.

t_rcvconnect
The result udata variable shall have zero length. Under TLI, the result opt variable shall have zero length.

Xt_rcvudata
If opt is non NULL and there were IP or UDP options sent with the datagram, theIP or UDP options should be returned in opt. Under TLI if opt is NULL and IP
options were sent, they should be silently discarded. Under TLI, UDP will not
send options.

X
X
X

t_rcvuderr
Under TLI the returned length of the opt variable shall be zero.

X

t_snd
If T_EXPEDITED is set in the flags argument, TCP will send the data as urgent data.
The TCP urgent data pointer will point to the first byte of data in the next data
sent by t_snd.

12-12

NETWORKINGDRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 228t_snddis
Data shall not be sent with the disconnect request.

t_sndrel
The T_COTS_ORD service of the transport provider (TCP) shall support this function.

t_sndudata
Under TLI, for /dev/udp, the opt field may contain IPPROTO_IP options. The
UDP protocol shall support sending zero length data.

X

Data Structures
To support interoperability between networked machines, an ABI-conforming
system supporting the Internet family protocols must support the following data
structures.
There must exist a sockaddr_in data structure containing at least the following
elements. Under TLI there must exist a opthdr data structure containing at least
the following elements.
Figure 12-15: Data Structures

struct sockaddr_in {short
sin_family;
u_short sin_port;
struct in_addr sin_addr;
char
sin_zero[8];};struct opthdr {
long
long
long
};

level;
name;len;

Optional Internet Transport Support

12-13

DRAFT COPY
March 18, 1997
File: chap12
386:adm.book:sum
Page: 229

X

IN

Index

Index

IN-1

Table of Contentsi

DRAFT COPY
March 18, 1997
File: Cindex
386:adm.book:sum
Page: 230

Index
2’s complement

4: 8

A
a64l 6: 9
ABI
generic 1: 1, 4, 8
processor specific 1: 1, 4, 8
ABI conformance 1: 4–5, 8, 3: 2, 4: 15,
5: 4, 6, 10, 15, 18, 6: 2, 5, 11, 14, 7: 1,
22, 8: 1, 10: 5, 11: 1, 4
ABI Conformance 12: 4
abort 6: 6
abs 6: 6
absolute symbols 4: 11
accept 6: 21
accepted_reply 7: 29
accept_stat 7: 27
access 6: 8
access control mechanisms 7: 23
accounting files 9: 6
acct 6: 8
addch 6: 25, 11: 7
addchnstr 6: 25, 11: 7
addchstr 6: 25, 11: 7
addnstr 6: 25, 11: 7
addnwstr 6: 25, 11: 7
addstr 6: 25, 11: 7
add_wch 6: 25
addwch 11: 7
add_wchnstr 6: 25
addwchnstr 11: 7
add_wchstr 6: 25
addwchstr 11: 7
addwstr 6: 25, 11: 7
ADN_FULLNAME 7: 33–34
ADN_NICKNAME 7: 33–34

AF_INET 12: 8
aio_cancel 6: 16
aio_error 6: 16
aio_read 6: 16
aio_return 6: 16
aio_suspend 6: 16
aio_write 6: 16
alarm 6: 8
alignment, section 4: 13_altzone 6: 12
altzone 6: 12
ANSI C 3: 1, 6: 1, 10, 13, 46
application environment 9: 1
applicationShellClassRec 6: 37
applicationShellWidgetClass
6: 37

archive file 4: 24, 5: 19, 7: 2, 11: 4
archive header 7: 2
string table 7: 2
archive formats, other 7: 6
archive header, see archive file 7: 2
archive symbol table 7: 2, 4–5
archive word encoding 7: 4
ARFMAG 7: 3
ar.h 7: 2
ar.hdr 7: 2
as 11: 1
ASCII 2: 5, 3: 2, 7: 2
asctime 6: 6
asctime_r 6: 8
assembler 4: 1, 11: 1
symbol names 4: 22_ _assert 6: 9
asynchronous input/output 6: 15
asynchronous I/O 6: 15
atexit 6: 6
atexit(BA_OS) 5: 26

Index

IN-1

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 231

atof 6: 6
atoi 6: 6
atol 6: 6
attr_get 6: 25
attr_off 6: 25
attroff 6: 25, 11: 7
attr_on 6: 25
attron 6: 25, 11: 7
attr_set 6: 25
attrset 6: 25, 11: 7
AUTH_BADCRED 7: 27
AUTH_BADVERF 7: 27
authdes_cred 7: 34
authdes_fullname 7: 34
authdes_getucred 6: 20
authdes_namekind 7: 33
authdes_seccreate 6: 20
authdes_verf 7: 35
authdes_verf_svr 7: 35
authentication protocol 7: 23, 25
AUTH_ERROR 7: 27, 30
auth_flavor 7: 25
authnone_create 6: 20
AUTH_NULL 7: 30–31
AUTH_REJECTEDCRED 7: 27
AUTH_REJECTEDVERF 7: 27
auth_stat 7: 27
AUTH_SYS 7: 30
authsys_create 6: 20
authsys_create_default 6: 20
auth_sysparms 7: 31
AUTH_TOOWEAK 7: 27

Bbarrier_destroy 6: 15
barrier_init 6: 15
barrier_wait 6: 15
BASE 7: 35
base address 5: 15
definition 5: 5

BASEDIR 2: 9
basename 6: 9
basic system service 6: 5
baudrate 6: 25, 11: 7
bcmp 6: 9
bcopy 6: 9
beep 6: 25, 11: 7
bind 6: 21
bit_attributes 6: 25
bit-field 3: 1
bkgd 6: 25, 11: 7
bkgdset 6: 25, 11: 7
bkgrnd 6: 25
bkgrndset 6: 25
boolcodes 6: 25
boolfnames 6: 25
boolnames 6: 25
border 6: 25, 11: 7
border_set 6: 25
box 6: 25, 11: 7
box_set 6: 25
brk 6: 9
broadcast packet 7: 26
broadcast RPC 7: 37
bsd_signal 6: 9
bsearch 6: 6
byte order 4: 8
bzero 6: 9

CC language
ABI reference language
ANSI 1: 2, 3: 1, 6: 3
assembly names 4: 22
calling sequence 3: 4
library (see library)
C library 6: 5
CALL 7: 27–28
call_body 7: 28
calling sequence 3: 1, 4

IN-2

3: 1

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 232

signals 1: 6
system traps 1: 6
calloc 6: 6
can_change_color 6: 25, 11: 7
catclose 6: 8
catgets 6: 8
catopen 6: 8
cbreak 6: 25, 11: 7
cc 11: 1
cfgetispeed 6: 8
cfgetospeed 6: 8
cfsetispeed 6: 8
cfsetospeed 6: 8
character sets 3: 2, 7: 2
chdir 6: 8
chgat 6: 25
chmod 6: 8
chown 6: 8
chroot 6: 8
_cleanup 6: 9
clear 6: 25, 11: 7
clearerr 6: 6
clearok 6: 25, 11: 7
clnt_create 6: 20
clnt_dg_create 6: 20
clnt_pcreateerror 6: 20
clnt_perrno 6: 20
clnt_perror 6: 20
clnt_raw_create 6: 20
clnt_spcreateerror 6: 20
clnt_sperrno 6: 20
clnt_sperror 6: 20
clnt_tli_create 6: 20
clnt_tp_create 6: 20
clnt_vc_create 6: 20
clock 6: 6
close 6: 8
close 6: 21
closedir 6: 8
closelog 6: 9
clrtobot 6: 25, 11: 7
clrtoeol 6: 25, 11: 7

code generation 3: 6
code sequences 3: 6
color_content 6: 25, 11: 7
colorConvertArgs 6: 37
common symbols 4: 11
compositeClassRec 6: 37
compositeWidgetClass 6: 37
compver 2: 3, 11
cond_broadcast 6: 15
cond_destroy 6: 15
cond_init 6: 15
cond_signal 6: 15
cond_timedwait 6: 15
cond_wait 6: 15
confstr 6: 8
connect 6: 21
connld 12: 2
constraintClassRec 6: 37
constraintWidgetClass 6: 37
conversation key 7: 32
copyright 2: 3, 10
copywin 6: 25, 11: 7
core file 4: 5
coreWidgetClass 6: 37
cpio 2: 1, 4–6, 7: 6
creat 6: 8
ctermid 6: 8
ctime 6: 6
ctime_r 6: 8
_ _ctype 6: 12
cur_bools 6: 25
cur_nums 6: 25
curscr 6: 25
curs_errno 6: 25
curs_parm_err 6: 25
curs_set 6: 25, 11: 7
cur_strs 6: 25
cur_term 6: 25
cuserid 6: 8

Index

IN-3

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 233

D
DARPA 12: 2
data object sizes 6: 47
data representation 4: 3, 8
date 9: 1
date and time 9: 1
_daylight 6: 12
daylight 6: 12
dbm_clearerr 6: 9
dbm_close 6: 9
dbm_delete 6: 9
dbm_error 6: 9
dbm_fetch 6: 9
dbm_firstkey 6: 9
dbm_nextkey 6: 9
dbm_open 6: 9
dbm_store 6: 9
dd 2: 1
DDN Protocol Handbook, DARPAInternet Protocols 12: 2
def_prog_mode 6: 25, 11: 7
def_shell_mode 6: 25, 11: 7
delay_output 6: 25, 11: 7
delch 6: 25, 11: 7
del_curterm 6: 25, 11: 7
deleteln 6: 25, 11: 7
delscreen 6: 25, 11: 7
delwin 6: 25, 11: 7
depend 2: 3, 11
derwin 6: 25, 11: 7
DES authentication protocol 7: 33
DES key 7: 32
des_block 7: 34/dev 9: 4
Development Environment 11: 1, 3
device drivers 12: 2
device nodes 12: 2/dev/lpX 9: 4
/dev/null 9: 4
/dev/ptmx 12: 2/dev/pts 12: 2/dev/tcp 12: 2/dev/ticlts 12: 2/dev/ticots 12: 2/dev/ticotsord 12: 2/dev/tty 9: 4
/dev/udp 12: 2
Diffie-Hellman 7: 32
difftime 6: 6
dirname 6: 9
div 6: 6
dlclose 6: 17
dlerror 6: 17
dlopen 6: 17
dlsym 6: 17
doupdate 6: 25, 11: 7
dup 6: 8
dup2 6: 8
dupwin 6: 25, 11: 7_DYNAMIC 5: 14
see also dynamic linking 5: 14
dynamic binding 7: 37
see also rpcbind protocol 7: 37
dynamic library (see shared object
file)
dynamic linker 4: 1, 5: 13
see also dynamic linking 5: 13
see also link editor 5: 13
see also shared object file 5: 13
dynamic linking 1: 5, 5: 12, 6: 2, 11
base address 5: 5
_DYNAMIC 5: 14
environment 5: 14, 20
hash function 5: 21
initialization function 5: 17, 22
lazy binding 5: 14
LD_BIND_NOW 5: 14
LD_LIBRARY_PATH 5: 20
relocation 5: 17
see also dynamic linker 5: 12
see also hash table 5: 17
see also procedure linkage table
5: 16

IN-4

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 234

string table 5: 17
symbol resolution 5: 19
symbol table 4: 14, 18, 5: 17
termination function 5: 17, 22
dynamic linking library 6: 17/etc/opt 2: 15, 9: 3
/etc/opt/pkg 9: 5
/etc/passwd 7: 1
example 6: 45
exec(BA_OS) 4: 1, 5: 12–14, 20, 6: 13,
9: 2

Eecho 6: 25, 11: 7
echochar 6: 25, 11: 7
echo_wchar 6: 25
echowchar 11: 7
ecvt 6: 9
ELF 4: 1
encrypted timestamp 7: 32
endgrent 6: 9
endhostent 6: 21
endnetconfig 6: 20
endnetent 6: 21
endnetpath 6: 20
endprotoent 6: 21
endpwent 6: 9
endservent 6: 21
endutxent 6: 9
endwin 6: 25, 11: 7
ENOSYS 6: 13, 19
entry point (see process, entry point)_environ 6: 12
environ 6: 13
environment 5: 14, 20
envvar 8: 1, 9: 2
erase 6: 25, 11: 7
erasechar 6: 25, 11: 7
erasewchar 6: 25_ _ _errno 6: 9
_ _errno 6: 10_ _errno 6: 12
errno 6: 12–13, 19/etc 9: 3–4/etc subtree 9: 4
/etc/mnttab 7: 1

execl 6: 8
execle 6: 8
execlp 6: 8
executable file 4: 1
execv 6: 8
execve 6: 8
execvp 6: 8
exit 5: 26, 6: 4
_exit 6: 6
exit 6: 6
External Data Representation

7: 10

F
fattach 6: 8
fchdir 6: 8
fchmod 6: 8
fchown 6: 8
fclose 6: 6
fcntl 6: 8
fcntl 6: 21
fcvt 6: 9
fdetach 6: 8
fdopen 6: 8
feof 6: 6
ferror 6: 6
fflush 6: 6
ffs 6: 9
fgetc 6: 6
fgetpos 6: 6
fgetpos 6: 21
fgets 6: 6
fgetwc 6: 6
fgetws 6: 6
_ _filbuf 6: 9

Index

IN-5

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 235

filearchive (see archive file)object (see object file)
file formats 7: 1
file system structure and contents 9: 3
fileno 6: 8
filter 6: 25, 11: 7
flash 6: 25, 11: 7
flockfile 6: 8
_ _flsbuf 6: 9
flushinp 6: 25, 11: 7
fnmatch 6: 8
fopen 6: 6
fork 6: 8
fork1 6: 8
forkall 6: 8
formatsarchive file 7: 2
object file 4: 1
formats and protocols for networking
7: 10

FORTRAN 4: 11
fpathconf 6: 8
fprintf 6: 6
fputc 6: 6
fputs 6: 6
fputwc 6: 6
fputws 6: 6
fread 6: 6
free 6: 6
freenetconfigent 6: 20
freopen 6: 6
frexp 6: 6
fscanf 6: 6
fseek 6: 6
fsetpos 6: 6
fsetpos 6: 21
fstat 6: 11
fstatvfs 6: 8
fsync 6: 8
ftell 6: 6
ftell 6: 21

ftime 6: 9
ftok 6: 8
ftruncate 6: 9
ftrylockfile 6: 8
ftw 6: 9ftw(BA_LIB) 6: 10
function linkage (see calling
sequence)
funlockfile 6: 8
fwprintf 6: 6
fwrite 6: 6
fwscanf 6: 6G
GARBAGE_ARGS 7: 27, 29
gcvt 6: 9
GeometryCallback 6: 32
getbegyx 6: 25, 11: 7
getbkgd 6: 25
getbkgrnd 6: 25
getc 6: 6
getcchar 6: 25
getch 6: 25, 11: 7
getchar 6: 6
getchar_unlocked 6: 8
getcontext 6: 8
getc_unlocked 6: 8
getcwd 6: 8
getdate 6: 8
_getdate_err 6: 12
getdate_err 6: 12
getdtablesize 6: 9
getegid 6: 8
getenv 6: 6
geteuid 6: 8
getgid 6: 8
getgrent 6: 9
getgrgid 6: 8
getgrnam 6: 8
getgroups 6: 8

IN-6

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 236

gethostbyaddr 6: 21
gethostbyname 6: 21
gethostent 6: 21
gethostid 6: 9
gethostname 6: 21
getitimer 6: 9
getksym 6: 8
getlogin 6: 8
getlogin_r 6: 8
getmaxyx 6: 25, 11: 7
getmsg 6: 8
getnetbyaddr 6: 21
getnetbyname 6: 21
getnetconfig 6: 20
getnetconfigent 6: 20
getnetent 6: 21
getnetname 6: 20
getnetpath 6: 20
getnstr 6: 25
getn_wstr 6: 25
getnwstr 11: 7
getopt 6: 8
getpagesize 6: 9
getparyx 6: 25, 11: 7
getpass 6: 8
getpass_r 6: 8
getpeername 6: 21
getpgid 6: 8
getpgrp 6: 8
getpid 6: 8
getpmsg 6: 8
getppid 6: 8
getpriority 6: 9
getprotobyname 6: 21
getprotobynumber 6: 21
getprotoent 6: 21
getpublickey 6: 20
getpwent 6: 9
getpwnam 6: 8
getpwuid 6: 8
getrlimit 2: 8
getrlimit 6: 8

getrlimit 9: 1
getrusage 6: 9
gets 6: 6
getsecretkey 6: 20
getservbyname 6: 21
getservbyport 6: 21
getservent 6: 21
getsid 6: 8
getsockname 6: 21
getsockopt 6: 21
getstr 6: 25, 11: 7
getsubopt 6: 8
getsyx 11: 7
gettimeofday 6: 9
gettxt 6: 8
getuid 6: 8
getutxent 6: 9
getutxid 6: 9
getutxline 6: 9
getw 6: 8
getwc 6: 6
get_wch 6: 25
getwch 11: 7
getwchar 6: 6
getwd 6: 9
getwin 6: 25, 11: 7
get_wstr 6: 25
getwstr 11: 7
getyx 6: 25, 11: 7
glob 6: 8
global data symbols 6: 11, 32
global offset table 4: 19, 5: 13, 21
globfree 6: 8
gmtime 6: 6
gmtime_r 6: 8
grantpt 6: 8

H
halfdelay 6: 25, 11: 7
has_colors 6: 25, 11: 7

Index

IN-7

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 237

hash function 5: 21
hash table 4: 16, 19, 5: 13, 17, 21
has_ic 6: 25, 11: 7
has_il 6: 25, 11: 7
hcreate 6: 8
hdestroy 6: 8
header files 6: 46
hline 6: 25, 11: 7
hline_set 6: 25
host2netname 6: 20
hsearch 6: 8
htonl 6: 21
htons 6: 21

I
iconv 6: 8
iconv_close 6: 8
iconv_open 6: 8
idcok 6: 25, 11: 7
idlok 6: 25, 11: 7
IEEE POSIX P1003.1 (see POSIX)
ilogb 6: 9
immedok 6: 25, 11: 7
implementation of libc routines 6: 13
INADDR_ANY 12: 8
inch 6: 25, 11: 7
inchnstr 6: 25, 11: 7
inchstr 6: 25, 11: 7
index 6: 9
inet_addr 6: 21
inet_lnaof 6: 21
inet_makeaddr 6: 21
inet_netof 6: 21
inet_network 6: 21
inet_ntoa 6: 21
init 2: 8
init_color 6: 25, 11: 7
initgroups 6: 8
init_pair 6: 25, 11: 7
initscr 6: 25, 11: 7

initstate 6: 9
innstr 6: 25, 11: 7
innwstr 6: 25, 11: 7
insch 6: 25, 11: 7
insdelln 6: 25, 11: 7
insertln 6: 25, 11: 7
insnstr 6: 25, 11: 7
ins_nwstr 6: 25
insnwstr 11: 7
insque 6: 9
insstr 6: 25, 11: 7
install 2: 3, 6
installation and removal scripts
class scripts 2: 12
exit codes 2: 13
postinstall 2: 12
postremove 2: 12
preinstall 2: 12
preremove 2: 12
request 2: 11
installation media
file formats 2: 1
format 2: 1
software structure 2: 1
installf 2: 12, 16
instr 6: 25, 11: 7
ins_wch 6: 25
inswch 11: 7
ins_wstr 6: 25
inswstr 11: 7
Internet 12: 2, 4interpreter, see program interpreter
5: 12

intrflush 6: 25, 11: 7
in_wch 6: 25
inwch 11: 7
in_wchnstr 6: 25
inwchnstr 11: 7
in_wchstr 6: 25
inwchstr 11: 7
inwstr 6: 25, 11: 7_ _iob 6: 12

IN-8

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 238

ioctl 6: 8
IP Level Options 12: 11
IPOPT_EOL 12: 11
IPOPT_LSRR 12: 11
IPOPT_NOP 12: 11
IPOPT_SSRR 12: 11
isalnum 6: 6
isalpha 6: 6
isascii 6: 8
isastream 6: 8
isatty 6: 8
iscntrl 6: 6
isdigit 6: 6
isendwin 6: 25, 11: 7
isgraph 6: 6
is_linetouched 6: 25, 11: 7
islower 6: 6
isnan 6: 8
isnand 6: 8
ISO 12: 4
isprint 6: 6
ispunct 6: 6
isspace 6: 6
isupper 6: 6
iswalnum 6: 6
iswalpha 6: 6
iswcntrl 6: 6
iswctype 6: 6
_ _iswctype 6: 9–10
iswdigit 6: 6
iswgraph 6: 6
is_wintouched 6: 25, 11: 7
iswlower 6: 6
iswprint 6: 6
iswpunct 6: 6
iswspace 6: 6
iswupper 6: 6
iswxdigit 6: 6
isxdigit 6: 6

K
key_decryptsession 6: 20
key_encryptsession 6: 20
key_gendes 6: 20
key_name 6: 25
keyname 6: 25, 11: 7
keypad 6: 25, 11: 7
key_setsecret 6: 20
kill 6: 8
killchar 6: 25, 11: 7
killpg 6: 9
killwchar 6: 25

Ll64a 6: 9
labs 6: 6
lazy binding 5: 14
lchown 6: 8
ld 11: 1
LD_BIND_NOW 5: 14
ldexp 6: 6
ldiv 6: 6
LD_LIBRARY_PATH 5: 20
ld(SD_CMD) (see link editor)
ldterm 12: 2
leaveok 6: 25, 11: 7
lex 11: 1
lfind 6: 8
libc 6: 1–3, 11, 13
see also library 6: 1
libc contents 6: 5, 11
libc1 6: 10
libcurses 6: 1
libcurses 11: 4
libcurses contents 6: 22, 25
libdl 6: 1–3, 17
see also library 6: 1
libdl contents 6: 17
libext 10: 5
libm 11: 4

Index

IN-9

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 239

libMrm 6: 2–3, 38, 10: 5
see also library 6: 1
libMrm contents 6: 45
libnsl 6: 1–3, 18, 7: 10
see also library 6: 1
libnsl contents 6: 18–20
library
dynamic (see shared object file)
see also archive file 7: 2
see also libc 6: 1
see also libdl 6: 1
see also libMrm 6: 1
see also libnsl 6: 1
see also libthread 6: 1
see also libX 6: 1
see also libXext 6: 1
see also libXm 6: 1
see also libXt 6: 1
shared (see shared object file)libsocket 6: 1
libsocket contents 6: 21
libthread 6: 1–3
libthread 6: 15
libthread, see also library 6: 1
libthread contents 6: 15
libX 6: 1–3, 26, 32, 10: 3, 5
see also library 6: 1
libX contents 6: 26
libXext 6: 2–3, 33
see also library 6: 1
libXext contents 6: 33
libXm 6: 2–3, 38, 10: 5
see also library 6: 1
libXm contents 6: 38, 44
libXt 6: 1, 3, 34, 10: 5
see also library 6: 1
libXt contents 6: 34, 37
link 6: 8
link editor 4: 1, 24–25, 5: 13, 17, 20, 7: 2,
11: 1

see also dynamic linker 5: 13
linkage, function (see calling
sequence)

lio_listio 6: 16
listen 6: 21
loc1 6: 9
localeconv 6: 6
localeconv(BA_LIB)
localtime 6: 6
localtime_r 6: 8
lockf 6: 8
locs 6: 9
log1p 6: 9
logb 6: 8
logging files 9: 6
longjmp 6: 6_longjmp 6: 9
longname 6: 25, 11: 7
loopback 12: 2
lsearch 6: 8
lseek 6: 8
lseek 6: 21
lstat 6: 11

6: 12

M
m4 11: 1
magic number 4: 5, 7
main 4: 19
makecontext 6: 8
malloc 6: 6
math library 1: 4
MAXNETNAMELEN 7: 34
mblen 6: 6
mbrlen 6: 6
mbrtowc 6: 6
mbsinit 6: 6
mbsrtowcs 6: 6
mbstowcs 6: 6
mbtowc 6: 6
media, format 2: 4
memccpy 6: 8
memchr 6: 6
memcmp 6: 6

IN-10

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 240

memcntl 6: 8
memcntl 6: 13
memcpy 6: 6
memmove 6: 6
memory management 5: 6
memset 6: 6
message catalogues 7: 22
meta 6: 25, 11: 7
mkdir 6: 8
mkfifo 6: 8
mknod 6: 11
mkstemp 6: 9
mktemp 6: 8
mktime 6: 6
mlock 6: 8
mmap 6: 8
mmap(KE_OS) 5: 12
mnttab file 7: 1
modadm 6: 8
modf 6: 6
modload 6: 8
modpath 6: 8
modstat 6: 8
moduload 6: 8
MODULUS 7: 35
monitor 6: 8
Motif 10: 4
interface 10: 1
Motif Library 6: 38
mount 6: 8
Mouse_status 6: 25
move 6: 25, 11: 7
mprotect 6: 8
MrmCloseHierarchy 6: 45
MrmFetchBitmapLiteral 6: 45
MrmFetchColorLiteral 6: 45
MrmFetchIconLiteral 6: 45
MrmFetchLiteral 6: 45
MrmFetchSetValues 6: 45
MrmFetchWidget 6: 45
MrmFetchWidgetOverride 6: 45
MrmInitialize 6: 45

MrmOpenHierarchy 6: 45
MrmOpenHierarchyPerDisplay 6: 45
MrmRegisterClass 6: 45
MrmRegisterNames 6: 45
MrmRegisterNamesInHierarchy
6: 45

MSG_ACCEPTED 7: 27, 29
msgctl 6: 8
MSG_DENIED 7: 27, 29
msgget 6: 8
msgrcv 6: 8
msgsnd 6: 8
msg_type 7: 27
msync 6: 8
multibyte characters 3: 2
multithreaded applications 6: 15
multithreading interfaces 6: 15
munlock 6: 8
munmap 6: 8
mutex_destroy 6: 15
mutex_init 6: 15
mutex_lock 6: 15
mutex_trylock 6: 15
mutex_unlock 6: 15
mvaddch 6: 25, 11: 7
mvaddchnstr 6: 25, 11: 7
mvaddchstr 6: 25, 11: 7
mvaddnstr 6: 25, 11: 7
mvaddnwstr 6: 25, 11: 7
mvaddstr 6: 25, 11: 7
mvadd_wch 6: 25
mvaddwch 11: 7
mvadd_wchnstr 6: 25
mvaddwchnstr 11: 7
mvadd_wchstr 6: 25
mvaddwchstr 11: 7
mvaddwstr 6: 25, 11: 7
mvchgat 6: 25
mvcur 6: 25, 11: 7
mvdelch 6: 25, 11: 7
mvderwin 6: 25, 11: 7
mvgetch 6: 25, 11: 7

Index

IN-11

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 241

mvgetnstr 6: 25
mvgetn_wstr 6: 25
mvgetnwstr 11: 7
mvgetstr 6: 25, 11: 7
mvget_wch 6: 25
mvgetwch 11: 7
mvget_wstr 6: 25
mvgetwstr 11: 7
mvhline 6: 25
mvhline_set 6: 25
mvinch 6: 25, 11: 7
mvinchnstr 6: 25, 11: 7
mvinchstr 6: 25, 11: 7
mvinnstr 6: 25, 11: 7
mvinnwstr 6: 25, 11: 7
mvinsch 6: 25, 11: 7
mvinsnstr 6: 25, 11: 7
mvins_nwstr 6: 25
mvinsnwstr 11: 7
mvinsstr 6: 25, 11: 7
mvinstr 6: 25, 11: 7
mvins_wch 6: 25
mvinswch 11: 7
mvins_wstr 6: 25
mvinswstr 11: 7
mvin_wch 6: 25
mvinwch 11: 7
mvin_wchnstr 6: 25
mvinwchnstr 11: 7
mvin_wchstr 6: 25
mvinwchstr 11: 7
mvinwstr 6: 25, 11: 7
mvprintw 6: 25, 11: 7
mvscanw 6: 25, 11: 7
mvvline 6: 25
mvvline_set 6: 25
mvwaddch 6: 25, 11: 7
mvwaddchnstr 6: 25, 11: 7
mvwaddchstr 6: 25, 11: 7
mvwaddnstr 6: 25, 11: 7
mvwaddnwstr 6: 25, 11: 7
mvwaddstr 6: 25, 11: 7

mvwadd_wch 6: 25
mvwaddwch 11: 7
mvwadd_wchnstr 6: 25
mvwaddwchnstr 11: 7
mvwadd_wchstr 6: 25
mvwaddwchstr 11: 7
mvwaddwstr 6: 25, 11: 7
mvwchgat 6: 25
mvwdelch 6: 25, 11: 7
mvwgetch 6: 25, 11: 7
mvwgetnstr 6: 25
mvwgetn_wstr 6: 25
mvwgetnwstr 11: 7
mvwgetstr 6: 25, 11: 7
mvwget_wch 6: 25
mvwgetwch 11: 7
mvwget_wstr 6: 25
mvwgetwstr 11: 7
mvwhline 6: 25
mvwhline_set 6: 25
mvwin 6: 25, 11: 7
mvwinch 6: 25, 11: 7
mvwinchnstr 6: 25, 11: 7
mvwinchstr 6: 25, 11: 7
mvwinnstr 6: 25, 11: 7
mvwinnwstr 6: 25, 11: 7
mvwinsch 6: 25, 11: 7
mvwinsnstr 6: 25, 11: 7
mvwins_nwstr 6: 25
mvwinsnwstr 11: 7
mvwinsstr 6: 25, 11: 7
mvwinstr 6: 25, 11: 7
mvwins_wch 6: 25
mvwinswch 11: 7
mvwins_wstr 6: 25
mvwinswstr 11: 7
mvwin_wch 6: 25
mvwinwch 11: 7
mvwin_wchnstr 6: 25
mvwinwchnstr 11: 7
mvwin_wchstr 6: 25
mvwinwchstr 11: 7

IN-12

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 242

mvwinwstr 6: 25, 11: 7
mvwprintw 6: 25, 11: 7
mvwscanw 6: 25, 11: 7
mvwvline 6: 25
mvwvline_set 6: 25

noecho 6: 25, 11: 7
nonl 6: 25, 11: 7
noqiflush 6: 25, 11: 7
noraw 6: 25, 11: 7
notimeout 6: 25, 11: 7
ntohl 6: 21
ntohs 6: 21
numcodes 6: 25_numeric 6: 12
numerical limits 9: 1
numfnames 6: 25
numnames 6: 25

Nnapms 6: 25, 11: 7
nc_perror 6: 20
nc_sperror 6: 20_nderror 6: 20
netdir_free 6: 20
netdir_getbyaddr 6: 20
netdir_getbyname 6: 20
netdir_options 6: 20
netdir_perror 6: 20
netdir_sperror 6: 20
netname 7: 31, 33
netname2host 6: 20
netname2user 6: 20
network clients 7: 22
network name 7: 31
network service 7: 22
network services library 6: 18
network time synchronization
networking 12: 1
networks
loopback 12: 1
peer-to-peer 12: 1
newpad 6: 25, 11: 7
newterm 6: 25, 11: 7
newwin 6: 25, 11: 7
nextafter 6: 8
nftw 6: 8
nice 6: 8
nl 6: 25, 11: 7
nl_langinfo 6: 8
no 6: 25
nocbreak 6: 25, 11: 7
nodelay 6: 25, 11: 7

O

7: 32

object file 4: 1
archive file 4: 24, 7: 2
data representation 4: 3
data types 4: 3
ELF header 4: 2, 4
extensions 4: 6
format 4: 1
hash table 5: 13, 17, 21
program header 4: 2, 5: 2
program loading 5: 2
relocation 4: 16, 27, 5: 17
section 4: 2, 10
section alignment 4: 13
section attributes 4: 15
section header 4: 2, 10
section names 4: 20
section types 4: 13
see also archive file 4: 1
see also dynamic linking 5: 12
see also executable file 4: 1
see also relocatable file 4: 1
see also shared object file 4: 1
segment 5: 1–2
shared object file 5: 13
special sections 4: 17
string table 4: 16, 21–22

Index

IN-13

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 243

symbol table 4: 16, 22
type 4: 5
version 4: 6
objectClass 6: 37
objectClassRec 6: 37
opaque_auth 7: 25, 30
open 6: 8
opendir 6: 8
openlog 6: 9
/opt 2: 15, 9: 3–5/opt subtree 9: 5
optarg 6: 12
opterr 6: 12
optind 6: 12
optopt 6: 12/opt/pkg/bin 9: 5
outchcount 6: 25
overlay 6: 25, 11: 7
overrideShellClassRec 6: 37
overrideShellWidgetClass 6: 37
overwrite 6: 25, 11: 7

Ppackage installation 9: 3
packages 2: 2–16
pair_content 6: 25, 11: 7
password file 7: 1
PATH 8: 1, 11: 3
pathconf 6: 8
pathconf 9: 1
pause 6: 8
pckt 12: 2
pclose 6: 8
pechochar 6: 25, 11: 7
pecho_wchar 6: 25
pechowchar 11: 7
permissions, process segments (seesegment permissions)per-process environment information

perror 6: 6
pipe 6: 8
pipemod 12: 2
pkgadd 2: 7–8, 16
pkgask 2: 8, 16
pkgchk 2: 16
pkginfo 2: 3, 5–9, 11–12, 16
pkgmap 2: 3, 8–10, 12
pkgmk 11: 3
pkgparam 2: 16
pkgproto 11: 3
pkgrm 2: 7, 16
pkgtrans 11: 3
pnoutrefresh 6: 25, 11: 7
poll 6: 8
pool 6: 21
popen 6: 8
position-independent code 5: 13
POSIX 1: 2, 6: 1, 10, 15, 46, 7: 6, 9: 1
POSIX 1003.1c 6: 15
POSIX 1003.4a 6: 15
PostScript 10: 4
pread 6: 8
PreeditCaretCallback 6: 32
PreeditDoneCallback 6: 32
PreeditDrawCallback 6: 32
PreeditStartCallback 6: 32
prefresh 6: 25, 11: 7
printf 6: 6
printw 6: 25, 11: 7
priocntl 6: 8
priocntllist 6: 8
procedure linkage table 4: 19, 25, 5: 13,
16–17, 19, 21

process
entry point 4: 6, 19, 5: 22
image 4: 1, 5: 1–2
virtual addressing 5: 2
processor-specific 5: 13
processor-specific information

3: 1,
3–6, 4: 5–6, 8–10, 15–16, 20, 24–25,
27–28, 5: 1, 4, 6–7, 11, 13, 19, 21, 6: 11,
47, 9: 4, 11: 2–4

9: 2

IN-14

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 244

PROC_UNAVAIL 7: 27, 29
profil 6: 8
PROG_MISMATCH 7: 27, 29
program header 5: 2
program interpreter 4: 19, 5: 12–13
program loading 5: 1, 11
programming language, ABI reference 3: 1
PROG_UNAVAIL 7: 27, 29
protocol version 2 7: 24
pseudo terminal 12: 2
ptem 12: 2
ptrace 6: 8
ptsname 6: 8
putc 6: 6
putc(BA_LIB) 6: 9
putchar 6: 6
putchar_unlocked 6: 8
putc_unlocked 6: 8
putenv 6: 8
putmsg 6: 8
putp 6: 25, 11: 7
putpmsg 6: 8
puts 6: 6
pututxline 6: 9
putw 6: 8
putwc 6: 6
putwchar 6: 6
putwin 6: 25, 11: 7
pwrite 6: 8

Qqiflush 6: 25, 11: 7
qsort 6: 6

Rraise 6: 6
rand 6: 6
random 6: 9

rand_r 6: 8
raw 6: 25, 11: 7
read 6: 8
read 6: 21
readdir 6: 8
readdir_r 6: 8
readlink 6: 8
readv 6: 8
realloc 6: 6
realpath 6: 9
re_comp 6: 9
rectObjClass 6: 37
rectObjClassRec 6: 37
recv 6: 21
recvfrom 6: 21
recvmsg 6: 21
redrawwin 6: 25, 11: 7
re_exec 6: 9
refresh 6: 25, 11: 7
regcmp 6: 9
regcomp 6: 8
regerror 6: 8
regex 6: 9
regexec 6: 8
regexp 6: 9
regfree 6: 8
rejected_reply 7: 30
reject_stat 7: 27
reliable byte stream protocols 7: 26
reloc 2: 3, 6
relocatable file 4: 1
relocation, see object file 4: 27
remove 6: 6
removef 2: 12, 16
remque 6: 9
rename 6: 6
REPLY 7: 27–28
reply_body 7: 29
reply_stat 7: 27
required sizes for some data objects
6: 46

requirements, summary

Index

10: 5

IN-15

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 245

reset_prog_mode 6: 25, 11: 7
reset_shell_mode 6: 25, 11: 7
resetty 6: 25, 11: 7
restartterm 6: 25, 11: 7
rewind 6: 6
rewinddir 6: 8
rindex 6: 9
rint 6: 9
ripoffline 6: 25, 11: 7
rmdir 6: 8
rmutex_destroy 6: 15
rmutex_init 6: 15
rmutex_lock 6: 15
rmutex_trylock 6: 15
rmutex_unlock 6: 15
root 2: 3, 6
root subtree 9: 3
RPC
authentication 7: 23, 25
authentication protocols 7: 30
basic authentication for UNIX Systems 7: 30
batching 7: 26
binding and rendezvous independence 7: 23
broadcast 7: 26
DES authentication 7: 31
DES authentication verifiers 7: 32
DES nicknames and clock synchronization 7: 33
message protocol 7: 27
naming 7: 31
null authentication 7: 30
program number assignment 7: 25
programs and procedures 7: 24
record marking standard 7: 36
transports and semantics 7: 22
uses of the RPC protocol 7: 26
RPC_AUTHERROR 7: 33
rpcb_getaddr 6: 20
rpcb_getmaps 6: 20
rpcb_gettime 6: 20

rpcbind 7: 22, 26, 37–38
mechanism 7: 37
operation 7: 38
protocol 7: 23
protocol specification 7: 37
RPCBPROC_CALLIT 7: 37–38
RPCBPROC_DUMP 7: 37–38
RPCBPROC_GETADDR 7: 37–38
RPCBPROC_GETTIME 7: 37, 39
RPCBPROC_NULL 7: 37
RPCBPROC_SET 7: 37–38
RPCBPROC_UNSET 7: 37–38
RPCBPROG 7: 37
rpcb_rmtcall 6: 20
rpc_broadcast 6: 20
rpc_broadcast_exp 6: 20
rpcb_set 6: 20
rpcb_unset 6: 20
RPCBVERS 7: 37
rpc_call 6: 20
rpc_createerr 6: 20
RPC_MISMATCH 7: 27, 30
rpc_msg 7: 28
rpc_reg 6: 20
rwlock_destroy 6: 15
rwlock_init 6: 15
rw_rdlock 6: 15
rw_tryrdlock 6: 15
rw_trywrlock 6: 15
rw_unlock 6: 15
rw_wrlock 6: 15

S
SARMAG 7: 2
savetty 6: 25, 11: 7
sbrk 6: 9
scalb 6: 8
scanf 6: 6
scanw 6: 25, 11: 7
scr_dump 6: 25, 11: 7

IN-16

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 246

screenConvertArg 6: 37
scr_init 6: 25, 11: 7
scripts 2: 3
scrl 6: 25, 11: 7
scroll 6: 25, 11: 7
scrollok 6: 25, 11: 7
scr_restore 6: 25, 11: 7
scr_set 6: 25, 11: 7
SD_CMD 11: 1
security control mechanisms
sed 2: 13
seekdir 6: 8
segment
dynamic 5: 12, 14
object file 5: 1–2
process 5: 1, 12–13, 19
program header 5: 2
segment permissions 5: 5
select 6: 9, 21
sema_destroy 6: 15
sema_init 6: 15
sema_post 6: 15
sema_trywait 6: 15
sema_wait 6: 15
semctl 6: 8
semget 6: 8
semop 6: 8
send 6: 21
sendmsg 6: 21
sendto 6: 21
server 7: 22, 10: 4
setbuf 6: 6
setcat 6: 8
setcchar 6: 25
setcontext 6: 8
set_curterm 6: 25, 11: 7
setgid 6: 8
setgrent 6: 9
setgroups 6: 8
sethostent 6: 21
setitimer 6: 9
setjmp 6: 6

7: 23

_setjmp 6: 9
setlabel 6: 8
setlocale 6: 6
setlocale(BA_OS) 6: 12
setlogmask 6: 9
setnetconfig 6: 20
setnetent 6: 21
setnetpath 6: 20
setpgid 6: 8
setpgrp 6: 8
setpriority 6: 9
setprotoent 6: 21
setpwent 6: 9
setregid 6: 9
setreuid 6: 9
setrlimit 6: 8
setscrreg 6: 25, 11: 7
setservent 6: 21
setsid 6: 8
setsockopt 6: 21
setstate 6: 9
setsyx 11: 7
set_term 6: 25, 11: 7
setterm 11: 7
setuid 6: 8
setupterm 6: 25, 11: 7
set-user ID programs 5: 21
setutxent 6: 9
setvbuf 6: 6
sh 2: 11
shared library (see shared object file)shared library names 6: 3
shared object file 4: 1, 6: 1
functions 4: 25
see also dynamic linking 5: 13
see also object file 5: 13
shell scripts 4: 1
shellClassRec 6: 37
shellWidgetClass 6: 37
shmat 6: 8
shmctl 6: 8
shmdt 6: 8

Index

IN-17

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 247

shmget 6: 8
shutdown 6: 21
sigaction 6: 8
sigaddset 6: 8
sigaltstack 6: 8
sigdelset 6: 8
sigemptyset 6: 8
sigfillset 6: 8
sighold 6: 8
sigignore 6: 8
siginterrupt 6: 9
sigismember 6: 8
siglongjmp 6: 8
signal 6: 6
signgam 6: 9
sigpause 6: 8
sigpending 6: 8
sigprocmask 6: 8
sigrelse 6: 8
sigsend 6: 8
sigsendset 6: 8
sigset 6: 8
sigsetjmp 6: 8
sigstack 6: 9
sigsuspend 6: 8
sigwait 6: 8
sin 6: 2
sleep 6: 8
slk_attr_off 6: 25
slk_attroff 6: 25, 11: 7
slk_attr_on 6: 25
slk_attron 6: 25, 11: 7
slk_attr_set 6: 25
slk_attrset 6: 25, 11: 7
slk_clear 6: 25, 11: 7
slk_init 6: 25, 11: 7
slk_label 6: 25, 11: 7
slk_noutrefresh 6: 25, 11: 7
slk_refresh 6: 25, 11: 7
slk_restore 6: 25, 11: 7
slk_set 6: 25, 11: 7
slk_touch 6: 25, 11: 7

slk_wset 6: 25
snprintf 6: 8
socket 6: 21
socketpair 6: 21
software structure 2: 2–16
SP 6: 25
space 2: 3, 10
sprintf 6: 6
srand 6: 6
srandom 6: 9
sscanf 6: 6
standend 6: 25, 11: 7
standout 6: 25, 11: 7
start_color 6: 25, 11: 7
stat 2: 10, 6: 11, 7: 3
StatusDoneCallback 6: 32
StatusDrawCallback 6: 32
StatusStartCallback 6: 32
statvfs 6: 8
stdscr 6: 25
stime 6: 8
strcasecmp 6: 9
strcat 6: 6
strchr 6: 6
strcmp 6: 6
strcodes 6: 25
strcoll 6: 6
strcpy 6: 6
strcspn 6: 6
strdup 6: 8
STREAMS-based pipe 12: 3
strerror 6: 6
strfmon 6: 8
strfnames 6: 25
strftime 6: 6
string table
see archive file 7: 2
see object file 4: 21
strlen 6: 6
strlist 6: 8
strnames 6: 25
strncasecmp 6: 9

IN-18

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 248

strncat 6: 6
strncmp 6: 6
strncpy 6: 6
strpbrk 6: 6
strptime 6: 8
strrchr 6: 6
strspn 6: 6
strstr 6: 6
strtod 6: 6
strtof 6: 8
strtok 6: 6
strtok_r 6: 8
strtol 6: 6
strtold 6: 8
strtoul 6: 6
strxfrm 6: 6
subpad 6: 25, 11: 7
subwin 6: 25, 11: 7
SUCCESS 7: 27, 29
sum 2: 10
svc_create 6: 20
svc_dg_create 6: 20
svcerr_auth 6: 20
svcerr_decode 6: 20
svcerr_noproc 6: 20
svcerr_noprog 6: 20
svcerr_progvers 6: 20
svcerr_systemerr 6: 20
svcerr_weakauth 6: 20
svc_fd_create 6: 20
svc_fdset 6: 20
svc_getreq_common 6: 20
svc_getreq_poll 6: 20
svc_getreqset 6: 20
svc_raw_create 6: 20
svc_reg 6: 20
svc_run 6: 20
svc_sendreply 6: 20
svc_tli_create 6: 20
svc_tp_create 6: 20
svc_unreg 6: 20
svc_vc_create 6: 20

SVID 11: 1, 3–4, 12: 2
swab 6: 8
swapcontext 6: 8
swprintf 6: 6
swscanf 6: 6
symbol names, C and assembly 4: 22
symbol table, see object file 4: 22
symbolsabsolute 4: 11
binding 4: 23
common 4: 11
see also hash table 4: 19
shared object file functions 4: 25
type 4: 24
undefined 4: 10
value 4: 24, 26
symlink 6: 8
sync 6: 8
syncok 6: 25, 11: 7
sysconf 6: 8
sysconf 9: 1
syslog 6: 9
system 6: 6
system 9: 2
system calls 6: 5
extensions 6: 14_$vendor.company 6: 14
system data interfaces 6: 46
system identification 9: 1

T
TABSIZE 6: 25
t_accept 6: 18
t_accept 12: 8
T_ACCEPT1 12: 5
T_ACCEPT2 12: 5
T_ACCEPT3 12: 5
TACCES 12: 4
T_ADDR 12: 5
taddr2uaddr 6: 20

Index

IN-19

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 249

TADDRBUSY 12: 4
T_ALL 12: 5
t_alloc 6: 18
TBADADDR 12: 4
TBADDATA 12: 4
TBADF 12: 4
TBADFLAG 12: 4
TBADNAME 12: 4
TBADOPT 12: 4
TBADQLEN 12: 4
TBADSEQ 12: 4
t_bind 6: 18
T_BIND 12: 5
t_bind 12: 8
TBUFOVFLW 12: 4
T_CALL 12: 5
tcdrain 6: 8
tcflow 6: 8
tcflush 6: 8
tcgetattr 6: 8
tcgetpgrp 6: 8
tcgetsid 6: 8
T_CHECK 12: 4
t_close 6: 18
T_CLOSE 12: 5
T_CLTS 12: 4, 8
t_connect 6: 18
T_CONNECT 12: 4
t_connect 12: 8
T_CONNECT1 12: 5
T_CONNECT2 12: 5
T_COTS 12: 4
T_COTS_ORD 12: 4, 8
TCP/IP 7: 22, 26, 36
tcsendbreak 6: 8
tcsetattr 6: 8
tcsetpgrp 6: 8
T_DATA 12: 4
T_DATAXFER 12: 5
T_DEFAULT 12: 4
tdelete 6: 8
T_DIS 12: 5

T_DISCONNECT 12: 4
tell 6: 8
telldir 6: 8
tempnam 6: 8
temporary files 9: 6
termattrs 6: 25, 11: 7
term_errno 6: 25
terminfo(TI_ENV) 7: 7
termname 6: 25, 11: 7
term_parm_err 6: 25
t_errno 6: 20
t_error 6: 18
T_ERROR 12: 4
T_EVENTS 12: 4
T_EXDATA 12: 4
T_EXPEDITED 12: 4
T_FAILURE 12: 4
T_FAKE 12: 5
tfind 6: 8
TFLOW 12: 4
t_free 6: 18
tgetent 6: 25, 11: 7
tgetflag 6: 25, 11: 7
t_getinfo 6: 18
t_getinfo 12: 9
tgetnum 6: 25, 11: 7
t_getstate 6: 18
tgetstr 6: 25, 11: 7
tgoto 6: 25, 11: 7
thr_continue 6: 15
thr_create 6: 15
Threads Library 6: 15_ _thr_errno 6: 9–10
_ _thr_errno 6: 12
thr_exit 6: 15
thr_getconcurrency 6: 15
thr_getprio 6: 15
thr_get_rr_interval 6: 15
thr_getscheduler 6: 15
thr_getspecific 6: 15
thr_join 6: 15
thr_keycreate 6: 15

IN-20

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 250

thr_keydelete 6: 15
thr_kill 6: 15
thr_minstack 6: 15
thr_self 6: 15
thr_setconcurrency 6: 15
thr_setprio 6: 15
thr_setscheduler 6: 15
thr_setspecific 6: 15
thr_sigsetmask 6: 15
thr_suspend 6: 15
thr_yield 6: 15
T_IDLE 12: 5
tigetflag 6: 25, 11: 7
tigetnum 6: 25, 11: 7
tigetstr 6: 25, 11: 7
time 6: 8
time 7: 3, 9: 1
timeout 6: 25, 11: 7
times 6: 8
timestamp 7: 34_timezone 6: 12
timezone 6: 12
timod 12: 2, 4
T_INCON 12: 5
TINDOUT 12: 4
T_INFO 12: 5
T_INREL 12: 5
tirdwr 12: 2, 4
t_listen 6: 18
T_LISTEN 12: 4
t_listen 12: 9
T_LISTN 12: 5
t_look 6: 18
TLOOK 12: 4
T_MORE 12: 4
tmpfile 6: 6
tmpnam 6: 6
T_NEGOTIATE 12: 4
TNOADDR 12: 4
TNODATA 12: 4
TNODIS 12: 4
TNOREL 12: 4

T_NOSTATES 12: 5
TNOSTRUCTYPE 12: 4
TNOTSUPPORT 12: 4
TNOUDERR 12: 4
toascii 6: 8
tolower 6: 6
_tolower 6: 9
t_open 6: 18
T_OPEN 12: 5
t_open 12: 9
topLevelShellClassRec 6: 37
topLevelShellWidgetClass 6: 37
T_OPT 12: 5
t_optmgmt 6: 18
T_OPTMGMT 12: 5
t_optmgmt 12: 10
T_ORDREL 12: 4
touchline 6: 25, 11: 7
touchwin 6: 25, 11: 7
toupper 6: 6
_toupper 6: 9
T_OUTCON 12: 5
T_OUTREL 12: 5
TOUTSTATE 12: 4
towlower 6: 6
towupper 6: 6
tparm 6: 25, 11: 7
T_PASSCON 12: 5
TPROTO 12: 4
TPROVMISMATCH 12: 4
tputs 6: 25, 11: 7
TQFULL 12: 4
transientShellClassRec 6: 37
transientShellWidgetClass 6: 37
transport 12: 2
t_rcv 6: 18
T_RCV 12: 5
t_rcv 12: 12
t_rcvconnect 6: 18
T_RCVCONNECT 12: 5
t_rcvconnect 12: 12
t_rcvdis 6: 18

Index

IN-21

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 251

T_RCVDIS1 12: 5
T_RCVDIS2 12: 5
T_RCVDIS3 12: 5
t_rcvrel 6: 18
T_RCVREL 12: 5
t_rcvudata 6: 18
T_RCVUDATA 12: 5
t_rcvudata 12: 12
t_rcvuderr 6: 18
T_RCVUDERR 12: 5
t_rcvuderr 12: 12
truncate 6: 9
_ _trwctype 6: 9
tsearch 6: 8
t_snd 6: 18
T_SND 12: 5
t_snd 12: 12
t_snddis 6: 18
t_snddis 12: 13
T_SNDDIS1 12: 5
T_SNDDIS2 12: 5
t_sndrel 6: 18
T_SNDREL 12: 5
t_sndrel 12: 13
t_sndudata 6: 18
T_SNDUDATA 12: 5
t_sndudata 12: 13
TSTATECHNG 12: 4
T_SUCCESS 12: 4
t_sync 6: 18
TSYSERR 12: 4
ttyname 6: 8
ttyname_r 6: 8
ttyslot 6: 9
ttytype 6: 25
T_UDATA 12: 5
T_UDERR 12: 4
T_UDERROR 12: 5
t_unbind 6: 18
T_UNBIND 12: 5
T_UNBND 12: 5
T_UNINIT 12: 5

T_UNITDATA 12: 5
twalk 6: 8
typeahead 6: 25, 11: 7_tzname 6: 12
tzname 6: 12tzset 6: 8
tzset(BA_LIB) 6: 12

Uuaddr2taddr 6: 20
ualarm 6: 9
UDP/IP 7: 22, 26__ctype 6: 12
ulimit 6: 8__iob 6: 12_ _trwctype(wint_t wc, wctype_t
charclass) 6: 10
umask 6: 8
umount 6: 8
uname 6: 11, 9: 1
unctrl 6: 25, 11: 7
undefined behavior 1: 8, 4: 13, 5: 10,
6: 14

undefined symbols 4: 10
ungetc 6: 6
ungetch 6: 25, 11: 7
ungetwc 6: 6
unget_wch 6: 25
ungetwch 11: 7
unlink 6: 8
unlockpt 6: 8
unspecified property 4: 2, 5, 10–11,
15–16, 18–19, 24–25, 5: 2, 4, 6, 9, 18–19,
6: 5, 11
untouchwin 6: 25, 11: 7
use_env 6: 25, 11: 7
user2netname 6: 20
usleep 6: 9
/usr 9: 3–5/usr subtree 9: 5

IN-22

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 252

/usr/bin 9: 5
/usr/lib/X11 9: 5
/usr/lib/X11/app-defaults 9: 5
/usr/lib/X11/locale 9: 5
/usr/share 9: 5
/usr/share/lib 9: 5
/usr/share/lib/terminfo/ 7: 7
utime 6: 8
utimes 6: 9

Vvalloc 6: 9
/var 9: 3–4/var subtree 9: 6
/var/opt 2: 15/var/opt/pkg 9: 6
/var/tmp 9: 6
vendor extensions 6: 14_$vendor.company 6: 14
vendorShellClassRec 6: 37, 45
vendorShellWidgetClass 6: 37, 45
vfork 6: 9
vfprintf 6: 6
vfscanf 6: 8
vfwprintf 6: 6
vfwscanf 6: 8
vid_attr 6: 25
vidattr 6: 25, 11: 7
vid_puts 6: 25
vidputs 6: 25, 11: 7
virtual addressing 5: 2
vline 6: 25, 11: 7
vline_set 6: 25
VMTP 7: 23
vprintf 6: 6
vscanf 6: 8
vsnprintf 6: 8
vsprintf 6: 6
vsscanf 6: 8
vswprintf 6: 6

vswscanf 6: 8
vwprintf 6: 6
vw_printw 6: 25
vwprintw 6: 25, 11: 7
vwscanf 6: 8
vw_scanw 6: 25
vwscanw 6: 25, 11: 7

W
waddch 6: 25, 11: 7
waddchnstr 6: 25, 11: 7
waddchstr 6: 25, 11: 7
waddnstr 6: 25, 11: 7
waddnwstr 6: 25, 11: 7
waddstr 6: 25, 11: 7
wadd_wch 6: 25
waddwch 11: 7
wadd_wchnstr 6: 25
waddwchnstr 11: 7
wadd_wchstr 6: 25
waddwchstr 11: 7
waddwstr 6: 25, 11: 7
wait 6: 8
wait3 6: 9
waitid 6: 8
waitpid 6: 8
wattr_get 6: 25
wattr_off 6: 25
wattroff 6: 25, 11: 7
wattr_on 6: 25
wattron 6: 25, 11: 7
wattr_set 6: 25
wattrset 6: 25, 11: 7
wbkgd 6: 25, 11: 7
wbkgdset 6: 25, 11: 7
wbkgrnd 6: 25
wbkgrndset 6: 25
wborder 6: 25, 11: 7
wborder_set 6: 25
wchgat 6: 25

Index

IN-23

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 253

wclear 6: 25, 11: 7
wclrtobot 6: 25, 11: 7
wclrtoeol 6: 25, 11: 7
wcolor_set 6: 25
wcrtomb 6: 6
wcscat 6: 6
wcschr 6: 6
wcscmp 6: 6
wcscoll 6: 6
wcscpy 6: 6
wcscspn 6: 6
wcsftime 6: 6
wcslen 6: 6
wcsncat 6: 6
wcsncmp 6: 6
wcsncpy 6: 6
wcspbrk 6: 6
wcsrchr 6: 6
wcsrtombs 6: 6
wcsspn 6: 6
wcsstr 6: 6
wcstod 6: 6
wcstof 6: 8
wcstok 6: 6
wcstol 6: 6
wcstold 6: 8
wcstombs 6: 6
wcstoul 6: 6
wcswcs 6: 9
wcswidth 6: 8
wcsxfrm 6: 6
wctob 6: 6
wctomb 6: 6
wctype 6: 6
wcursyncup 6: 25, 11: 7
wcwidth 6: 8
wdelch 6: 25, 11: 7
wdeleteln 6: 25, 11: 7
wechochar 6: 25, 11: 7
wecho_wchar 6: 25
wechowchar 11: 7
werase 6: 25, 11: 7

wgetbkgrnd 6: 25
wgetch 6: 25, 11: 7
wgetnstr 6: 25, 11: 7
wgetn_wstr 6: 25
wgetnwstr 11: 7
wgetstr 6: 25, 11: 7
wget_wch 6: 25
wgetwch 11: 7
wget_wstr 6: 25
wgetwstr 11: 7
whline 6: 25, 11: 7
whline_set 6: 25
widgetClass 6: 37
widgetClassRec 6: 37
winch 6: 25, 11: 7
winchnstr 6: 25, 11: 7
winchstr 6: 25, 11: 7
window manager 10: 4
window system 10: 1
components 10: 3
winnstr 6: 25, 11: 7
winnwstr 6: 25, 11: 7
winsch 6: 25, 11: 7
winsdelln 6: 25, 11: 7
winsertln 6: 25, 11: 7
winsnstr 6: 25, 11: 7
wins_nwstr 6: 25
winsnwstr 11: 7
winsstr 6: 25, 11: 7
winstr 6: 25, 11: 7
wins_wch 6: 25
winswch 11: 7
wins_wstr 6: 25
winswstr 11: 7
win_wch 6: 25
winwch 11: 7
win_wchnstr 6: 25
winwchnstr 11: 7
win_wchstr 6: 25
winwchstr 11: 7
winwstr 6: 25, 11: 7
wmove 6: 25, 11: 7

IN-24

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 254

wmShellClassRec 6: 37
wmShellWidgetClass 6: 37
wnoutrefresh 6: 25, 11: 7
wordexp 6: 8
wordfree 6: 8
wprintf 6: 6
wprintw 6: 25, 11: 7
wredrawln 6: 25, 11: 7
wrefresh 6: 25, 11: 7
write 6: 8
write 6: 21
writev 6: 8
wscanf 6: 6
wscanw 6: 25, 11: 7
wscrl 6: 25, 11: 7
wsetscrreg 6: 25, 11: 7
wstandend 6: 25, 11: 7
wstandout 6: 25, 11: 7
wsyncdown 6: 25, 11: 7
wsyncup 6: 25, 11: 7
wtimeout 6: 25, 11: 7
wtouchln 6: 25, 11: 7
wunctrl 6: 25
wvline 6: 25, 11: 7
wvline_set 6: 25

X
X Toolkit Intrinsics 6: 1, 34
X toolkit intrinsics 10: 3
X Toolkit Intrinsics Library 6: 34
X Window System 1: 2, 6: 1, 26
X Window System Library 1: 5, 6: 26
X11 Nonrectangular Window Shape
Extension 10: 3
interface 10: 1
X11 Nonrectangular Window Shape
Extension Library 6: 33
X11 protocol 10: 2
X11 Toolkit Intrinsics, interface 10: 1
X11 Window System 9: 5

interface 10: 1
overview 10: 2
XActivateScreenSaver 6: 31
XAddExtension 6: 31
XAddHost 6: 31
XAddHosts 6: 31
XAddPixel 6: 31
XAddToExtensionList 6: 31
XAddToSaveSet 6: 31
XAllocClassHint 6: 31
XAllocColor 6: 31
XAllocColorCells 6: 31
XAllocColorPlanes 6: 31
XAllocIconSize 6: 31
XAllocNamedColor 6: 31
XAllocSizeHints 6: 31
XAllocStandardColormap 6: 31
XAllocWMHints 6: 31
XAllowEvents 6: 31
XAllPlanes 6: 31
XAutoRepeatOff 6: 31
XAutoRepeatOn 6: 31
XBaseFontNameListOfFontSet 6: 31
XBell 6: 31
XBitmapBitOrder 6: 31
XBitmapPad 6: 31
XBitmapUnit 6: 31
XBlackPixel 6: 31
XBlackPixelOfScreen 6: 31
XCellsOfScreen 6: 31
XChangeActivePointerGrab 6: 31
XChangeGC 6: 31
XChangeKeyboardControl 6: 31
XChangeKeyboardMapping 6: 31
XChangePointerControl 6: 31
XChangeProperty 6: 31
XChangeSaveSet 6: 31
XChangeWindowAttributes 6: 31
XCheckIfEvent 6: 31
XCheckMaskEvent 6: 31
XCheckTypedEvent 6: 31
XCheckTypedWindowEvent 6: 31

Index

IN-25

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 255

XCheckWindowEvent 6: 31
XCirculateSubwindows 6: 31
XCirculateSubwindowsDown 6: 31
XCirculateSubwindowsUp 6: 31
XClearArea 6: 31
XClearWindow 6: 31
XClipBox 6: 31
XCloseDisplay 6: 31
XCloseIM 6: 31
XcmsAddColorSpace 6: 31
XcmsAddFunctionSet 6: 31
XcmsAllocColor 6: 31
XcmsAllocNamedColor 6: 31
XcmsCCCofColormap 6: 31
XcmsCIELabClipab 6: 31
XcmsCIELabClipL 6: 31
XcmsCIELabClipLab 6: 31
XcmsCIELabColorSpace 6: 32
XcmsCIELabQueryMaxC 6: 31
XcmsCIELabQueryMaxL 6: 31
XcmsCIELabQueryMaxLC 6: 31
XcmsCIELabQueryMinL 6: 31
XcmsCIELabToCIEXYZ 6: 31
XcmsCIELabWhiteShiftColors 6: 31
XcmsCIELuvClipL 6: 31
XcmsCIELuvClipLuv 6: 31
XcmsCIELuvClipuv 6: 31
XcmsCIELuvColorSpace 6: 32
XcmsCIELuvQueryMaxC 6: 31
XcmsCIELuvQueryMaxL 6: 31
XcmsCIELuvQueryMaxLC 6: 31
XcmsCIELuvQueryMinL 6: 31
XcmsCIELuvToCIEuvY 6: 31
XcmsCIELuvWhiteShiftColors 6: 31
XcmsCIEuvYColorSpace 6: 32
XcmsCIEuvYToCIELuv 6: 31
XcmsCIEuvYToCIEXYZ 6: 31
XcmsCIEuvYToTekHVC 6: 31
XcmsCIExyYColorSpace 6: 32
XcmsCIExyYToCIEXYZ 6: 31
XcmsCIEXYZColorSpace 6: 32
XcmsCIEXYZToCIELab 6: 31

XcmsCIEXYZToCIEuvY 6: 31
XcmsCIEXYZToCIExyY 6: 31
XcmsCIEXYZToRGBi 6: 31
XcmsClientWhitePointOfCCC 6: 31
XcmsConvertColors 6: 31
XcmsCreateCCC 6: 31
XcmsDefaultCCC 6: 31
XcmsDisplayOfCCC 6: 31
XcmsFormatOfPrefix 6: 31
XcmsFreeCCC 6: 31
XcmsLinearRGBFunctionSet 6: 32
XcmsLookupColor 6: 31
XcmsPrefixOfFormat 6: 31
XcmsQueryBlack 6: 31
XcmsQueryBlue 6: 31
XcmsQueryColor 6: 31
XcmsQueryColors 6: 31
XcmsQueryGreen 6: 31
XcmsQueryRed 6: 31
XcmsQueryWhite 6: 31
XcmsRGBColorSpace 6: 32
XcmsRGBiColorSpace 6: 32
XcmsRGBiToCIEXYZ 6: 31
XcmsRGBiToRGB 6: 31
XcmsRGBToRGBi 6: 31
XcmsScreenNumberOfCCC 6: 31
XcmsScreenWhitePointOfCCC 6: 31
XcmsSetCompressionProc 6: 31
XcmsSetWhiteAdjustProc 6: 31
XcmsSetWhitePoint 6: 31
XcmsStoreColor 6: 31
XcmsStoreColors 6: 31
XcmsTekHVCCColorSpace 6: 32
XcmsTekHVCClipC 6: 31
XcmsTekHVCClipV 6: 31
XcmsTekHVCClipVC 6: 31
XcmsTekHVCQueryMaxC 6: 31
XcmsTekHVCQueryMaxV 6: 31
XcmsTekHVCQueryMaxVC 6: 31
XcmsTekHVCQueryMaxVSamples
6: 31

XcmsTekHVCQueryMinV

IN-26

6: 31

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 256

XcmsTekHVCToCIEuvY 6: 31
XcmsTekHVCWhiteShiftColors 6: 31
XcmsUNDEFINEDColorSpace 6: 32
XcmsVisualOfCCC 6: 31
XConfigureWindow 6: 31
XConnectionNumber 6: 31
XContextDependentDrawing 6: 31
XConvertSelection 6: 31
XCopyArea 6: 31
XCopyColormapAndFree 6: 31
XCopyGC 6: 31
XCopyPlane 6: 31
XCreateBitmapFromData 6: 31
XCreateColormap 6: 31
XCreateFontCursor 6: 31
XCreateFontSet 6: 31
XCreateGC 6: 31
XCreateGlyphCursor 6: 31
XCreateIC 6: 31
XCreateImage 6: 31
XCreatePixmap 6: 31
XCreatePixmapCursor 6: 31
XCreatePixmapFromBitmapData
6: 31

XCreateRegion 6: 31
XCreateSimpleWindow 6: 31
XCreateWindow 6: 31
XDefaultColormap 6: 31
XDefaultColormapOfScreen 6: 31
XDefaultDepth 6: 31
XDefaultDepthOfScreen 6: 31
XDefaultGC 6: 31
XDefaultGCOfScreen 6: 31
XDefaultRootWindow 6: 31
XDefaultScreen 6: 31
XDefaultScreenOfDisplay 6: 31
XDefaultString 6: 31
XDefaultVisual 6: 31
XDefaultVisualOfScreen 6: 31
XDefineCursor 6: 31
XDeleteContext 6: 31
XDeleteModifiermapEntry 6: 31

XDeleteProperty 6: 31
XDestroyIC 6: 31
XDestroyImage 6: 31
XDestroyRegion 6: 31
XDestroySubwindows 6: 31
XDestroyWindow 6: 31
XDisableAccessControl 6: 31
XDisplayCells 6: 31
XDisplayHeight 6: 31
XDisplayHeightMM 6: 31
XDisplayKeycodes 6: 31
XDisplayMotionBufferSize 6: 31
XDisplayName 6: 31
XDisplayOfIM 6: 31
XDisplayOfScreen 6: 31
XDisplayPlanes 6: 31
XDisplayString 6: 31
XDisplayWidth 6: 31
XDisplayWidthMM 6: 31
XDoesBackingStore 6: 31
XDoesSaveUnders 6: 31
XDR
array, fixed length 7: 16
array, variable length 7: 17
basic block size 7: 10
block size 7: 10
boolean 7: 12
constant 7: 19
data, optional 7: 20
data types 7: 11
discriminated union 7: 18
double-precision floating-point
integer 7: 13
enumeration 7: 12
fixed-length array 7: 16
fixed-length opaque data 7: 14
floating-point integer 7: 12
integer 7: 11
integer, double-precision floating
point 7: 13
integer, floating point 7: 12
integers 7: 36

Index

IN-27

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 257

opaque data, fixed length 7: 14
opaque data, variable length 7: 14
optional data 7: 20
protocol specification 7: 10
string 7: 15
structure 7: 17
typedef 7: 19
union discriminated 7: 18
unsigned integer 7: 11
variable-length array 7: 17
variable-length opaque data 7: 14
void 7: 19
xdr_accepted_reply 6: 20
xdr_array 6: 20
xdr_authsys_parms 6: 20
XDrawArc 6: 31
XDrawArcs 6: 31
XDrawImageString 6: 31
XDrawImageString16 6: 31
XDrawLine 6: 31
XDrawLines 6: 31
XDrawPoint 6: 31
XDrawPoints 6: 31
XDrawRectangle 6: 31
XDrawRectangles 6: 31
XDrawSegments 6: 31
XDrawString 6: 31
XDrawString16 6: 31
XDrawText 6: 31
XDrawText16 6: 31
xdr_bool 6: 20
xdr_bytes 6: 20
xdr_callhdr 6: 20
xdr_callmsg 6: 20
xdr_char 6: 20
xdr_double 6: 20
xdr_enum 6: 20
xdr_float 6: 20
xdr_free 6: 20
xdr_int 6: 20
xdr_long 6: 20
xdrmem_create 6: 20

xdr_opaque 6: 20
xdr_opaque_auth 6: 20
xdr_pointer 6: 20
xdrrec_create 6: 20
xdrrec_endofrecord 6: 20
xdrrec_eof 6: 20
xdrrec_skiprecord 6: 20
xdr_reference 6: 20
xdr_rejected_reply 6: 20
xdr_replymsg 6: 20
xdr_short 6: 20
xdrstdio_create 6: 20
xdr_string 6: 20
xdr_u_char 6: 20
xdr_u_int * 6: 20
xdr_u_long 6: 20
xdr_union 6: 20
xdr_u_short 6: 20
xdr_vector 6: 20
xdr_void 6: 20
xdr_wrapstring 6: 20
XEmptyRegion 6: 31
XEnableAccessControl 6: 31
XEqualRegion 6: 31
XEventMaskOfScreen 6: 31
XEventsQueued 6: 31
XExtentsOfFontSet 6: 31
XFetchBuffer 6: 31
XFetchBytes 6: 31
XFetchName 6: 31
XFillArc 6: 31
XFillArcs 6: 31
XFillPolygon 6: 31
XFillRectangle 6: 31
XFillRectangles 6: 31
XFilterEvent 6: 31
XFindContext 6: 31
XFindOnExtensionList 6: 31
XFlush 6: 31
XFlushGC 6: 31
XFontsOfFontSet 6: 31
XForceScreenSaver 6: 31

IN-28

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 258

XFree 6: 31
XFreeColormap 6: 31
XFreeColors 6: 31
XFreeCursor 6: 31
XFreeExtensionList 6: 31
XFreeFont 6: 31
XFreeFontInfo 6: 31
XFreeFontNames 6: 31
XFreeFontPath 6: 31
XFreeFontSet 6: 31
XFreeGC 6: 31
XFreeModifiermap 6: 31
XFreePixmap 6: 31
XFreeStringList 6: 31_xftw 6: 9–10
XGContextFromGC 6: 31
XGeometry 6: 31
XGetAtomName 6: 31
XGetClassHint 6: 31
XGetCommand 6: 31
XGetDefault 6: 31
XGetErrorDatabaseText 6: 31
XGetErrorText 6: 31
XGetFontPath 6: 31
XGetFontProperty 6: 31
XGetGCValues 6: 31
XGetGeometry 6: 31
XGetIconName 6: 31
XGetIconSizes 6: 31
XGetICValues 6: 31
XGetImage 6: 31
XGetIMValues 6: 31
XGetInputFocus 6: 31
XGetKeyboardControl 6: 31
XGetKeyboardMapping 6: 31
XGetModifierMapping 6: 31
XGetMotionEvents 6: 31
XGetNormalHints 6: 31
XGetPixel 6: 31
XGetPointerControl 6: 31
XGetPointerMapping 6: 31
XGetRGBColormaps 6: 31

XGetScreenSaver 6: 31
XGetSelectionOwner 6: 31
XGetSizeHints 6: 31
XGetStandardColormap 6: 31
XGetSubImage 6: 31
XGetTextProperty 6: 31
XGetTransientForHint 6: 31
XGetVisualInfo 6: 31
XGetWindowAttributes 6: 31
XGetWindowProperty 6: 31
XGetWMClientMachine 6: 31
XGetWMColormapWindows 6: 31
XGetWMHints 6: 31
XGetWMIconName 6: 31
XGetWMName 6: 31
XGetWMNormalHints 6: 31
XGetWMProtocols 6: 31
XGetWMSizeHints 6: 31
XGrabButton 6: 31
XGrabKey 6: 31
XGrabKeyboard 6: 31
XGrabPointer 6: 31
XGrabServer 6: 31
XHeightMMOfScreen 6: 31
XHeightOfScreen 6: 31
XIconifyWindow 6: 31
XIfEvent 6: 31
XImageByteOrder 6: 31
XIMOfIC 6: 31
XInitExtension 6: 31
XInsertModifiermapEntry 6: 31
XInstallColormap 6: 31
XInternAtom 6: 31
XIntersectRegion 6: 31
XKeycodeToKeysym 6: 31
XKeysymToKeycode 6: 31
XKeysymToString 6: 31
XKillClient 6: 31
XLastKnownRequestProcessed 6: 31
XListDepths 6: 31
XListExtensions 6: 31
XListFonts 6: 31

Index

IN-29

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 259

XListFontsWithInfo 6: 31
XListHosts 6: 31
XListInstalledColormaps 6: 31
XListPixmapFormats 6: 31
XListProperties 6: 31
XLoadFont 6: 31
XLoadQueryFont 6: 31
XLocaleOfFontSet 6: 31
XLocaleOfIM 6: 31
XLookupColor 6: 31
XLookupKeysym 6: 31
XLookupString 6: 31
XLowerWindow 6: 31
XmActivateProtocol 6: 43
XmAddProtocolCallback 6: 43
XmAddProtocols 6: 43
XmAddTabGroup 6: 43
XMapRaised 6: 31
XMapSubwindows 6: 31
XMapWindow 6: 31
xmArrowButtonClassRec 6: 45
xmArrowButtonGadgetClass 6: 45
xmArrowButtonGadgetClassRec
6: 45

xmArrowButtonWidgetClass 6: 45
XMaskEvent 6: 31
XMatchVisualInfo 6: 31
XMaxCmapsOfScreen 6: 31
XMaxRequestSize 6: 31
XmbDrawImageString 6: 31
XmbDrawString 6: 31
XmbDrawText 6: 31
XmbLookupString 6: 31
XmbResetIC 6: 31
XmbSetWMProperties 6: 31
XmbTextEscapement 6: 31
XmbTextExtents 6: 31
XmbTextListToTextProperty 6: 31
XmbTextPerCharExtents 6: 31
XmbTextPropertyToTextList 6: 31
xmBulletinBoardClassRec 6: 45
xmBulletinBoardWidgetClass 6: 45

xmCascadeButtonClassRec 6: 45
xmCascadeButtonGadgetClass 6: 45
xmCascadeButtonGadgetClassRec
6: 45

XmCascadeButtonGadgetHighlight
6: 43

xmCascadeButtonGCacheObjClassRec 6: 45
XmCascadeButtonHighlight 6: 43
xmCascadeButtonWidgetClass 6: 45
XmChangeColor 6: 43
XmClipboardCancelCopy 6: 43
XmClipboardCopy 6: 43
XmClipboardCopyByName 6: 43
XmClipboardEndCopy 6: 43
XmClipboardEndRetrieve 6: 43
XmClipboardInquireCount 6: 43
XmClipboardInquireFormat 6: 43
XmClipboardInquireLength 6: 43
XmClipboardInquirePendingItems
6: 43

XmClipboardLock 6: 43
XmClipboardRegisterFormat 6: 43
XmClipboardRetrieve 6: 43
XmClipboardStartCopy 6: 43
XmClipboardStartRetrieve 6: 43
XmClipboardUndoCopy 6: 43
XmClipboardUnlock 6: 43
XmClipboardWithdrawFormat 6: 43
XmCommandAppendValue 6: 43
xmCommandClassRec 6: 45
XmCommandError 6: 43
XmCommandGetChild 6: 43
XmCommandSetValue 6: 43
xmCommandWidgetClass 6: 45
XmConvertUnits 6: 43
XmCreateArrowButton 6: 43
XmCreateArrowButtonGadget 6: 43
XmCreateBulletinBoard 6: 43
XmCreateBulletinBoardDialog 6: 43
XmCreateCascadeButton 6: 43
XmCreateCascadeButtonGadget 6: 43

IN-30

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 260

XmCreateCommand 6: 43
XmCreateDialogShell 6: 43
XmCreateDragIcon 6: 43
XmCreateDrawingArea 6: 43
XmCreateDrawnButton 6: 43
XmCreateErrorDialog 6: 43
XmCreateFileSelectionBox 6: 43
XmCreateFileSelectionDialog 6: 43
XmCreateForm 6: 43
XmCreateFormDialog 6: 43
XmCreateFrame 6: 43
XmCreateInformationDialog 6: 43
XmCreateLabel 6: 43
XmCreateLabelGadget 6: 43
XmCreateList 6: 43
XmCreateMainWindow 6: 43
XmCreateMenuBar 6: 43
XmCreateMenuShell 6: 43
XmCreateMessageBox 6: 43
XmCreateMessageDialog 6: 43
XmCreateOptionMenu 6: 43
XmCreatePanedWindow 6: 43
XmCreatePopupMenu 6: 43
XmCreatePromptDialog 6: 43
XmCreatePulldownMenu 6: 43
XmCreatePushButton 6: 43
XmCreatePushButtonGadget 6: 43
XmCreateQuestionDialog 6: 43
XmCreateRadioBox 6: 43
XmCreateRowColumn 6: 43
XmCreateScale 6: 43
XmCreateScrollBar 6: 43
XmCreateScrolledList 6: 43
XmCreateScrolledText 6: 43
XmCreateScrolledWindow 6: 43
XmCreateSelectionBox 6: 43
XmCreateSelectionDialog 6: 43
XmCreateSeparator 6: 43
XmCreateSeparatorGadget 6: 43
XmCreateSimpleCheckBox 6: 43
XmCreateSimpleMenuBar 6: 43
XmCreateSimpleOptionMenu 6: 43

XmCreateSimplePopupMenu 6: 43
XmCreateSimplePulldownMenu 6: 43
XmCreateSimpleRadioBox 6: 43
XmCreateTemplateDialog 6: 43
XmCreateText 6: 43
XmCreateTextField 6: 43
XmCreateToggleButton 6: 43
XmCreateToggleButtonGadget 6: 43
XmCreateWarningDialog 6: 43
XmCreateWorkArea 6: 43
XmCreateWorkingDialog 6: 43
XmCvtCTToXmString 6: 43
XmCvtStringToUnitType 6: 43
XmCvtXmStringToCT 6: 43
XmDeactivateProtocol 6: 43
xmDesktopClass 6: 45
xmDesktopClassRec 6: 45
XmDestroyPixmap 6: 43
xmDialogShellClassRec 6: 45
xmDialogShellExtClassRec 6: 45
xmDialogShellExtObjectClass
6: 45

xmDialogShellWidgetClass 6: 45
xmDisplayClass 6: 45
xmDisplayClassRec 6: 45
XmDragCancel 6: 43
xmDragContextClass 6: 45
xmDragContextClassRec 6: 45
xmDragIconClassRec 6: 45
xmDragIconObjectClass 6: 45
xmDragOverShellClassRec 6: 45
xmDragOverShellWidgetClass 6: 45
XmDragStart 6: 43
xmDrawingAreaClassRec 6: 45
xmDrawingAreaWidgetClass 6: 45
xmDrawnButtonClassRec 6: 45
xmDrawnButtonWidgetClass 6: 45
XmDropSiteConfigureStackingOrder
6: 43

XmDropSiteEndUpdate 6: 43
xmDropSiteManagerClassRec 6: 45
xmDropSiteManagerObjectClass
6: 45

Index

IN-31

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 261

XmDropSiteQueryStackingOrder
6: 43

XmDropSiteRegister 6: 43
XmDropSiteRetrieve 6: 43
XmDropSiteStartUpdate 6: 43
XmDropSiteUnregister 6: 43
XmDropSiteUpdate 6: 43
XmDropTransferAdd 6: 43
xmDropTransferClassRec 6: 45
xmDropTransferObjectClass 6: 45
XmDropTransferStart 6: 43
xmExtClassRec 6: 45
xmExtObjectClass 6: 45
xmFileSelectionBoxClassRec 6: 45
XmFileSelectionBoxGetChild 6: 43
xmFileSelectionBoxWidgetClass
6: 45

XmFileSelectionDoSearch 6: 43
XmFontListAdd 6: 43
XmFontListAppendEntry 6: 43
XmFontListCopy 6: 43
XmFontListCreate 6: 43
XmFontListEntryCreate 6: 43
XmFontListEntryFree 6: 43
XmFontListEntryGetFont 6: 43
XmFontListEntryGetTag 6: 43
XmFontListEntryLoad 6: 43
XmFontListFree 6: 43
XmFontListFreeFontContext 6: 43
XmFontListGetNextFont 6: 43
XmFontListInitFontContext 6: 43
XmFontListNextEntry 6: 43
XmFontListRemoveEntry 6: 43
xmFormClassRec 6: 45
xmFormWidgetClass 6: 45
xmFrameClassRec 6: 45
xmFrameWidgetClass 6: 45
xmGadgetClass 6: 45
xmGadgetClassRec 6: 45
XmGetAtomName 6: 43
XmGetColorCalculation 6: 43
XmGetColors 6: 43

XmGetDestination 6: 43
XmGetDragContext 6: 43
XmGetFocusWidget 6: 43
XmGetMenuCursor 6: 43
XmGetPixmap 6: 43
XmGetPixmapByDepth 6: 43
XmGetPostedFromWidget 6: 43
XmGetSecondaryResourceData 6: 43
XmGetTabGroup 6: 43
XmGetTearOffControl 6: 43
XmGetVisibility 6: 43
XmGetXmDisplay 6: 43
XmGetXmScreen 6: 43
XMinCmapsOfScreen 6: 31
XmInstallImage 6: 43
XmInternAtom 6: 43
XmIsMotifWMRunning 6: 43
XmIsTraversable 6: 43
xmLabelClassRec 6: 45
xmLabelGadgetClass 6: 45
xmLabelGadgetClassRec 6: 45
xmLabelGCacheObjClassRec 6: 45
xmLabelWidgetClass 6: 45
XmListAddItem 6: 43
XmListAddItems 6: 43
XmListAddItemsUnselected 6: 43
XmListAddItemUnselected 6: 43
xmListClassRec 6: 45
XmListDeleteAllItems 6: 43
XmListDeleteItem 6: 43
XmListDeleteItems 6: 43
XmListDeleteItemsPos 6: 43
XmListDeletePos 6: 43
XmListDeletePositions 6: 43
XmListDeselectAllItems 6: 43
XmListDeselectItem 6: 43
XmListDeselectPos 6: 43
XmListGetKbdItemPos 6: 43
XmListGetMatchPos 6: 43
XmListGetSelectedPos 6: 43
XmListItemExists 6: 43
XmListItemPos 6: 43

IN-32

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 262

XmListPosSelected 6: 43
XmListPosToBounds 6: 43
XmListReplaceItems 6: 43
XmListReplaceItemsPos 6: 43
XmListReplaceItemsPosUnselected
6: 43

XmListReplaceItemsUnselected 6: 43
XmListReplacePositions 6: 43
XmListSelectItem 6: 43
XmListSelectPos 6: 43
XmListSetAddMode 6: 43
XmListSetBottomItem 6: 43
XmListSetBottomPos 6: 43
XmListSetHorizPos 6: 43
XmListSetItem 6: 43
XmListSetKbdItemPos 6: 43
XmListSetPos 6: 43
XmListUpdateSelectedList 6: 43
xmListWidgetClass 6: 45
XmListYToPos 6: 43
xmMainWindowClassRec 6: 45
XmMainWindowSep1 6: 43
XmMainWindowSep2 6: 43
XmMainWindowSep3 6: 43
XmMainWindowSetAreas 6: 43
xmMainWindowWidgetClass 6: 45
xmManagerClassRec 6: 45
xmManagerWidgetClass 6: 45
XmMapSegmentEncoding 6: 43
XmMenuPosition 6: 43
xmMenuShellClassRec 6: 45
xmMenuShellWidgetClass 6: 45
xmMessageBoxClassRec 6: 45
XmMessageBoxGetChild 6: 43
xmMessageBoxWidgetClass 6: 45
XmOptionButtonGadget 6: 43
XmOptionLabelGadget 6: 43
XMoveResizeWindow 6: 31
XMoveWindow 6: 31
xmPanedWindowClassRec 6: 45
xmPanedWindowWidgetClass 6: 45
xmPrimitiveClassRec 6: 45

xmPrimitiveWidgetClass 6: 45
XmProcessTraversal 6: 43
xmProtocolClassRec 6: 45
xmProtocolObjectClass 6: 45
xmPushButtonClassRec 6: 45
xmPushButtonGadgetClass 6: 45
xmPushButtonGadgetClassRec 6: 45
xmPushButtonGCacheObjClassRec
6: 45

xmPushButtonWidgetClass 6: 45
XmQmotif 6: 45
XmRegisterSegmentEncoding 6: 43
XmRemoveProtocolCallback 6: 43
XmRemoveProtocols 6: 43
XmRemoveTabGroup 6: 43
XmRepTypeAddReverse 6: 43
XmRepTypeGetId 6: 43
XmRepTypeGetNameList 6: 43
XmRepTypeGetRecord 6: 43
XmRepTypeGetRegistered 6: 43
XmRepTypeInstallTearOffModelConverter 6: 43
XmRepTypeRegister 6: 43
XmRepTypeValidValue 6: 43
XmResolveAllPartOffsets 6: 43
XmResolvePartOffsets 6: 43
xmRowColumnClassRec 6: 45
xmRowColumnWidgetClass 6: 45
xmSashClassRec 6: 45
xmSashWidgetClass 6: 45
xmScaleClassRec 6: 45
XmScaleGetValue 6: 43
XmScaleSetValue 6: 43
xmScaleWidgetClass 6: 45
xmScreenClass 6: 45
xmScreenClassRec 6: 45
xmScrollBarClassRec 6: 45
XmScrollBarGetValues 6: 43
XmScrollBarSetValues 6: 43
xmScrollBarWidgetClass 6: 45
xmScrolledWindowClassRec 6: 45
XmScrolledWindowSetAreas 6: 43

Index

IN-33

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 263

xmScrolledWindowWidgetClass
6: 45

XmScrollVisible 6: 43
xmSelectionBoxClassRec 6: 45
XmSelectionBoxGetChild 6: 43
xmSelectionBoxWidgetClass 6: 45
xmSeparatorClassRec 6: 45
xmSeparatorGadgetClass 6: 45
xmSeparatorGadgetClassRec 6: 45
xmSeparatorGCacheObjClassRec
6: 45

xmSeparatorWidgetClass 6: 45
XmSetColorCalculation 6: 43
XmSetFontUnit 6: 43
XmSetFontUnits 6: 43
XmSetMenuCursor 6: 43
XmSetProtocolHooks 6: 43
xmShellExtClassRec 6: 45
xmShellExtObjectClass 6: 45
XmStringBaseline 6: 43
XmStringByteCompare 6: 43
XmStringCompare 6: 43
XmStringConcat 6: 43
XmStringCopy 6: 43
XmStringCreate 6: 43
XmStringCreateLocalized 6: 43
XmStringCreateLtoR 6: 43
XmStringCreateSimple 6: 43
XmStringDirectionCreate 6: 43
XmStringDraw 6: 43
XmStringDrawImage 6: 43
XmStringDrawUnderline 6: 43
XmStringEmpty 6: 43
XmStringExtent 6: 43
XmStringFree 6: 43
XmStringFreeContext 6: 43
XmStringGetLtoR 6: 43
XmStringGetNextComponent 6: 43
XmStringGetNextSegment 6: 43
XmStringHasSubstring 6: 43
XmStringHeight 6: 43
XmStringInitContext 6: 43

XmStringLength 6: 43
XmStringLineCount 6: 43
XmStringNConcat 6: 43
XmStringNCopy 6: 43
XmStringPeekNextComponent 6: 43
XmStringSegmentCreate 6: 43
XmStringSeparatorCreate 6: 43
XmStringWidth 6: 43
XmTargetsAreCompatible 6: 43
xmTearOffButtonClassRec 6: 45
xmTearOffButtonWidgetClass 6: 45
xmTextClassRec 6: 45
XmTextClearSelection 6: 43
XmTextCopy 6: 43
XmTextCut 6: 43
XmTextDisableRedisplay 6: 43
XmTextEnableRedisplay 6: 43
xmTextFieldClassRec 6: 45
XmTextFieldClearSelection 6: 43
XmTextFieldCopy 6: 43
XmTextFieldCut 6: 43
XmTextFieldGetBaseline 6: 43
XmTextFieldGetEditable 6: 43
XmTextFieldGetInsertionPosition
6: 43

XmTextFieldGetLastPosition 6: 43
XmTextFieldGetMaxLength 6: 43
XmTextFieldGetSelection 6: 43
XmTextFieldGetSelectionPosition
6: 43

XmTextFieldGetSelectionWcs 6: 43
XmTextFieldGetString 6: 43
XmTextFieldGetStringWcs 6: 43
XmTextFieldGetSubstring 6: 43
XmTextFieldGetSubstringWcs 6: 43
XmTextFieldInsert 6: 43
XmTextFieldInsertWcs 6: 43
XmTextFieldPaste 6: 43
XmTextFieldPosToXY 6: 43
XmTextFieldRemove 6: 43
XmTextFieldReplace 6: 43
XmTextFieldReplaceWcs 6: 43

IN-34

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 264

XmTextFieldSetAddMode 6: 43
XmTextFieldSetEditable 6: 43
XmTextFieldSetHighlight 6: 43
XmTextFieldSetInsertionPosition
6: 43

XmTextFieldSetMaxLength 6: 43
XmTextFieldSetSelection 6: 43
XmTextFieldSetString 6: 43
XmTextFieldSetStringWcs 6: 43
XmTextFieldShowPosition 6: 43
xmTextFieldWidgetClass 6: 45
XmTextFieldXYToPos 6: 43
XmTextFindString 6: 43
XmTextFindStringWcs 6: 43
XmTextGetBaseLine 6: 43
XmTextGetBaseline 6: 43
XmTextGetEditable 6: 43
XmTextGetInsertionPosition 6: 43
XmTextGetLastPosition 6: 43
XmTextGetMaxLength 6: 43
XmTextGetSelection 6: 43
XmTextGetSelectionPosition 6: 43
XmTextGetSelectionWcs 6: 43
XmTextGetSource 6: 43
XmTextGetString 6: 43
XmTextGetStringWcs 6: 43
XmTextGetSubstring 6: 43
XmTextGetSubstringWcs 6: 43
XmTextGetTopCharacter 6: 43
XmTextInsert 6: 43
XmTextInsertWcs 6: 43
XmTextPaste 6: 43
XmTextPosToXY 6: 43
XmTextRemove 6: 43
XmTextReplace 6: 43
XmTextReplaceWcs 6: 43
XmTextScroll 6: 43
XmTextSetAddMode 6: 43
XmTextSetEditable 6: 43
XmTextSetHighlight 6: 43
XmTextSetInsertionPosition 6: 43
XmTextSetMaxLength 6: 43

XmTextSetSelection 6: 43
XmTextSetSource 6: 43
XmTextSetString 6: 43
XmTextSetStringWcs 6: 43
XmTextSetTopCharacter 6: 43
XmTextShowPosition 6: 43
xmTextWidgetClass 6: 45
XmTextXYToPos 6: 43
xmToggleButtonClassRec 6: 45
xmToggleButtonGadgetClass 6: 45
xmToggleButtonGadgetClassRec
6: 45

XmToggleButtonGadgetGetState
6: 43

XmToggleButtonGadgetSetState 6: 43
xmToggleButtonGCacheObjClassRec 6: 45
XmToggleButtonGetState 6: 43
XmToggleButtonSetState 6: 43
xmToggleButtonWidgetClass 6: 45
XmTrackingEvent 6: 43
XmTrackingLocate 6: 43
XmTranslateKey 6: 43
XmUninstallImage 6: 43
XmUpdateDisplay 6: 43
xmUseVersion 6: 45
XmVaCreateSimpleCheckBox 6: 43
XmVaCreateSimpleMenuBar 6: 43
XmVaCreateSimpleOptionMenu 6: 43
XmVaCreateSimplePopupMenu 6: 43
XmVaCreateSimplePulldownMenu
6: 43

XmVaCreateSimpleRadioBox 6: 43
xmVendorShellExtClassRec 6: 45
xmVendorShellExtObjectClass
6: 45

XmWidgetGetBaselines 6: 43
XmWidgetGetDisplayRect 6: 43
xmWorldClass 6: 45
xmWorldClassRec 6: 45
XNewModifiermap 6: 31
XNextEvent 6: 31

Index

IN-35

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 265

XNextRequest 6: 31
XNoOp 6: 31
XOffsetRegion 6: 31
X/Open Common Application
Environment Specification, Issue
4.2 1: 1
X/Open Common Application
Environment Specification (CAE),
Issue 4.2 1: 2
X/Open Portability Guide 7: 22
XOpenDisplay 6: 31
XOpenIM 6: 31
XParseColor 6: 31
XParseGeometry 6: 31
XPeekEvent 6: 31
XPeekIfEvent 6: 31
XPending 6: 31
Xpermalloc 6: 31
XPG3 7: 22_ _xpg4 6: 12
XPlanesOfScreen 6: 31
XPointInRegion 6: 31
XPolygonRegion 6: 31
XProtocolRevision 6: 31
XProtocolVersion 6: 31
xprt_register 6: 20
xprt_unregister 6: 20
XPutBackEvent 6: 31
XPutImage 6: 31
XPutPixel 6: 31
XQLength 6: 31
XQueryBestCursor 6: 31
XQueryBestSize 6: 31
XQueryBestStipple 6: 31
XQueryBestTile 6: 31
XQueryColor 6: 31
XQueryColors 6: 31
XQueryExtension 6: 31
XQueryFont 6: 31
XQueryKeymap 6: 31
XQueryPointer 6: 31
XQueryTextExtents 6: 31

XQueryTextExtents16 6: 31
XQueryTree 6: 31
XRaiseWindow 6: 31
XReadBitmapFile 6: 31
XRebindKeysym 6: 31
XRecolorCursor 6: 31
XReconfigureWMWindow 6: 31
XRectInRegion 6: 31
XRefreshKeyboardMapping 6: 31
XRemoveFromSaveSet 6: 31
XRemoveHost 6: 31
XRemoveHosts 6: 31
XReparentWindow 6: 31
XResetScreenSaver 6: 31
XResizeWindow 6: 31
XResourceManagerString 6: 31
XRestackWindows 6: 31
XrmCombineDatabase 6: 31
XrmCombineFileDatabase 6: 31
XrmDestroyDatabase 6: 31
XrmEnumerateDatabase 6: 31
XrmGetDatabase 6: 31
XrmGetFileDatabase 6: 31
XrmGetResource 6: 31
XrmGetStringDatabase 6: 31
XrmInitialize 6: 31
XrmLocaleOfDatabase 6: 31
XrmMergeDatabases 6: 31
XrmParseCommand 6: 31
XrmPermStringToQuark 6: 31
XrmPutFileDatabase 6: 31
XrmPutLineResource 6: 31
XrmPutResource 6: 31
XrmPutStringResource 6: 31
XrmQGetResource 6: 31
XrmQGetSearchList 6: 31
XrmQGetSearchResource 6: 31
XrmQPutResource 6: 31
XrmQPutStringResource 6: 31
XrmQuarkToString 6: 31
XrmSetDatabase 6: 31
XrmStringToBindingQuarkList 6: 31

IN-36

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 266

XrmStringToQuark 6: 31
XrmStringToQuarkList 6: 31
XrmUniqueQuark 6: 31
XRootWindow 6: 31
XRootWindowOfScreen 6: 31
XRotateBuffers 6: 31
XRotateWindowProperties 6: 31
XSaveContext 6: 31
XScreenCount 6: 31
XScreenNumberOfScreen 6: 31
XScreenOfDisplay 6: 31
XScreenResourceString 6: 31
XSelectInput 6: 31
XSendEvent 6: 31
XServerVendor 6: 31
XSetAccessControl 6: 31
XSetAfterFunction 6: 31
XSetArcMode 6: 31
XSetBackground 6: 31
XSetClassHint 6: 31
XSetClipMask 6: 31
XSetClipOrigin 6: 31
XSetClipRectangles 6: 31
XSetCloseDownMode 6: 31
XSetCommand 6: 31
XSetDashes 6: 31
XSetErrorHandler 6: 31
XSetFillRule 6: 31
XSetFillStyle 6: 31
XSetFont 6: 31
XSetFontPath 6: 31
XSetForeground 6: 31
XSetFunction 6: 31
XSetGraphicsExposures 6: 31
XSetICFocus 6: 31
XSetIconName 6: 31
XSetIconSizes 6: 31
XSetICValues 6: 31
XSetInputFocus 6: 31
XSetIOErrorHandler 6: 31
XSetLineAttributes 6: 31
XSetLocaleModifiers 6: 31

XSetModifierMapping 6: 31
XSetNormalHints 6: 31
XSetPlaneMask 6: 31
XSetPointerMapping 6: 31
XSetRegion 6: 31
XSetRGBColormaps 6: 31
XSetScreenSaver 6: 31
XSetSelectionOwner 6: 31
XSetSizeHints 6: 31
XSetStandardColormap 6: 31
XSetStandardProperties 6: 31
XSetState 6: 31
XSetStipple 6: 31
XSetSubwindowMode 6: 31
XSetTextProperty 6: 31
XSetTile 6: 31
XSetTransientForHint 6: 31
XSetTSOrigin 6: 31
XSetWindowBackground 6: 31
XSetWindowBackgroundPixmap
6: 31

XSetWindowBorder 6: 31
XSetWindowBorderPixmap 6: 31
XSetWindowBorderWidth 6: 31
XSetWindowColormap 6: 31
XSetWMClientMachine 6: 31
XSetWMColormapWindows 6: 31
XSetWMHints 6: 31
XSetWMIconName 6: 31
XSetWMName 6: 31
XSetWMNormalHints 6: 31
XSetWMProperties 6: 31
XSetWMProtocols 6: 31
XSetWMSizeHints 6: 31
XShapeCombineMask 6: 33
XShapeCombineRectangles 6: 33
XShapeCombineRegion 6: 33
XShapeCombineShape 6: 33
XShapeGetRectangles 6: 33
XShapeInputSelected 6: 33
XShapeOffsetShape 6: 33
XShapeQueryExtension 6: 33

Index

IN-37

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 267

XShapeQueryExtents 6: 33
XShapeQueryVersion 6: 33
XShapeSelectInput 6: 33
XShrinkRegion 6: 31
XStoreBuffer 6: 31
XStoreBytes 6: 31
XStoreColor 6: 31
XStoreColors 6: 31
XStoreName 6: 31
XStoreNamedColor 6: 31
XStringListToTextProperty 6: 31
XStringToKeysym 6: 31
XSubImage 6: 31
XSubtractRegion 6: 31
XSupportsLocale 6: 31
XSync 6: 31
XSynchronize 6: 31
XtAddCallback 6: 36
XtAddCallbacks 6: 36
XtAddEventHandler 6: 36
XtAddExposureToRegion 6: 36
XtAddGrab 6: 36
XtAddRawEventHandler 6: 36
XtAllocateGC 6: 36
XtAppAddActionHook 6: 36
XtAppAddActions 6: 36
XtAppAddInput 6: 36
XtAppAddTimeOut 6: 36
XtAppAddWorkProc 6: 36
XtAppCreateShell 6: 36
XtAppError 6: 36
XtAppErrorMsg 6: 36
XtAppGetErrorDatabase 6: 36
XtAppGetErrorDatabaseText 6: 36
XtAppGetSelectionTimeout 6: 36
XtAppInitialize 6: 36
XtAppMainLoop 6: 36
XtAppNextEvent 6: 36
XtAppPeekEvent 6: 36
XtAppPending 6: 36
XtAppProcessEvent 6: 36
XtAppReleaseCacheRefs 6: 36

XtAppSetErrorHandler 6: 36
XtAppSetErrorMsgHandler 6: 36
XtAppSetFallbackResources 6: 36
XtAppSetSelectionTimeout 6: 36
XtAppSetTypeConverter 6: 36
XtAppSetWarningHandler 6: 36
XtAppSetWarningMsgHandler 6: 36
XtAppWarning 6: 36
XtAppWarningMsg 6: 36
XtAugmentTranslations 6: 36
XtBuildEventMask 6: 36
XtCallAcceptFocus 6: 36
XtCallActionProc 6: 36
XtCallbackExclusive 6: 36
XtCallbackNone 6: 36
XtCallbackNonexclusive 6: 36
XtCallbackPopdown 6: 36
XtCallbackReleaseCacheRef 6: 36
XtCallbackReleaseCacheRefList 6: 36
XtCallCallbackList 6: 36
XtCallCallbacks 6: 36
XtCallConverter 6: 36
XtCalloc 6: 36
XtClass 6: 36
XtCloseDisplay 6: 36
XtConfigureWidget 6: 36
XtConvertAndStore 6: 36
XtConvertCase 6: 36
XtCreateApplicationContext 6: 36
XtCreateManagedWidget 6: 36
XtCreatePopupShell 6: 36
XtCreateWidget 6: 36
XtCreateWindow 6: 36
XtCvtColorToPixel 6: 36
XtCvtIntToBool 6: 36
XtCvtIntToBoolean 6: 36
XtCvtIntToColor 6: 36
XtCvtIntToFloat 6: 36
XtCvtIntToFont 6: 36
XtCvtIntToPixel 6: 36
XtCvtIntToPixmap 6: 36
XtCvtIntToShort 6: 36

IN-38

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 268

XtCvtIntToUnsignedChar 6: 36
XtCvtStringToAcceleratorTable 6: 36
XtCvtStringToAtom 6: 36
XtCvtStringToBool 6: 36
XtCvtStringToBoolean 6: 36
XtCvtStringToCursor 6: 36
XtCvtStringToDimension 6: 36
XtCvtStringToDisplay 6: 36
XtCvtStringToFile 6: 36
XtCvtStringToFloat 6: 36
XtCvtStringToFont 6: 36
XtCvtStringToFontSet 6: 36
XtCvtStringToFontStruct 6: 36
XtCvtStringToInitialState 6: 36
XtCvtStringToInt 6: 36
XtCvtStringToPixel 6: 36
XtCvtStringToShort 6: 36
XtCvtStringToTranslationTable 6: 36
XtCvtStringToUnsignedChar 6: 36
XtCvtStringToVisual 6: 36
XtDatabase 6: 36
XtDestroyApplicationContext 6: 36
XtDestroyWidget 6: 36
XtDisownSelection 6: 36
XtDispatchEvent 6: 36
XtDisplay 6: 36
XtDisplayInitialize 6: 36
XtDisplayOfObject 6: 36
XtDisplayStringConversionWarning

XtGetApplicationResources 6: 36
XtGetConstraintResourceList 6: 36
XtGetGC 6: 36
XtGetKeysymTable 6: 36
XtGetMultiClickTime 6: 36
XtGetResourceList 6: 36
XtGetSelectionRequest 6: 36
XtGetSelectionValue 6: 36
XtGetSelectionValueIncremental 6: 36
XtGetSelectionValues 6: 36
XtGetSelectionValuesIncremental
6: 36

6: 36

XtDisplayToApplicationContext 6: 36
XTextExtents 6: 31
XTextExtents16 6: 31
XTextPropertyToStringList 6: 31
XTextWidth 6: 31
XTextWidth16 6: 31
XtFindFile 6: 36
XtFree 6: 36
XtGetActionKeysym 6: 36
XtGetActionList 6: 36
XtGetApplicationNameAndClass
6: 36

XtGetSubresources 6: 36
XtGetSubvalues 6: 36
XtGetValues 6: 36
XtGrabButton 6: 36
XtGrabKey 6: 36
XtGrabKeyboard 6: 36
XtGrapPointer 6: 36
XtHasCallbacks 6: 36
XTI 12: 4_xti_accept 6: 19_xti_alloc 6: 19_xti_bind 6: 19_xti_close 6: 19_xti_connect 6: 19_xti_error 6: 19_xti_free 6: 19_xti_getinfo 6: 19_xti_getprotaddr 6: 19_xti_getstate 6: 19_xti_listen 6: 19_xti_look 6: 19
XtInitializeWidgetClass 6: 36
XtInsertEventHandler 6: 36
XtInsertRawEventHandler 6: 36
XtInstallAccelerators 6: 36
XtInstallAllAccelerators 6: 36_xti_open 6: 19_xti_rcv 6: 19_xti_rcvconnect 6: 19_xti_rcvdis 6: 19

Index

IN-39

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 269

_xti_rcvrel 6: 19_xti_rcvudata 6: 19_xti_rcvuderr 6: 19
XtIsApplicationsShell 6: 36
XtIsComposite 6: 36
XtIsConstraint 6: 36
XtIsManaged 6: 36_xti_snd 6: 19_xti_snddis 6: 19_xti_sndrel 6: 19_xti_sndudata 6: 19
XtIsObject 6: 36
XtIsOverrideShell 6: 36
XtIsRealized 6: 36
XtIsRectObj 6: 36
XtIsSensitive 6: 36
XtIsShell 6: 36
XtIsSubclass 6: 36
XtIsTopLevelShell 6: 36
XtIsTransientShell 6: 36_xti_strerror 6: 19
XtIsVendorShell 6: 36
XtIsWidget 6: 36
XtIsWMShell 6: 36_xti_sync 6: 19_xti_unbind 6: 19
XtKeysymToKeycodeList 6: 36
XtLastTimestampProcessed 6: 36
XtMakeGeometryRequest 6: 36
XtMakeResizeRequest 6: 36
XtMalloc 6: 36
XtManageChild 6: 36
XtManageChildren 6: 36
XtMapWidget 6: 36
XtMenuPopupAction 6: 36
XtMergeArgLists 6: 36
XtMoveWidget 6: 36
XtName 6: 36
XtNameToWidget 6: 36
XtOpenDisplay 6: 36
XtOverrideTranslations 6: 36
XtOwnSelection 6: 36

XtOwnSelectionIncremental 6: 36
XtParent 6: 36
XtParseAcceleratorTable 6: 36
XtParseTranslationTable 6: 36
XtPopdown 6: 36
XtPopup 6: 36
XtPopupSpringLoaded 6: 36
XtQueryGeometry 6: 36
XTranslateCoordinates 6: 31
XtRealizeWidget 6: 36
XtRealloc 6: 36
XtRegisterCaseConverter 6: 36
XtRegisterGrabAction 6: 36
XtReleaseGC 6: 36
XtRemoveActionHook 6: 36
XtRemoveAllCallbacks 6: 36
XtRemoveCallback 6: 36
XtRemoveCallbacks 6: 36
XtRemoveEventHandler 6: 36
XtRemoveGrab 6: 36
XtRemoveInput 6: 36
XtRemoveRawEventHandler 6: 36
XtRemoveTimeOut 6: 36
XtRemoveWorkProc 6: 36
XtResizeWidget 6: 36
XtResizeWindow 6: 36
XtResolvePathname 6: 36
XtScreen 6: 36
XtScreenDatabase 6: 36
XtScreenOfObject 6: 36
XtSetKeyboardFocus 6: 36
XtSetKeyTranslator 6: 36
XtSetLanguageProc 6: 36
XtSetMappedWhenManaged 6: 36
XtSetMultiClickTime 6: 36
XtSetSensitive 6: 36
XtSetSubvalues 6: 36
XtSetTypeConverter 6: 36
XtSetValues 6: 36
XtSetWMColormapWindows 6: 36
XtShellStrings 6: 37
XtStrings 6: 37

IN-40

Index

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 270

XtSuperclass 6: 36
XtToolkitInitialize 6: 36
XtTranslateCoords 6: 36
XtTranslateKey 6: 36
XtTranslateKeycode 6: 36
XtUngrabButton 6: 36
XtUngrabKey 6: 36
XtUngrabKeyboard 6: 36
XtUngrabPointer 6: 36
XtUninstallTranslations 6: 36
XtUnmanageChild 6: 36
XtUnmanageChildren 6: 36
XtUnmapWidget 6: 36
XtUnrealizeWidget 6: 36
XtVaAppCreateShell 6: 36
XtVaAppInitialize 6: 36
XtVaCreateArgsList 6: 36
XtVaCreateManagedWidget 6: 36
XtVaCreatePopupShell 6: 36
XtVaCreateWidget 6: 36
XtVaGetApplicationResources 6: 36
XtVaGetSubresources 6: 36
XtVaGetSubvalues 6: 36
XtVaGetValues 6: 36
XtVaSetSubvalues 6: 36
XtVaSetValues 6: 36
XtWidgetToApplicationContext 6: 36
XtWindow 6: 36
XtWindowOfObject 6: 36
XtWindowToWidget 6: 36
XUndefineCursor 6: 31
XUngrabButton 6: 31
XUngrabKey 6: 31
XUngrabKeyboard 6: 31
XUngrabPointer 6: 31
XUngrabServer 6: 31
XUninstallColormap 6: 31
XUnionRectWithRegion 6: 31
XUnionRegion 6: 31
XUnloadFont 6: 31
XUnmapSubwindows 6: 31
XUnmapWindow 6: 31

XUnsetICFocus 6: 31
XVaCreateNestedList 6: 31
XVendorRelease 6: 31
XVisualIDFromVisual 6: 31
XWarpPointer 6: 31
XwcDrawImageString 6: 31
XwcDrawString 6: 31
XwcDrawText 6: 31
XwcFreeStringList 6: 31
XwcLookupString 6: 31
XwcResetIC 6: 31
XwcTextEscapement 6: 31
XwcTextExtents 6: 31
XwcTextListToTextProperty 6: 31
XwcTextPerCharExtents 6: 31
XwcTextPropertyToTextList 6: 31
XWhitePixel 6: 31
XWhitePixelOfScreen 6: 31
XWidthMMOfScreen 6: 31
XWidthOfScreen 6: 31
XWindowEvent 6: 31
XWithdrawWindow 6: 31
XWMGeometry 6: 31
XWriteBitmapFile 6: 31
XXorRegion 6: 31

Y
yacc

Index

11: 1

IN-41

DRAFT COPY
March 18, 1997
File: index
386:adm.book:sum
Page: 271