AdaIC Available Ada Bindings Report - 1996

SECTION 2: Standards and Specifications

In This Section:

2.1 Ada Semantic Interface Specification (ASIS)
2.2 Generic Package of Elementary Functions (GPEF)
2.3 Generic Package of Primitive Functions (GPPF)
2.4 Graphical Kernel System (GKS)
2.5 Information Resources Dictionary System (IRDS)
2.6 Portable Operating System Interface for Computer Environments(POSIX)
2.7 Programmer's Hierarchical Interactive Graphic System (PHIGS)
2.8 SQL Database Language
2.9 X Window System

2.1 Ada Semantic Interface Specification (ASIS)

[revised October 1995]
Steve Blake,
Thompson Software Products, Inc.
10251 Vista Sorrento Parkway, Suite 300
San Diego, CA 92121
tel: 619/457-2700

Description and standardization efforts

The Ada Semantic Interface Specification (ASIS) is an interface between an Ada environment and any tool requiring information from this environment. An Ada environment includes valuable semantic and syntactic information. ASIS is an open and published callable interface that gives CASE tool and application developers access to this information. ASIS has been designed to be independent of underlying Ada environment implementations, thus supporting portability of software engineering tools while relieving tool developers from having to understand the complexities of an Ada environment's proprietary internal representation.

ASIS version 1.1.1 is the official interface for Ada 83 environments. ASIS version 2.0 supports Ada 95 environments as defined by ISO/IEC 8652, (the Ada 95 Reference Manual).

ASIS should greatly increase the number of tools available to the end user because tools can be more easily created and ported to environments of competing compiler vendors. Consequently, ASIS will significantly reduce the cost and the risk for a CASE tool vendor to enter the Ada market. ASIS will also facilitate more powerful and capable tools to support software engineering.

Examples of tools that could benefit from ASIS are symbolic debuggers, test tools, design tools, reverse engineering and re-engineering tools, metrics tools, style checkers, correctness verifiers, and automatic document generators. For example, a metrics tool can use ASIS to evaluate Ada application code. The symbolic name, type, and usage of each Ada object can be obtained through the ASIS interface to support the requirements of the metrics tool.

Examples of other programs that could benefit include client/server communication between Ada programs occurring on separated processors. One application is currently using ASIS to analyze messages transmitted from a satellite to a ground station. The methodology used in this application has a significant cost savings benefit to any application doing data reduction for postmission analysis.

ASIS is a unique interface in that it is the only consensus based "de facto standard" capable of supporting an interface to an Ada library as the library is updated through new compilations. In this manner, CASE tools now have access to the latest information.

ASIS is designed to be implemented on a variety of machines and operating systems by many Ada vendors, and to support Ada semantic requirements for a wide range of client tools. ASIS provides primitive services with the intent that toolkit layers of higher level sophisticated services addressing the variant needs of specific Integrated Software Engineering Environment (ISEE) tools can be created from these primitives.

Plans to standardize ASIS

The latest public version for ASIS is ASIS 1.1.1, dated May 1994, and is based on the 1983 Ada Specification. The latest working draft is ASIS2.0.C, which will be available publicly by November 1995. The ASIS Working Group (ASISWG), under sponsorship of the Association of Computing Machinery's Special Interest Group on Ada (ACM SIGAda), is evolving this working draft into a standard accepted by the International Organization for Standardization (ISO), and complementing the Ada 95 standard.

Products implementing ASIS

To date, product implementations of ASIS are being offered by Thomson Software Products, Rational, and others. Contacting these vendors directly is the best way to obtain current product information.

ASIS implementation differences

ASIS 1.1.0 attempts to clearly define the areas where differences are allowed to occur.

This list of potential variations is organized into several categories.

Optional and testable functionality: This group includes the optional features that are called out explicitly in the ASIS specification, and for which ASIS provides a query function to test whether the feature is supported by a particular implementation.

Bounded untestable variances: This group includes operations or features that are explicitly allowed by the specification to vary in prescribed ways, but for which there is no operation to query the behavior of a particular implementation.

Unbounded and untestable transformations: This group includes transformations, normalizations, and optimizations that may be performed early during compilation and thus affect the view resented via ASIS. There is no way to detect these transformations currently, and they may impact tools.

True system dependencies: Operations that it would not make sense to attempt to standardize further. This does not include compiler optimizations.

Information about ASIS

There are two electronic mail forums for the ASISWG: The technical discussion address is General non-technical subjects are discussed on Both lists receive all announcements of ASISWG meetings. To add your address to these, send e-mail to or to and indicate your preferred e-mail address, name, telephone number, fax number, and surface mail address.

ASIS 1.1.1 is available via anonymous FTP from the AdaIC Internet Host ( Please refer to Appendix B - Repository/Software-Reuse Library Information for directions on how to logon to the AdaIC's Internet host.

2.2 Generic Package of Elementary Functions (GPEF)

[no updates needed]

Gilbert Myers, NCCOSC RDT&E Division (NRaD)
53140 Gatchell Road-Room 335
San Diego, CA 92152-7440
tel: 619/553-4136

Description and standardization efforts

The proposed standard for the Generic Package of Elementary Functions (GPEF) represents the work of a large number of people in both the United States and Europe who have collaborated to develop specifications for packages of Ada mathematical functions. This development has been difficult and lengthy. The exceptional dedication and perseverance of these people have resulted in the completed specifications for two packages - GPEF, and the Generic Package of Primitive Functions for Ada
(GPPF - discussed in Section 2.3).

GPEF is the specification for certain elementary mathematical functions. They are square root, logarithm and exponential functions, and the exponentiation operator; the trigonometric functions for sine, cosine, tangent and cotangent and their inverses; and the hyperbolic functions for sine, cosine, tangent, and cotangent together with their inverses.


The Ada-Europe Numerics Working Group (A-ENWG) was formed in 1984 about the same time that an early study proposing standard mathematical packages in Ada was undertaken by Symm and Kok. In 1986, the Numerics Working Group (NUMWG) of the Association of Computing Machinery's Special Interest Group on Ada (ACM SIGAda) was formed, and has met every few months since. During the 1980s, members of A-ENWG met on a regular basis with the NUMWG so that close cooperation was achieved on developing specifications that were joint effort of both groups. The A-ENWG has not met for some 4 to 5 years, but the NUMWG continues informal liaison with key European Ada individuals on continuing work.

Current Status

The work of both groups has resulted in proposed standards for GPEF and GPPF, which have been adopted by the Numerics Rapporteur Group (NRG), a subcommittee of Working Group 9 (Ada) of Subcommittee 22 of Joint Technical Committee 1 of the International Organization for Standardization-International Electrotechnical Commission (ISO-IEC JTC1/SC22/WG9 (Ada). The NRG has proposed GPEF and GPPF for standardization. WG9 has approved both proposed standards and forwarded them to SC22 for voting. GPEF has been accepted as Draft International Standard (DIS) 11430 and GPFF has been approved as DIS 11729. Work continues to complete the editorial formatting of the documents for final publication and acceptance as international standards.

2.3 Generic Package of Primitive Functions (GPPF)

[no updates needed]

Gilbert Myers, NCCOSC RDT&E Division (NRaD)
53140 Gatchell Road-Room 335
San Diego, CA 92152-7440
tel: 619/553-4136

Description and standardization effort

The proposed standard for the Generic Package of Primitive Functions for Ada (GPPF) represents the work of a large number of people in both the United States and Europe who have collaborated to develop specifications for packages of Ada mathematical functions. This development has been difficult and lengthy. The exceptional dedication and perseverance of these people have resulted in the completed specifications for two packages - GPPF, and the Generic Package of Elementary Functions for Ada (GPEF - discussed in Section 1.2).

GPPF is the specification for primitive functions and procedures for manipulating the fraction part and exponent part of machine numbers of the generic floating-point type. Additional functions are provided for directed rounding to a nearby integer, for computing an exact remainder, for determining the immediate neighbors of a floating-point machine number, for transferring the sign from one floating-point machine number to another, and for shortening a floating-point machine number to a specified number of leading radix digits.


The Ada-Europe Numerics Working Group (A-ENWG) was formed in 1984 about the same time that an early study proposing standard mathematical packages in Ada was undertaken by Symm and Kok. In 1986, the Numerics Working Group (NUMWG) of the Association of Computing Machinery's Special Interest Group on Ada (ACM SIGAda) was formed, and has met every few months since. During the 1980s, members of A-ENWG met on a regular basis with the NUMWG so that close cooperation was achieved on developing specifications that were joint effort of both groups. The A-ENWG has not met for some three years, but the NUMWG continues informal liaison with key European Ada individuals on continuing work.

Current Status

The work of both groups has resulted in proposed standards for GPEF and GPPF, which have been adopted by the Numerics Rapporteur Group (NRG), a subcommittee of Working Group 9 (Ada) of Subcommittee 22 of Joint Technical Committee 1 of the International Organization for Standardization-International Electrotechnical Commission (ISO-IEC JTC1/SC22/WG9 (Ada). The NRG has proposed GPEF and GPPF for standardization. WG9 has approved both proposed standards and forwarded them to SC22 for voting. GPEF has been accepted as Draft International Standard (DIS) 11430 and GPPF has been approved as DIS 11729. Work continues to complete the editorial formatting of the documents for final publication and acceptance as international standards.

2.4 Graphical Kernel System (GKS)

[revised October 1995]

Ada Information Clearinghouse
tel: 1-800/232-4211 (703/681-2466)
fax: 703/681-2869

Description and standardization efforts

The Graphical Kernel System (GKS) is an American National Standards Institute (ANSI) standard graphics library, and a superset of the International Organization for Standardization (ISO) standard graphics library. GKS contains subroutines for an application programmer to incorporate within a program in order to produce and manipulate graphical images. It is defined independently of any particular language.

Binding Status

The Ada binding to GKS (GKS/Ada) is an ANSI/ISO standard.


The ANSI GKS/Ada Binding is published by ANSI as document #X3.124.3. The International Standard is published as ISO 8651-3. To inquire about availability of either standard, contact: ANSI, 1430 Broadway, New York, NY 10018; tel (sales): 212/354-3300; general: 212/354-3300

2.5 Information Resource Dictionary System (IRDS)

Wm. Currie Colket
Space and Naval Warfare Systems Command
Attn: Code 331-1A, CPK 5
Arlington, VA 22245-5200
tel: 703/602-3968
fax: 703/602-6805

Description and standardization efforts

The Information Resource Dictionary System (IRDS) is a series of international standards that specify a software tool that can be used to describe and potentially control an enterprise's information resources. These standards define the structure and part of the content of the data to be maintained at the Information Resource Dictionary (IRD) Definition Level, and the structure of the data to be maintained at the IRD Level. It also defines the services to be provided for maintaining and retrieving data at both levels.

Standards efforts involve both the American National Standards Institute (ANSI) and the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC).

Important IRDS international standards include:

ISO/IEC 10027: 1990; Information Technology - Information Resource Dictionary System (IRDS) Framework.

ISO/IEC 10032: 1993; Information Technology - Reference Model of Data management.

ISO/IEC 10728: 1993 (E); Information Technology - Information Resource Dictionary System (IRDS) Services Interface.

The pertinent standard for Ada bindings is the IRDS Services Interface (ISO/IEC 10728). This standard specifies a services interface to give any program full access to all IRDS services through external calls provided by the language in which the program is written. This standard defines the semantics of the interface using ISO Pascal (ISO 7185). Language bindings for other ISO standard programming languages are to be provided as annexes to ISO/IEC 10728. Current work is in process for a C Binding (Annex C) and an Ada Binding (Annex D).

The IRDS Services Interface standard has sections addressing IRDS concepts, IRDS facilities, abstract data structures, services concepts, service facilities, service data structures, and service formats. The Ada binding is primarily concerned with the service data structures (data types used in the interface to IRDS) and the service formats (Ada subprogram calls to the IRDS interface). The Ada binding is syntactic, using the Pascal specification and description in ISO/IEC 10728 for the semantics.

The IRDS Services Interface language binding for the Ada language is presented in the form of an Ada package specification. Equivalent Ada types are used to build data structures. It is expected that the package body will perform the necessary transformations to convert objects of Ada types to objects of IRDS types. Since Ada types are used, separators are not required.

Exceptions are used in lieu of Service Return Codes.

Several IRDS sessions can proceed in parallel using Ada tasking.

The IRDS Ada package specification conforms to the ISO standard for IRDS Services Interface. The package specification contains:

Constants defining name length limits, attribute length limits, and control identifier length limits.

Type definitions for data types, IRD content status classes, column data types, object names, control identifiers, and column list parameters.

Ada Exceptions are used for the diagnostics area in preference to Service Return Codes. The invoking of any service (except Get_Diagnostics) can raise the exception called IRDS_Error. The Ada error handler would then invoke the procedure Get_Diagnostics to ascertain the problem. Get_Diagnostics cannot raise exception IRDS_Error, because this would be circular.

Procedures are used for specifying operational services, level-independent services, and IRD definition level specific services.

Strategy for the ANSI/ISO Ada language binding to IRDS

In the Ada language binding to IRDS, the data names and data structures defined in the IRDS Standard have been adhered to except where the Ada language does not provide an appropriate construct. The binding defined in the package specification provides an interface to the primary Ada types. Time and date abstractions are obtained from Package Calendar. It is expected that the package body will provide the necessary transformations to IRDS types.

In the Ada binding, the procedure names and their parameters have been adhered to except where the Ada language does not provide an appropriate construct.

All names have been spelled out with underscores between logical words. Types as used for data structures have the explicit word "type" added to the simple name.

The "Irds" prefix has been removed from all types, objects, and procedure names. The desired effect is achieved through the use of a package called "IRDS". The fully qualified name will thus include IRDS (e.g., IrdsCreateIRDDefinition becomes IRDS.Create_IRD_Definition, IrdsNameLim becomes IRDS.Name_Limit, IrdsSessId becomes IRDS.Session_Id_Type).

All types end with the suffix "_Type" with the exception of the Ada predefined types of Boolean, Character, and String. This approach provides a means to improve portability between IRDS implementations.

Strings are passed as an access type (a pointer) allowing unbounded lengths. A list structure is used for the Column List Parameters using access types. Access types end with the suffix "Pointer_Type."

Status of the ISO/ANSI binding

The base IRDS standard is approved by ANSI (X3/H4) and is currently a recommendation to ISO's Joint Technical Committee 1, Subcommittee 21, Working Group 3 (JTC1/SC21/WG3) - reference IRDS Services Interface ISO/IEC 10728:1993(E). The base standard will include the Ada binding specified in a separate Annex. A new standard, colloquially called "IRDS2" includes improvements to IRDS and will incorporate the Ada binding.

Documentation of the ISO IRDS

The ISO standard, ISO/IEC 10728:1993(E), is available from ANSI at a cost of approximately $102. There are additional charges for shipping and handling. Contact: American National Standards Institute, Attn: Customer Service Department, 11 West 42nd Street, New York, NY 10036; tel: 212/642-4900.

When available, the Ada Binding will be Annex D to ISO/IEC 10728. The current Ada binding to IRDS is available in electronic form on the Internet, on the AdaIC's Internet host ( in the directory at /tools/bindings/IRDS/.

Historical Work

In the 1970's, the National Bureau of Standards (now the National Institute of Science and Technology - (NIST) had sponsored a committee to develop Federal Information Processing Standards (FIPSs) for data-dictionary systems. ANSI formed a committee in 1980 to address standardization of information resource dictionary systems. These committees merged in 1983 with the combined mission to develop a FIPS and an ANSI standard. A framework for IRDS was developed and standardized.

In 1985, the ANSI standard was proposed to ISO for international standardization and was rejected. For six years the ANSI and ISO IRDS communities worked independently, until 1991 when it was agreed to harmonize their efforts. ISO/IEC 10728 is a partially harmonized standard. The IRDS community is now evolving an object-oriented standard called IRDS2. The ANSI committee responsible for IRDS is JTC1/SC21/X3H4, currently chaired by Dr. Jerry Winkler (tel: 703/425-4558). The ISO IRDS Rapporteur is Mr. David Gradwell (+44 (276) 23519).

2.6 Portable Operating System Interface for Computer
Environments (POSIX)

[revised October 1996]

David Emery, Hughes Aircraft of Canada, Systems Division
CDF, #200 - 13571 Commerce Parkway
Richmond, BC V6V 2J2 Canada
tel: 604/231-3232

Dr. Ted Baker, Florida State University
Dept. of Computer Science
Tallahassee, FL 32306-4019
tel: 904/644-5452

Description and standardization efforts

The Portable Operating System Interface for Computer Environments (POSIX) is the collective name for a set of standards providing applications portability at the source-code level. Most POSIX standards define either an Application Program Interface (API) or a Profile - which can be used by an applications programmer to write portable applications. An API is a specification of types, operations, etc, to be used by an applications program, along with their associated semantics. A Profile selects one or more standards and identifies options, restrictions, interoperability, etc, to support a specific applications domain.

The POSIX program grew from the effort by Unix users to develop a "standard" definition of the Unix system interface. The Institute of Electrical and Electronics Engineers (IEEE) Computer Society's Technical Committee on Operating Systems started work on this project in the 1985-1986 time frame. Later, the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) decided to provide international standardization for POSIX standards, delegating the development work to the existing IEEE group. Currently, the IEEE group is the Portable Applications Standards Committee (PASC), and the ISO/IEC group is Working Group 15 of Subcommittee 22 of Joint Technical Committee 1 (ISO/IEC JTC1 SC22 WG15). Generally, POSIX standards are developed by a working group within PASC, and submitted for concurrent IEEE and ISO/IEC ballots. The intent is to have a single document as both an IEEE and an ISO/IEC standard.

The National Institute for Standards and Technology (NIST) has also adopted POSIX as a Federal Information Processing Standard (FIPS) 151-1, which adopts ISO 9945.1:1989/IEEE 1003.1-1990

There are many different POSIX projects currently under way. To date, seven POSIX standards have been adopted by the IEEE. These are:

IEEE Std 1003.0-1995, POSIX Guide

IEEE Std 1003.1-1990, IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API), POSIX Basic System Services

IEEE Std 1003.1b-1993, IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API), Amendment 1: Real-time Extension (C Language)

IEEE Std 1003.1i-1995, Portable Operating Interface System (POSIX), Part 1: System Application Program Interface (API), Amendment 2: Real-time Extension (C Language)

IEEE Std 1003.1i-1995, Corrections to 1003.1b

IEEE Std 1003.1i-1995, Portable Operating Interface System (POSIX), Part 1: System Application Program Interface (API), Amendment 1: Real-time Extension (C Language)

IEEE Std 1003.2-1992, IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities.

IEEE Std 1003.3-1991, IEEE Standard for Information Technology - Test Methods for Measuring Conformance to POSIX.

IEEE Std 1003.3.1-1992, IEEE Standard for Information Technology - Test Methods for Measuring Conformance to POSIX - Part 1: System Interfaces.

IEEE Std 1003.5-1992, IEEE Standard for Information Technology - POSIX Ada Language Interfaces - Part 1: Binding for System Application Program Interface (API).

IEEE Std 1003.5-1992, IEEE Standard for Information Technology - POSIX Ada Language Interfaces - Part 1: Binding for System Application Program Interface (API), Amendment 1: Realtime Extensions.

IEEE Std 1003.5a-1996, IEEE Standard for Information Technology - POSIX Fortran 77 Language Interfaces - Part 1: Binding for System Application Program Interface (API).

IEEE Std 1003.10-1994 (Supercomputing AEP)

IEEE Std 1003-17-1997 (Directory/NS)

Other projects are in varying stages of development, including P1003.4 for real-time extensions, P1003.6 for system security, P1003.7 for system administration, P1003.8 for network file access, P1003.10 for supercomputing profile, P1003.12 for protocol-independent networking, P1003.13 for real-time profile, and at least 10 other projects.

Some (but not all) of the IEEE standards are also ISO/IEC standards. IEEE Std 1003.1 has been adopted by ISO/IEC as ISO 9945-1, and IEEE Std 1003.2 has been adopted by ISO/IEC as ISO 9945-2.

NIST has also adopted POSIX as a Federal Information Processing Standard (FIPS). However, there has been a problem with the FIPS and the IEEE/ISO Standards. IEEE 1003.1 has undergone several revisions since it was first approved by the IEEE in 1988. The current version is ISO/IEC 9945-1:1989/IEEE Std 1003.1-1990, which corresponds to FIPS 151-1. However, a revision to the IEEE/ISO standard is underway. The problem is that the approval cycle for FIPS is not synchronized with the approval cycle for IEEE/ISO POSIX standards. In general, FIPS approval has lagged behind IEEE/ISO approval by at least one year.

Ada Bindings

Initially, because of its Unix heritage, POSIX API standards were specified in terms of the C language. However, as the POSIX effort grew, it became clear that other languages besides C could make effective use of the POSIX APIs. Projects to develop Ada and FORTRAN bindings were approved around 1986. PASC Working Group P1003.5 was chartered to develop Ada bindings for POSIX standards, with its first project being the Ada binding to IEEE 1003.1.

The P1003.5 Working Group made several initial decisions that influenced the resulting document. The group decided that it was inappropriate for the Ada binding to depend on the C binding, so IEEE Std. 1003.5 was specified as a self-contained "thick" binding document. (The alternative, a "thin binding document", would have contained pointers to text in IEEE Std. 1003.1). The other major decision was to provide Ada abstractions for the facilities in IEEE Std. 1003.1, rather than provide direct Ada analogs to each and every C type and function.

The IEEE approved IEEE Std. 1003.5 in July 1992. Due to a disagreement between the IEEE and ISO/IEC on how language bindings would be described, IEEE Std. 1003.5 was not initially accepted by ISO/IEC JTC1/SC22/WG15 for ISO/IEC standardization. Recently, ISO adopted IEEE std. 1003.5-1992 as ISO 14519.1:1995, via a "fast track" ballot. (As part of a reorganization of the POSIX work program, most POSIX efforts were renumbered, hence the "new" and "old" numbers.

The IEEE standard is available from the IEEE as document #SH 15354, from the IEEE Services Center, 445 Hoes Lane, Piscataway, NJ 08855, 800/678-4333.

IEEE Std. 1003.5 represents only one of many possible Ada bindings for IEEE standards. PASC Working Group P1003.5 is currently working on several Ada bindings projects.

IEEE Project P1003.5b (formerly P1003.20) developed Ada bindings for the POSIX real time standards , IEEE1003.1b (real time extensions, formerly P1003.4), and 1003.1c (threads extensions, formerly P1003.4a). It was approved by the IEEE in June 1996, but is still awaiting publication. Copies of the approval draft can be obtained from the IEEE Standards Office.

IEEE Project P1003.5a consists of Ada bindings for IEEE Std 1003.1g, the protocol-independent network interfaces (sockets and XTI). This project produced a draft that went through one mock ballot in Summer 1996. Work is now progressing on a revised draft, that may be suitable for formal ballot.

Two other Ada bindings are assigned to P1003.5. These are P1003.5 and P1003.5d. These projects cover Ada bindings to XT! and Sockets communications facilities, IEEE Projects P1003.12 and P1003.12a, respectively.

There are two other related POSIX/Ada efforts. IEEE Project 1003.5 is developing standard test assertions for ISO 14519.1:1995/IEEE Std. 1003.5-1992. IEEE Project 1003.21 is developing real-time distributed communications interfaces, including an Ada binding.

An overview of IEEE Std. 1003.5-1992

IEEE Std. 1003.5-1992 (commonly called POSIX/Ada) provides an Ada programer with access to operating-system services in the area of process control, process environment (including command line parameters), files and input/output (I/O), terminal devices and serial line control, and user and group databases.

The binding is organized as a series of packages, where each package provides access to a set of related services. For instance, facilities for controlling files are contained in the package POSIX_FILES, and the POSIX I/O operations are defined in package POSIX_IO. To avoid library-level name conflicts with user packages, all of the POSIX packages begin with "POSIX_" (except for the one package called "POSIX").

The package POSIX contains several common definitions for the binding, including the type POSIX_CHARACTER. An implementation may provide a character set (such as EBCDIC or IBM-PC character sets) that is different from Ada's predefined set. The type POSIX_CHARACTER allows access to the host environment's character set. The standard defines an interoperable subset of characters that are in both Ada's STANDARD.CHARACTER and POSIX.POSIX_CHARACTER. This package also defines various parameters on the POSIX implementation, such as the maximum number of open file descriptors and the maximum length of a filename.

Error handling is an important part of any binding. Errors are generally reported back to the user via the exception POSIX.POSIX_ERROR. The type POSIX.ERROR_CODE represents the predefined error conditions, such as FILE_EXISTS or PERMISSION_DENIED. When POSIX_ERROR is raised by the call to a POSIX operation, the program can call POSIX.GET_ERROR_CODE to retrieve the error code associated with the failed operation. Error status is kept on a per-task basis, to prevent race conditions between the call to a POSIX operation that fails and the call to GET_ERROR_CODE within a single task.

POSIX models the entire Ada program as a single POSIX process. For instance, all calls to POSIX_PROCESS_IDENTIFICATION.GET_PROCESS_ID from tasks within the same main program must return the same process ID. However, this does not prevent implementations from using multiple processes to support Ada tasking, as long as this does not change the behavior of POSIX/Ada operations.

Tasking safety was a major concern of the P1003.5 Working Group.In general, POSIX/Ada operations are required to be safe for use in programs with multiple tasks. However, POSIX/Ada does not guarantee task related blocking semantics. If one task performs I/O, it is implementation-dependent whether just that task or the entire process/program may be blocked. The basic definition of POSIX (IEEE Std. 1003.1:1990) does not provide sufficient functionality for POSIX/Ada to require or specify pertask blocking for I/O and other blocking situations. POSIX/Ada does provide a facility that allows the program to determine if the entire program/process or just the calling task will be blocked when doing I/O. A "smart" program can modify its behavior depending on the facilities provided by the implementation.

The IEEE Standard contains a very detailed rationale explaining the the reasoning and analysis that led to the final shape of the binding. The rationale discusses most of the issues that confront any binding developer, including packaging, documentation style (e.g., "thick" vs "thin") and tasking safety.

An overview of P1003.5b (Real-Time Extensions)

P1003.5b is a revision and extension of P1003.5, to reflect the new Ada language standard (ISO/IEC 8651:1995), the POSIX Realtime extension (IEEE Std 1003.1b-1993), and the POSIX Threads extension (IEEE Std 1003.1c -1995). P1003.5b incorporates the original content and style of presentation of P1003.5 and the new additions preserve the "look and feel" of P1003.5.

P1003.5b includes services for process and task/thread synchronization, as defined in both POSIX.1b and POSIX.1c. Process synchronization is supported via semaphores, and thread/task synchronization through condition variables and Mutexes. The standard also provides support for scheduling policies and parameters. Additional I/O services include data synchronization for ensuring data is flushed to disk and asynchronous I/O operations. New interprocess communication mechanisms include message queues and real-time signals. Real-time signals differ from conventional UNIX signals by being queued (so they are lossless) and being able carry data with them. New memory management capabilities include locking pages into main memory, creating shared memory objects, and mapping files into virtual memory. There is support for a real-time clock with higher precision than is guaranteed by POSIX.1/P1003.5, and associated timers.

Conformance issues

POSIX conformance is defined both for implementations and for applications. Implementation conformance basically means that the implementation correctly implements the POSIX API and its semantics. Application conformance means that the application uses only facilities defined within POSIX or other IEEE or ISO standards. In particular, a strictly conforming POSIX application may not use implementation extensions to POSIX.

IEEE Std. 1003.5 places specific restrictions on conforming implementations. A conforming implementation has to implement the API as defined by the standard - i.e., POSIX_IO.OPEN has to work as described, etc. Since POSIX portability is defined at the source-code level, IEEE Std. 1003.5 places restrictions on an implementation's actual definition of the standard POSIX packages. For instance, an implementation may not add an operation to the visible part of a standard package. The intent of these restrictions is to make sure that applications code can be moved from one conforming implementation to another without encountering compiler errors due to inadvertent overloading, etc.

Currently there is no test suite to measure implementation conformance to IEEE Std. 1003.5. (NIST has certified several test suites for measuring conformance for the C binding, IEEE Std. 1003.1.) Also, it is possible for an implementor to provide an interface to POSIX that does not claim conformance to IEEE Std. 1003.5. Finally, it is quite possible for a system to claim "POSIX conformance" because it conforms to the IEEE 1003.1 (or 1003.9) standard, but no Ada binding is provided. Therefore, when specifying or discussing "POSIX compliance", it is important to ensure that the system provides a conforming implementation of IEEE Std. 1003.5. An implementation that claims conformance only to IEEE Std. 1003.1 will not be of much use for Ada programming.

Some available resources

Ada Interfaces to POSIX:

This report considers the applicability of POSIX in the development of the Defense Department's Software Technology for Adaptable Reliable Systems (STARS) Software Engineering Environment, comparing it to the Common APSE Interface Set, version A (CAIS A). (This report is available from ASSET as ASSET_A_155. For more information on ASSET, see Appendix C.)

The POSIX/Ada Binding Tutorial

A tutorial on IEEE Std. 1003.5 1992 was presented at the TRI-Ada 1992 and TRI-Ada 1993 conferences, as well as Ada Europe 1993 and Ada UK 1992. Copies of the tutorial slides were printed in the TRI-Ada tutorial proceedings document.

A Prototype Implementation of the POSIX/Ada Binding

A paper on a prototype of an early verion of POSIX/Ada was presented by David Emery at TRI-Ada 1990. A copy of this paper can be found in the TRI-Ada 1990 proceedings. The paper describes techniques used to implement POSIX/Ada via pragma interface calls to the POSIX C library.

FSU POSIX/Ada Realtime Project

The FSU POSIX/Ada Real-Time (PART) project has produced a number of papers on the relationship between POSIX and Ada, and a prototype implementation of the P1003.5b Ada binding for use with the GNU NYU Ada 95 Translator (GNAT).

The Forest P1003.5 Implementation

Kenneth Almquist <> has also developed an implementation of P1003.5 that can be used with GNAT. His library, called "forest", is available via anonymous ftp from "", in subdirectory "/pub/gnat/contrib/forest". It is less complete than the FSU implementation; in particular, so far it does not include any of the P1003.5b extensions. It does include a useful tool for translating C type declarations to Ada.

2.7 Programmer's Hierachical Interactive Graphics System (PHIGS)

[October 1995]

Ada Information Clearinghouse
tel: 1-800/232-4211 (703) 681-2466
fax: 703/681-2869

Description and standardization efforts

The Programmer's Hierarchical Interactive Graphics System (PHIGS) is designed to support computer graphics applications that are highly dynamic and interactive. It supports a hierarchical graphical database that can be edited while elements of the database are being displayed. Such functionality is needed to support such applications as computer-aided design/computer-aided manufacturing (CAD/CAM) systems, command-and-control systems, and modeling of objects, etc.

A complement to PHIGS is the International Organization for Standardization (ISO) standard PHIGS Plus (ISO 9592-4). It augments the capabilities of PHIGS with functionality for lighting and shading, as well as for more complex primitives including B-splines. This standard is known as PHIGS PLUS (Plus Lumiere and Shading).

Both PHIGS and PHIGS PLUS are defined independently of any particular language.

Binding status

The PHIGS/Ada binding has been published as ISO 9593-3 and has been adopted as an American National Standards Institute (ANSI) standard under the same number.


The PHIGS/Ada binding is available from: ANSI, 1430 Broadway, New York, NY 10018; tel: 212/642-4900 (sales), 212/354-3300 (general)

2.8 Database Language SQL

James W. Moore
The MITRE Corporation
1820 Dolley Madison Boulevard
McLean, VA 22102

Description and standardization efforts

This section first describes the ISO/ANSI standard Database Language SQL and its bindings to Ada. It then describes approaches such as the SAME and SAMeDL, which build upon the standard binding. Finally, some related standards are briefly discussed.

Database Language SQL and its binding to Ada

Database Language SQL is a language for manipulating relational databases; it is a standard under both the American National Standards Institute (ANSI) and the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC). (“SQL” is no longer an acronym. Once it was an acronym for “Structured Query Language”, a language associated with a particular vendor’s prototype database-management system. When referring to the standard, “SQL” is simply an abbreviation for “Database Language SQL”.)

SQL provides facilities for defining, manipulating, and controlling data in a relational database. As a standard specification, it promotes the portability of database applications among conforming database management products.

SQL is defined in terms of a reference language called the “module language”. In principle, one defines the desired manipulations of the relational database by using the module language to write a number of SQL statements that are then collected as procedures within a “module”. Programming-language bindings take either of two forms: a procedural "module" form (which makes application-program subroutine calls on the procedures in the SQL module) or an embedded form (which has the effect of intermixing the SQL statements with the application program). The standard describes the embedded binding in terms of a syntactic transformation of the module and the application program.

Use of the embedded binding involves inserting SQL statements into Ada programs, creating codes that are not pure Ada. These codes are intended to be pre-processed by a vendor-supplied preprocessor that replaces the SQL statements with compilable, but implementation-dependent, subroutine calls. For languages other than Ada, the embedded binding has been the form typically provided by database-management system (DBMS) vendors.

The procedural binding (usually called the “module binding”) is a thin, direct binding of Ada to an SQL “module” that is a set of SQL statements packaged as procedures. The procedural binding describes how an Ada application program may make Ada subprogram calls upon the procedures of the SQL module. Thus an Ada application using the procedural binding is written in compilable Ada without interleaved SQL statements. Most Ada experts prefer the procedural binding to the embedded binding.

The binding for Ada uses a set of data types that are specified in a package named SQL_STANDARD. The explicit gathering and declaration of the data types provides the Ada binding with an advantage over the bindings to other programming languages. For other languages, the base SQL types are mapped to base types of the programming language. Because the value ranges of the base types are implementation-defined, mismatches can (and do) occur. SQL_STANDARD solves the problem by parameterizing the Ada types to match the SQL data types. Other types declared in SQL_STANDARD improve the safety and convenience of error checking.

Status of Database Language SQL and its binding to Ada

The SQL standard has progressed through three generations: a 1986 version (sometimes called SQL/86): a 1989 version (sometimes called SQL/89 or simply SQL); and the 1992 version (sometimes called SQL2 or SQL/92). Both ANSI and ISO published substantively identical documents known as ANSI X3.135-1992 and ISO/IEC 9075:1992, respectively. Since the 1992 standard was approved, two technical corrigenda have been published; the second one adds to and completely replaces the first one. All of the major DBMS vendors support the 1992 version of the standard.

The 1992 standard prescribed three levels of the SQL language: the Full language; a subset called "Intermediate"; and a smaller subset called "Entry". All of the major vendors support the Entry level; I know of none who support the larger language levels.

Particularly for federal procurements, a NIST Federal Information Processing Standard, FIPS 127-2, is helpful. It requires conformance to the Entry level of the language, requires delivery of a FIPS "flagger" to check for non-standard extensions, and provides a conformance test suite. All of the major vendors supply products meeting the requirements of FIPS 127-2.

Products implementing the Ada binding of SQL

The 1992 standard specifies both embedded and module language bindings for Ada. Conformance to the standard, though, does not require the vendor to support all of the programming language bindings described in the standard. A vendor may truthfully advertise their product as conforming to the standard even though some of the language bindings do not conform. So, it is important for a buyer to ensure that both the DBMS and the required language bindings conform to the desired level of the standard. NIST performs conformance testing upon SQL products and their bindings. An up-to-date list of conforming products can be obtained by ordering the NIST “Validated Products List” from the National Technical Information Service. Both subscriptions and single copies are available.

All of the major DBMS vendors provide conforming Ada bindings. From their literature, it appears that Sybase, Informix, Oracle, DB2 and Rdb (now sold by Oracle) all offer conforming Ada module language bindings. It appears that Oracle (and perhaps Informix) offers a conforming embedded Ada binding. Sybase also offers a non-standard Ada binding which, they feel, gives advantages in some situations because of its integration with a graphical user interface.

Documentation of Database Language SQL and its binding to Ada

The 1992 ANSI standard, X3.135-1992, can be obtained from ANSI at a cost of approximately $225. The ISO standard, ISO/IEC 9075:1992 is also available from ANSI at a cost of $266. The two are substantively identical. There are additional charges for shipping and handling. Contact: American National Standards Institute, 11 West 42nd Street, New York, NY 10036, Attn: Customer Service Department; tel: 212/642-4900.

The FIPS publication, FIPS 127-2, and the NIST Validated Products List (NISTIR 5167) can be obtained from: National Technical Information Service (NTIS), U.S. Commerce Department, 5285 Port Royal Road, Springfield, VA 22161; tel: 703/487-4650.

There are several good textbooks describing SQL. The one that I use is: C.J. Date with Hugh Darwen, A Guide to the SQL Standard, 3rd edition (describes SQL/92), Addison-Wesley, 1993.

A tutorial on the use of the module binding is provided in: James W. Moore, “The ANSI Binding of SQL to Ada,” Ada Letters, XI:5, July/August 1991, published by the Association of Computing Machinery’s Special Interest Group on Ada (SIGAda).

During the early 1980’s, a proposal variously named as “Ada/SQL” or as the “WIS”, “IDA”, or “RACOM” approach and described in papers by Friedman and Brykcynski was offered for standardization. For various reasons that proposal was rejected for standardization and is now inappropriate for use in new systems.

The SAME approach and the SAMeDL

Although the ANSI standard gives Ada a binding to SQL that is similar to that provided for other languages, some users desire an interface that is more “abstract” and that may be better suited to the software-engineering principles of Ada. To develop this interface, in 1988 the Software Engineering institute (SEI) created an informal, public committee, the SQL/Ada Module Extensions Design Committee (SAME-DC) chaired by Marc Graham. Besides drafting the binding eventually adopted by ANSI and ISO, the committee created a methodology, the SAME approach for layering an abstract module upon the standard binding. This abstract module would convert SQL numeric return codes into Ada exceptions, provide for a safe treatment of database nulls, promote basic SQL data types to user-defined types, and group scalar database values into “row-records”. It should be noted that the SAME approach provides for data abstraction but not procedural abstraction, i.e., each call from the application maps to a single SQL operation performed on the database. An SEI technical report describes the SAME approach: Guidelines for the Use of the SAME, CMU/SEI-89-TR-16, (DTIC #: AD-A223 932). Another SEI report provides suggested conformance criteria intended for use in peer evaluation of application of the approach: Conformance Criteria for the SAME Approach to Binding Ada Programs to SQL, SEI-89-SR-14.

Attempts have been made to automate the SAME approach. Under contract by the DoD’s Software Technology for Adaptable, Reliable Systems (STARS) program, Lockheed, led by Susan Mouton Phillips, provided Ada programs and a method for generating source code for the SAME abstract module via the declaration, instantiation, and execution of Ada generic packages. Two reports describe the project: an overview of the technical approach is given in General Definition of Project (Ada/SQL Binding), DTIC #: AD-A228 481; a more detailed description appears in User’s Manual for a Prototype Binding of ANSI-Standard SQL to Ada Supporting the SAME Methodology, DTIC #: AD-A228 480.

Informix offers a product, Ada/SAME, that is said to provide some automated support for the SAME method through extensions to the standard Ada module language binding.


After developing the SAME method, the SEI group went on to produce the SQL Ada Module Description Language. SAMeDL is a language that, when processed by an appropriate tool, generates the SAME abstract module and other code necessary to access a database-management system from a particular application. Although the SAMeDL is defined in terms of the ISO binding, an implementation is not constrained to be layered upon the standard binding — and may, in fact, be specific to a particular DBMS product. Standardization of the SAMeDL did not proceed through the groups responsible for SQL. Instead, standardization was performed by the ISO working group responsible for Ada, ISO-IEC JTC1/SC22/WG9. The resulting standard was approved in 1995 and is known as ISO-IEC 12227:1995. The current standard specifies a binding to the 1983/1987 version of Ada rather than the new Ada 95. The standard reflects the 1992 version of SQL but not the recently approved additions to it. The current SAMeDL standard supports only the entry level of SQL, not the larger intermediate and full language levels.

Since SAMeDL is not recognized as an conforming method of binding by FIPS Publication 127-2, users may be interested in the relationship of SAMeDL to the conformant binding methods. The SAMeDL standard permits a processor to claim conformance via "mapping" or via "effect". Conformance via mapping means that the processor generates either the module or embedded binding. Conformance via effect means that the processor achieves the same results but by other, non-standard, methods. Users interested in meeting the requirements of FIPS Pub 127-2 should prefer a SAMeDL processor that conforms via mapping, preferably one that generates the Ada module binding.

Implementations of the SAMeDL for some specific platforms (HP RISC, Sun Solaris and IBM RS/6000) and specific DBMS products (Sybase, Informix, Oracle) are available in the U. S. from Intermetrics. The aforementioned DBMS vendors also provide the SAMeDL product through marketing agreements with Intermetrics. Apparently, only Sybase offers a product that implements the characteristic of conforming via mapping to the standard module binding. A SAMeDL product is offered in Germany by Competence Center Informatik.

Documentation of the SAME and SAMeDL

A copy of the SAMeDL standard can be obtained from ANSI for $135. Although the detailed proposal has been modified as it progresses through ISO, one can find early descriptions in several SEI Technical reports: The SQL Ada Module Description Language — SAMeDL (SEI-90-TR-26; DTIC #: AD-A235 781); Rationale for the SQL Ada Module Description Language (SEI-91-TR-4; DTIC #: AD-A235 780); and Notes on Applications of the SAMeDL (SEI-91-TR-12; DTIC #: AD-A240 851).

Any of the SEI reports noted above can be obtained from: Research Access, 800 Vinial Street, Pittsburgh, PA 15212; tel: 800/685-6510.

Reports that have been assigned DTIC accession numbers are available to registered DTIC users from Defense Technical Information Center, Cameron Station, Alexandria, VA 22304-6145; tel: 703/274-7633. Those who are not registered DTIC users may use the DTIC accession numbers to obtain the documents from NTIS at the address noted previously in this section.

Other Related Standards


None of the binding methods described above offer a true Application Program Interface, API, to the RDBMS. All require the manipulation and linkage of source code, written in SQL or SAMeDL, to achieve the interface to the database product. For some time, third party vendors of "shrink wrapped" software have desired an object code interface to RDBMS products.

The recently approved ISO-IEC 9075-3, Call Level Interface (CLI), provides such an interface. Apparently, none of the major RDBMS vendors yet support the interface, but most of them support Microsoft's Object Data Base Connectivity Version 2 (ODBC 2) a subset of CLI. Furthermore, Microsoft is said to have promised that ODBC 3 will conform with (i.e., be a superset of) CLI. Finally, X/Open is said to be preparing a conformance test suite for ODBC 3.

The ultimate role of the interface is still unclear. The major DBMS vendors support ODBC 2 as the way to access their DBMS from Microsoft platforms. Some third party vendors, though, see ODBC/CLI as the interface to a large variety of value-added services like transaction processing and distributed databases.

There are no standard bindings of CLI to any programming language. The CLI standard explains the routines and their parameters in a language-independent fashion and provides examples in C (representing the class of languages with pointers) and Cobol (representing the class of languages without pointers). For each language, the mechanism for parameter passing (e.g., by name, by reference) is specified.

Objective Interface Systems provides both Ada 83 and Ada 95 bindings to ODBC 2. They are marketed by Intersolv, one of the leading vendors of ODBC drivers, for a number of platforms and DBMS.

RDA ISO 9579:1993, Remote Data Access, was once envisioned as a protocol for communication among distributed SQL servers and their clients. Apparently, none of the major DBMS vendors currently support RDA although some say they are willing if it is needed by a customer. The current RDA standard does not support all the functionality and data types of the 1992 SQL standard. Revision of the standard is planned in 1997.

SQL Environments FIPS Publication 193 provides useful guidance on how various standards might be employed to support heterogeneous environments of SQL and non-SQL databases and their clients.

2.9 X Window System

[to be revised - January 1996]

Christopher M. Byrnes,
The MITRE Corporation
202 Burlington Road-M/S A378A
Bedford, MA 01730-1420

Description and standardization efforts

Ada/X background

This section first describes the historical background that led to the current Ada/X Window System bindings. Understanding this background is important because potential users of these bindings should check the derivation or "breeding" of a product, as that will help determine the portability and compatibility of the resulting software. Experience has shown that even simple Ada/X applications programs - such as the canonical "Hello, world" example - can be coded in vastly different manners among different bindings. (For a discussion of this, see my "Porting Applications Between Two Commercial Ada/Motif Bindings", Proceedings of TRI-Ada '93.)

Historical background

There are several different ways of viewing the X Window System. One common way is to view the overall X system architecture arranged in a stack hierarchy:

User Interface Management System (UIMS)
Widget sets
Xt intrinsics
X protocol

The lowest level of this stack architecture is the X protocol, which defines the flow and structure of packets of information around a network. A library of subroutines (known as "Xlib") is used to create and receive these packets. These Xlib subroutines provide all the common actions associated with a bit-mapped display terminal, such as drawing a line or being notified that a keystroke was depressed.

Programmers soon realized that trying to write complex applications through these low-level Xlib calls was an extremely complex task. Eventually, a layer on top of Xlib was built, known as the "intrinsics" level, which was written to provide an object-oriented programming (OOP) interface. A major change in an intrinsics layer is the use of event-driven "callback" routines. No longer does the programmer call the windowing system from a "main line" programming loop provided by the application. Instead, the intrinsics layer contains an application's main line routine; the programmer provides the address of subroutines to call back in response to certain events. This completely inverts the flow of control and data in an application, where OOP "message passing" becomes the main programming paradigm. The most popular set of intrinsics functions, used on almost all X applications, are the X toolkit (Xt) intrinsics that are provided by the Athena consortium.

The Xt intrinsics provide just a set of OOP routines and conventions for defining actions such as how workstation events are passed to the application and how changes are propagated through the callback functions. To ensure a common "look and feel" as well as provide programmers with a large set of reusable components to start with, several organizations have developed reusable widget sets. Some widget sets, such as the Athena widgets, are provided at no extra charge on the X distribution tapes. Other widget sets are developed and maintained for sale by commercial organizations. The two best known of these X widget sets are the Open Software Foundation's (OSF's) Motif widgets and UNIX International's (UI's) Open Look (OL).

Some programmers have found using widget sets such as Motif and OL to be still too low-level to develop programs on. They have chosen the option of using a user interface management system (UIMS) to generate the application program interface (API) calls to a widget set. The highest level of an X architecture remains the application code, which has the option of using one or more of the lower layers. These lower layers are typically provided to the application as program libraries that are connected at link time, based on which API calls were used in the application. Depending on the UIMS, it may make direct bindings to one or more of these X architecture layers, or it may provide a more abstract API (such as a custom-developed binding specific to this UIMS) that provides similar functionality from the underlying widget set and/or intrinsics layer.

Another way of viewing X's architecture is through a client/server model. In this model, an X server is responsible for managing a scarce resource - in this case the workstation's graphical display surface and input devices (keyboard and mouse). The application programs (which sit as the top layer in their earlier stack architecture) are the clients, communicating with the server through X protocol calls. These clients can be local (running on the same workstation the server is) or can be running on another computer (communicating over a network).

The X architectures shown above provide a framework or reference model for describing X software. The actual X Window System software that is sold or distributed can change as new features are added and bugs are fixed. Over time, the Athena Consortium has made both major new versions of X and minor new releases of individual versions available for distribution. At the time of this report's preparation, the current major version of X was #11 and the release level was 5. This is commonly abbreviated as X11R5. Note that even when the Athena Consortium releases a new version of the base (or reference) X server implementation and client libraries (such as X11R6), there may be a lag time before a commercial organization (such as OSF or UI) or a language-binding developer (such as for Ada/X) will upgrade their products to conform to this new release. Therefore, it is important to understand how "version skew" can affect these X layers and the programming language bindings to them.

There have been a variety of efforts to create Ada/X bindings, below are just some of those the author has heard about:

Binding Developer

Ada/Xlib (R2) SAIC for original Software Technology for Adaptable and Reliable Systems (STARS) Foundations work (1988).

Ada/Windows DEC's interface to their "Xlib-like" DECWindows product (1989).

Ada/Xlib (R3) Early commercial versions of STARS Foundations work (1989).

Ada/Xlib (R4) STARS Ada/Xlib binding from SAIC and Unisys (1991).

Ada/Xt (R2) Software Productivity Consortium (SPC) proprietary binding to Hewlett-Packard (HP) widget set (1989).

Ada/Xt (R3) STARS Ada/Xt implementation on top of STARS Ada/Xlib from both SAIC and Unisys (1991).

Ada widgets STARS work to populate an Xt widget set on Ada/Xt implementation (1991).

Ada/Xt (R4) Jet Propulsion Laboratory (JPL) work to create Xt binding (1991).

Ada/Motif (R3) OSF-funded partial Motif bindings work at University of Lowell (1991).

Ada/Motif NASA's Transportable Applications Environment Plus (TAE+) UIMS uses Ada bindings to Motif (1991).

Ada/Xt SEI's Serpent UIMS, generating a direct Ada interface (1991).

Ada/Xt TRW's Generated Reusable Ada Man-Machine Interface (GRAMMI) UIMS (1991).

Ada/Xt Advanced Software Engineering Technologies' Agora UIMS based on Serpent.

Ada/Motif Systems Engineering Research Corporation's (SERC's) SA/Motif binding based on STARS Ada/Xt and Ada/Xlib specifications.

Ada/Motif Advanced Technology Center (ATC) Ada X Interface binding.

Ada/Motif TeleSoft's TeleUSE UIMS uses direct Ada bindings to Motif (1991).

Ada/Motif Objective Interface Systems' Screen Machine UIMS uses abstract Ada interface to Motif (1992).

Ada/Motif Sunrise Software International's ezX UIMS uses abstract Ada interface to Motif (1992).

Ada/UIMS Strategies' Heragraph UIMS produces Ada graphics applications conformant to Motif's "look and feel" (1992).

Ada/UIMS Sherrill-Lubinski's Graphical Modeling System (SL-GMS) UIMS produces Ada graphics applications conformant to Motif's "look and feel" (1992).

In the list above, the "Binding" column indicates which level of the X stack architecture (Xlib, Xt, widget set, and/or UIMS) is being bound to. Note that some of the Ada/UIMS tools do not provide interfaces to the lower layers of the X stack architecture, while other bindings typically provide interfaces to the highest layer named and each lower layer. The "R" number indicates which X release level the Ada API is being provided for, so "R3" indicates X11R3. The "Developer" column indicates who is (or has been) developing this Ada/X binding and what year that binding was first released for use. As can be seen from the dates in the list above, most of the Ada/X binding development work has been done in just the last few years. A number of Ada compiler vendors are reselling one of these bindings (such as SA/Motif and AdaX) as an add-on product to their compilers.

Many of the Ada/X developments discussed above are based on the idea of implementing all or parts of Ada/X as a binding on top of an underlying C/X implementation. Not all Ada developers have agreed with this assumption - some believe that it is possible to develop an all-Ada implementation of the entire X Window System so that their Ada programmers are not tied to what the base C/X implementation provides and so that Ada's built-in object-oriented design (OOD) and OOP constructs can be fully exploited.

Rational Corporation has developed an (almost) all-Ada implementation of Xlib for both their R1000 computers and Sun 3 workstations. This is instead of the more traditional approach of writing a binding to an underlying C/X implementation. They do have some assembler at the lowest layers to interface to the X protocol, where direct calls to network "sockets" are made. Rational donated this ~33,000 line Ada/Xlib implementation to the Athena Consortium for distribution on the X11R5 "contributed software" release tape.

All the Ada/X development work discussed above concentrates on the client side of X's architecture, providing the Ada interfaces and libraries that an application needs. But there has been work at Lockheed/Sanders to develop an all-Ada implementation of an X server. (For a description of how this Ada/X server implementation was done, see "Ada Implemenation of an X Window System Server" by Stuart Lewin, Proceedings of TRI-Ada '89.)

Ada application design issues

One area that has to be considered when developing an application using Ada/X is the software design method(s) being used. The X Window System assumes an OOP approach that is implemented manually in the default C programming language. Ada has its own built-in OOP constructs that OOD often tries to take advantage of. Many of these Ada/X bindings try to straddle the boundary between following what the reference X implementations in C (C/X, with which most existing X programmers will be most familiar with) provides and what an idealized Ada/X binding would provide.

Ada provides a variety of OOP constructs to choose from, and it turns out that many binding developers made different choices in their individual implementations of Ada/X. Experience with different Ada compilers has shown that individual compilers do a good job efficiently handling some Ada constructs but no---t others. There are variants across compiler vendors, so one compiler might do a good job with one approach but not another. The presence of different Ada/X implementation approaches allows application developers to choose which of the bindings best matches the strengths of their compiler. But this does require detailed knowledge by the application development organization as to the specific strengths and weakness of their chosen compiler(s).

When assessing a potential Ada binding and/or UIMS to be used with an application, experience with various Ada/X implementations has lead to an initial set of "lessons learned" about using complex Ada applications that vendors should be asked about (if important to the application):

Interactions with Ada tasking in application program, particularly given the non-threaded nature of many underlying C/X data structures.

Usability of resulting Ada code with symbolic debugger (Ada, C, etc.), particularly client/server interaction, tasking, and overall memory requirements.

X resource availability during Ada elaboration and other initialization order issues.

Handling of X resources within Ada packages and in the ~/.Xdefaults files.

Support for Ada generics, which are a means for abstracting some of the Ada/X vendor dependencies out of an application program.

Widget design and implementation issues

A major technical difference among various Ada/X bindings is how Ada/Xt callbacks are implemented. Xt intrinsics use an "event-driven" model of execution; the widget contains a pointer to an application routine that is called when a specified event occurs. The "main" control of the program exists within the internals of Xt; almost all of the application's windowing code will be subroutines that are called from within Xt. Unfortunately, Ada does not handle this particular OOD concept of being able to point to instances of encapsulated code and data very well, so Ada/X vendors had to design something that would simulate this concept.

One approach used within some of the STARS Ada/Xt implementation is to use tasks and task types to encapsulate widget instances. Since Ada allows pointers (access) to task types, it is possible to set up and assign pointers to what to call when certain events occur. Ada task types can be dynamically created and terminated, so the programmer has some flexibility on how and when to construct widgets.

Since Ada tasks exist within Ada's strong typing model, that means there are normally restrictions on how data is passed as parameters to the task's entry points and even how tasks of different types are treated separately. This is a problem with Xt intrinsics because a weak typing model is assumed. Applications programmers and widget developers are supposed to be able to easily construct higher-level widgets from the pieces of lower-level widgets. Xt's "inheritance hierarchy" assures that when an event occurs within one widget, it is propagated up the hierarchy to all the other related widgets that also need to deal with that widget. Widget developers provide default "methods" and "values" that the application programmers can use to control what is done when these events occur. Programmers are free to override these default "methods" through subclassing of a widget class into a new "subclass" and/or by manually setting a new method that is run as an alternative to the old one.

All this dynamic definition and reconfiguration of the structure or architecture of who is allowed to call what tends to conflict with Ada's strong (task) typing model. One solution is to separate the different types of widgets and their associated (underlying) Xt intrinsics into different Ada task types. But instead of different entry points for the different methods of this type of task (widget class), there is only one entry for all tasks (with each defined handle having exactly the same parameter profile). The advantage of this approach is that Ada's Unchecked_Conversion procedure can (hopefully) be used to convert a pointer of one instance of these task types to another. By converting a task access from one type to another, the same calls to the entry can be used to "simulate" the overwriting or subclassing of one Ada/Xt "method" by another.

Other Ada/X vendors have taken a different approach for implementing this callback scheme. Instead of using access to task types, they use pointers to Ada procedures. Since there is no such thing as an access pointer to an Ada subprogram, they use the ADDRESS attribute of the procedures as the values to place and adjust within widget "methods". For example, some of the STARS-based bindings uses a generic callback package, where the "action" routines are passed into it as a generic procedure parameter. The work involved to overwrite default methods will require passing system.addresses around as further parameters. There is a single dispatch subprogram that deals with the "methods", that centralizes where these callbacks are handled. As anyone who has programmed in C/Xt can tell you, a variety of terrible things will happen if these pointers become corrupted or set incorrectly.

Another issue to check for in an Ada/X binding is the support for Motif's User Interface Language (UIL). A number of UIMS tools (both Ada and C) will generate UIL in addition to or as a replacement for generated Ada code to an API. This is a more abstract interface to X, but many of the same Ada application program binding issues discussed above remain.

Standardization issues

Most Ada/X binding developers agree that there needs to be some sort of standards group responsible for just the Ada bindings to the rest of X. But as with the general C/X community, there has been a general lack of progress in developing formal standards (in contrast to de facto standards) in this area. As the vendors listed above generate Ada/Xlib, Ada/Xt, Ada/UIMS, and other specifications, someone needs to transition these specifications to a standards group to be maintained. The incompatible Ada/X systems (differing on even comparatively simple decisions, such as Ada naming conventions) are examples of what can go wrong for the entire Ada/X community that hopes for portability and reusability of software if too many incompatible bindings are developed. The X Window System levels (within the stack architecture) are all in a state of flux as new technical improvements are being added almost continuously. Each of these changes might be implemented differently by the binding developers, hurting overall Ada/X portability. These changes to C/X (at least) are beginning to be controlled by a series of standards groups; some are American National Standards Institute (ANSI) groups (such as X3H3) and some are Institute of Electrical and Electronic Engineers (IEEE) groups, such as POSIX committee P1201.

But progress is slow at the C/X level as well, with Ada/X viewed as an effort that must follow these standards. The use of language-independent specifications (LIS), as has been done in POSIX P1003, would aid an Ada/X binding to underlying X Window System services. But progress to an X, Motif, or OL LIS has been very slow.

Currently there are no clear plans on how (or who) to set up an Ada/X standards group. Any Ada standardization group would be within the structure of an existing standards group; there is no point in creating some all-new group just for Ada bindings. This means that the Ada group would have to conform to practices being used by its related groups. For example, the POSIX P1201 committee is looking specifically at creating industry standards for X, so it could be a good place to form a subcommittee for dealing just with Ada bindings. POSIX already has a subcommittee that deals with just Ada binding standards to the base operating system (P1003.5), so Ada language-specific bindings are not new to POSIX.

One issue to consider in the timing of the formation of any Ada/X binding standardization group is the progress being made by the related standards groups. In POSIX, the trend is toward the development first of an LIS for the functionality of some system; with language-specific bindings then developed on top of this standard. For X, this trend leads to some confusion because there are different groups working on different standards (at different rates of completion) for the various layers of X.

At the base of the X Window System is the X protocol defining the bits and bytes that are passed between client and server. The ANSI X3H3.6 subcommittee has developed a standard. Since this protocol layer is well below what any Ada application program would have to deal with (with the possible exception of the Rational Ada/Xlib implementation) and since most other Ada/X bindings abstract away this layer by dealing with the X Window System only through higher layers, there may be no need for an Ada-specific binding standard at the protocol layer.

The next layer up is Xlib. The development of the functionality (specification of behavior) is done by the Athena Consortium itself, with no formal standards group yet responsible for creating the formal standard. A problem has arisen here in that the Athena Consortium wants to hold off any standardization (in C, Ada, or anything else) at the Xlib layer until they have come up with a solution to the tricky problem of "internationalization" (the support of non-Roman alphabets such as Kanji, Hangul, Arabic, and Hebrew).

When moving above Xlib, an Ada programmer moves into X toolkits, widget sets, and controversy. While the X community has settled on using the Xt intrinsics, the widget sets and "look and feel" issues remain highly competitive. POSIX P1201.1 and others are trying again with a very high-level abstract interface known as the Virtual Application Programming Interface (VAPI) that was developed for the XVT commercial virtual toolkit that claims conformance to almost any windowing system (including Motif; and OL). Some progress has been made in developing an Ada/XVT binding.

The Ada/X community will have to address the widget-set issue at some point. The X application development community seems to be lining up behind commercial widget sets such as Motif's and OL's, with older and smaller widget sets such as the Athena and Xray sets falling into disuse. In addition to the size of these commercial widget sets (Ada bindings and/or implementations are a major undertaking), there are nasty copyright and "commercial advantage" issues to consider.

Another standardization issue to consider is the moving targets being standardized to. The original STARS Foundations Ada bindings were to X11R2; the final STARS Ada/Xlib bindings are to X11R4; and a number of commercial Ada/X bindings support X11R5. Also, there are already rumored plans for future X11 releases (that will include threads, where Ada tasking can really make an impact). The commercial widget sets are also moving targets (such as Motif versions 1.1, 1.2, 2.0, etc.). Note that the commercial X vendors do not always release their products in synchronization with the latest Athena Consortia releases. (Motif was stuck at X11R3 for a while after X11R4 was released.)

Another question that Ada/X developers should consider is how they should deal with the National Institute of Science and Technology (NIST) Federal Information Processing Standard (FIPS) on user interface models (FIPS 158). NIST has defined a seven-layer reference model (patterned after the Open Systems Interconnection - OSI - network reference model) that is used to organize standards. FIPS 158 defines a user-interface reference model that is closely patterned after the X Window System's architecture "stack":

FIPS 158 model X11 reality

application application

dialog UIMS

presentation ?

toolkit widgets

subroutine foundation Xt intrinsics

subroutines Xlib

byte stream X protocol

Another standardization issue to consider for FIPS 158 and Ada bindings are the extensions being made to the X Window System by various developers and researchers. For example, the Programmer's Hierarchical Interface for Graphics Systems (PHIGS) Extensions to X (PEX) defines functionality that some programmers will need but which lie outside the traditional X Window System "reference model". The Ada/PHIGS binding has already gone through its standardization effort.

    Previous Section          Table of Contents          Next Section

                                Keyword Search