2.1 Ada Semantic Interface Specification (ASIS)
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.
There are two electronic mail forums for the ASISWG: The technical discussion address is ASISWG-Technical@sw-eng.falls-church.va.us. General non-technical subjects are discussed on ASISWG@sw-eng.falls-church.va.us. Both lists receive all announcements of ASISWG meetings. To add your address to these, send e-mail to ASISWG-Technical-Request@sw-eng.falls-church.va.us or to ASISWG-Request@sw-eng.falls-church.va.us 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 (archive.adaic.com). Please refer to Appendix B - Repository/Software-Reuse Library Information for directions on how to logon to the AdaIC's Internet host.
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 (archive.adaic.com)
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).
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:
The POSIX/Ada Binding Tutorial
A Prototype Implementation of the POSIX/Ada Binding
FSU POSIX/Ada Realtime Project
The Forest P1003.5 Implementation
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.
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 Resource Dictionary System
(IRDS)
Strategy for the ANSI/ISO Ada language binding to IRDS
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.
2.6 Portable Operating System Interface
for Computer
Environments (POSIX)
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.
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)
2.7 Programmer's Hierachical Interactive Graphics System (PHIGS)
2.8 Database Language SQL
2.9 X Window System
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.
Previous Section Table of Contents Next Section
Keyword Search