6    Overview of the DIGITAL UNIX Programming Environment

The DIGITAL UNIX and ULTRIX programming environments are similar and most of the tools in the DIGITAL UNIX programming environment are the same as the ULTRIX equivalent tools. However, some differences exist. This chapter is an overview of those differences, in the following categories:

• Alpha architecture

• Graphical programming environment

• Software development tools

• Other programming tools

• Source file control

• Product installation tools

• Shared libraries

• Standard application programming interfaces (APIs)

• Network programming software

• Distributed services programming software

• Internationalization features

• Event-logging software

• Security

• Curses libraries

6.1    Alpha Architecture

To take advantage of the Alpha architecture, the DIGITAL UNIX programming environment differs from ULTRIX in the following areas:

• Data representation

• Data access

• Data alignment

• File system

These changes, described in the following sections, can affect how a program accesses and manipulates data.

6.1.1    Data Representation

The DIGITAL UNIX C data types have been modified and extended to include a 64-bit type. Table 6-0 shows the differences in data types between the ULTRIX and DIGITAL UNIX environments.

Table 6-0:  C Language Data Types

Data Type	32-Bit MIPS or VAX System (Size in Bits)	64-Bit DIGITAL UNIX System (Size in Bits)
char	8	8
short	16	16
int	32	32
long	32	64
long long	Not available	64
float	32 (MIPS: IEEE single precision)(VAX: F_floating)	32 (IEEE single precision)
double	64 (MIPS: IEEE double precision)(VAX: G_floating or D_floating)	64 (IEEE double precision)
pointer	32	64

The major differences are that long is defined to be 64 bits; pointer is defined to be 64 bits, extending the address space; and long long, a new data type, is defined to be 64 bits. The long long data type offers the unique name for a 64-bit data type that might give additional interoperability between 32-bit and 64-bit systems.

Like the VAX and MIPS systems, the DIGITAL UNIX system uses right-to-left byte ordering (little endian) for integer types.

6.1.2    Data Access

Unlike the VAX and MIPS architectures, which allowed byte and word memory accesses, the Alpha architecture supports only memory accesses of longword (32 bits) or quadword (64 bits). Byte and word accesses are accomplished by multiple instructions, which load a longword or quadword, mask, and shift to get the desired entity. The lack of a single operation for byte and word access might produce incorrect results in cases where you are accessing adjacent byte or word entities in shared memory segments.

For instance, a multithreaded application or multiple processes that have access to adjacent byte data through shared memory or shared memory-mapped files will have to use thread mutual exclusion locking functions or semaphore locks, respectively, to avoid conflicts with accesses to adjacent byte or word data items.

Also, the order in which write operations occur can be different from what the programmer intended. If it is important to guarantee the order in which data is written to memory, use memory barrier instructions.

6.1.3    Data Alignment

On both MIPS and Alpha systems the data alignment is implied by the data type. For instance, an int (32 bits) is aligned on a 4-byte boundary. On MIPS systems, a long (32 bits) is also aligned on a 4-byte boundary. But on Alpha systems, a long (64 bits) is aligned on 8-byte boundaries. If you are using assembly language, you will need to understand and code according to these alignment restrictions. If you are using a high-level language, such as C, the compiler will take care of this alignment for you. However, you need to understand these alignment differences when using long and pointer types in structure definitions that are shared between 32-bit and 64-bit systems.

6.1.4    File Systems

On the 32-bit MIPS and VAX systems, the maximum size of files and file systems was 2 gigabytes (GB). This limit was imposed by the programming interface and file system, which used a 32-bit integer to represent the file offset in bytes (off_t) when navigating within a file or file system.

On a 64-bit Alpha system, you can now build much larger files and file systems. The off_t file offset is defined to be a long on Alpha systems, which is 64 bits in length. Given this extended capability, it is possible to build files and file systems that cannot be fully accessed by 32-bit systems. You need to keep this in mind when working in a distributed environment where file systems are shared between 32- and 64-bit systems.

6.2    Graphical Programming Environment

The DIGITAL UNIX DECwindows Motif windowing environment is based on the industry-standard OSF/Motif Version 1.2.3 graphical user interface, featuring three-dimensional visuals and consistent operation and style. The ULTRIX and UWS OSF/Motif graphical interface is based on Version 1.2.2 of OSF/MOtif. Because OSF/Motif Version 1.2.3 does not include new features, there should be no migration issues between the ULTRIX and UWS and DIGITAL UNIX system programming environments. However, the DECwindows XUI interface available on ULTRIX systems is different from the DIGITAL UNIX interface. The following sections discuss these differences.

The DECwindows Motif programming environment provides libraries and tools for developing graphical applications for workstations. This graphical programming environment includes:

• Xlib

  This is the DIGITAL implementation of the Massachusetts Institute of Technology's X Window System, Version 11, Release 5, library provides low-level routines for performing basic windowing functions such as display; graphics; event handling; and text, font, and cursor manipulation. DIGITAL has extended Xlib to provide routines for the Display PostScript System. This extension allows applications to display images by calling functions that send PostScript code.

  For more information on programming with Xlib, see the book X Window System, published by Digital Press. The Display PostScript System documents are contained in the /usr/share/doclib directory.

• X Toolkit (also called the Intrinsics)

  A library of routines that creates and manipulates interface objects called widgets.

  For more information on programming with the X Toolkit, see the book X Window System, published by Digital Press.

• Motif Toolkit

  A collection of widgets and gadgets for building Motif applications; similar to the XUI Toolkit for building XUI applications on ULTRIX systems. Includes the User Interface Language (UIL), a presentation description language that simplifies the creation and customization of an applications's user interface. DIGITAL extends the Motif Toolkit by providing additional widgets for help, color mixing, printing, compound strings, and structural visual navigation.

  For more information about programming with the Motif Toolkit, see the OSF/Motif Programmer's Guide manual and the DECwindows Motif Guide to Application Programming manual. For more information about DIGITAL extensions to the Motif Toolkit, see the DECwindows Extensions to Motif manual.

Creating graphical applications for the DECwindows Motif environment is similar to creating applications for the XUI environment. Programmers who are experienced in developing XUI applications or who are porting existing XUI applications to Motif should note the following differences:

• Name changes--For widget classes, functions, resources, enumeration literals, callback reasons, compound strings, and fontlists.

  See Appendix F for a list of the names for these components.

• Window managers--Motif uses the Motif Window Manager (mwm); XUI uses the DECwindows Window Manager (dxwm). The window manager provides functions for moving and resizing windows on the workspace. The Motif Window Manager works with the toolkit to manage the operations of windows on the screen.

  Terminology differences exist between XUI and Motif. Window functions such as changing the size, shape, or location of a window can be done as Window menu items in Motif. In XUI, these functions are activated by clicking on window manager buttons or borders.

  For a summary of terminology and windowing differences, see Appendix E.

• Style changes--Menu items that appear in the File, Edit, and Help menus are different in the Motif interface. Motif also provides accelerators for each menu item and provides different default mouse button bindings.

  For a summary of these differences, see Appendix E.

For information about how to design Motif compliant applications, see the OSF/Motif Style Guide manual and the DECwindows Companion to the OSF/Motif Style Guide manual.

For more complete information about porting XUI applications to Motif, see the Porting XUI Applications to Motif manual.

6.3    Software Development Tools

Like ULTRIX systems, DIGITAL UNIX systems have a variety of software development tools. You can use these tools as you port applications to a DIGITAL UNIX system, as well as when you develop new applications on a DIGITAL UNIX system.

This section gives an overview of the following DIGITAL UNIX software development tools, highlighting differences from the ULTRIX software development tools:

• C preprocessor

• C compiler

• Linker

• Debugging tools

• Other programming tools, including ar, cflow, ctags, cxref, dis, file, lex, lint, make, nm, odump, pixie, prof, pixstats, size, stdump, strip, and yacc

This section gives an overview of only the DIGITAL UNIX C preprocessor and C compiler, because they are part of the DIGITAL UNIX product. In addition, other compilers, such as DIGITAL Fortran and DIGITAL Pascal, are available for use on the DIGITAL UNIX system.

Note

The ULTRIX RISC programming environment for Version 4.3A and higher systems use the MIPS Version 3.0 compilation system, as does the DIGITAL UNIX system. Earlier versions of ULTRIX RISC programming environments were based on the MIPS Version 2.10 compiler.

6.3.1    The C Preprocessor

The C preprocessor (cpp) on DIGITAL UNIX systems is similar to the preprocessor (cpp) on ULTRIX systems. Like the ULTRIX preprocessor, the DIGITAL UNIX preprocessor interprets directives, such as #include and #define. The syntax for specifying directives is the same as the syntax on ULTRIX systems.

The DIGITAL UNIX system defines a number of preprocessor symbols. Some of these symbols are different from the equivalent symbol on an ULTRIX system. For information about DIGITAL UNIX predefined symbols, see Section 7.4.1.

6.3.2    The C Compiler

Like the ULTRIX C compiler driver, the DIGITAL UNIX C driver performs several tasks. You can enter the cc command to run the C preprocessor, the C compiler, or the linker. Normally, you use the cc command to run all three tools and to compile and link your application. Like most ULTRIX C compilers, the DIGITAL UNIX C compiler supports optimizing code. In addition, the compiler supports DIGITAL UNIX features, such as linking with shared libraries and creating function prototypes. (For more information about the features and general use of the compiler, see the Programmer's Guide.)

For compatibility with ULTRIX compilers, the DIGITAL UNIX compiler supports several modes for compiling applications. You choose which mode the compiler operates in by using one of the following command-line options:

For information about using these options to compile ULTRIX programs on DIGITAL UNIX systems, see Section 7.4.

Many applications written for the ULTRIX programming environment will compile with no changes. However, there are certain behaviors that are present in the ULTRIX system that are not in the default DIGITAL UNIX system. Most of these behaviors will not be caught at compile time but will instead cause an application to fail when it is run.

The DIGITAL UNIX system is written using a hierarchy of interfaces and definitions. Using the default interface, -D_OSF_SOURCE, applications will be able to make use of all the features specified by the OSF Application Environment Specification (AES). If other specific operating system environments are needed, you can use the following symbols:

• -D_OSF_SOURCE

• -D_AES_SOURCE

• -D_XOPEN_SOURCE

• -D_POSIX_SOURCE (for maximum portability of your application)

• -D_ANSI_C_SOURCE

• -D_BSD

For example, applications needing a fully POSIX-conforming environment should be compiled with the -D_POSIX_SOURCE compiler switch. Applications needing a strict ANSI-conforming environment should be compiled with the -D_ANSI_SOURCE and -stdl compiler switches.

6.3.3    The Linker

In most instances, you can use the compiler to link separate application object files into a single executable application.

As part of the compilation process, compiler drivers call the linker, ld, to combine one or more object files into a single application object file. The linker's operation is essentially similar on the two systems; the most important difference is that by default the DIGITAL UNIX linker links with shared libraries; the ULTRIX system does not support shared libraries. The DIGITAL UNIX linker resolves external references, searches libraries, and performs all other processing required to create object files that are ready for execution. The resulting object module can either be executed or can serve as input to a separate ld command. (You can invoke the linker separately from the compiler by entering the ld command.)

The DIGITAL UNIX linker also supports C++ automatic constructors and destructors, and new options.

On DIGITAL UNIX systems, you normally use the linker to create shared libraries. For information about using and creating shared libraries, see Chapter 8. To link your application with shared libraries, use the appropriate compiler driver. To inhibit linking with shared libraries, use the driver's -non_shared option.

Because the DIGITAL UNIX environment is a 64-bit environment, the linker, by default, loads the program text and data in the high 64-bit virtual address space of the process (between 0xFFFFFFFFFFFFFFFF and 0x0000000100000000). As a result, there are no addresses accessible with a 32-bit address. If your source code contains any unintended pointer truncations, they will trap into the kernel and cause a run-time error. You can change this default behavior by using the -T or -D options to change the text and data segment origin, respectively.

6.3.4    The Debugger

The primary debugging tool on DIGITAL UNIX systems is dbx, which is a source-level debugger. This debugger is the same tool that is available on ULTRIX systems, and you can use it the same as you used the ULTRIX dbx. The differences between the DIGITAL UNIX and ULTRIX versions of dbx are that the DIGITAL UNIX debugger has been enhanced to support debugging applications that are linked with shared libraries.

The ULTRIX window interface to dbx, which is dxdb, is not supplied on DIGITAL UNIX systems. If you develop software in a window environment, you can purchase and install the DEC FUSE product. DEC FUSE is a software development, analysis, and maintenance environment for programmers. DEC FUSE offers a set of tools with a DEC OSF/Motif user interface and graphics options in an integrated setting. DEC FUSE tools include an editor, a code manager, a program builder, a debugger, a cross-referencer, and a call graph browser.

DIGITAL UNIX systems also include another debugging tool, kdbx. The kdbx utility is an interactive, crash analysis and kernel debugging tool that replaces the ULTRIX crash program. As a kernel debugging tool, kdbx serves as a front end to the dbx debugger, and enables you to examine the running kernel or dump files created by savecore. The kdbx utility is also insensitive to version numbers, and can be customized and extended. For more information on the kdbx utility, see the Kernel Debugging manual.

6.3.5    Other Programming Tools

DIGITAL UNIX systems have other programming tools that are available on ULTRIX. These tools have been modified to support the ANSI C language dialect, shared libraries, and 64-bit data types. Otherwise, their use is the same as their ULTRIX equivalents.

The following list gives a brief description of each tool. (For more information about the tools, see the reference page for each individual tool.)

• ar

  Creates and maintains archive libraries. (You cannot use the ar command to create shared libraries. To create shared libraries, use the ld command as described in Section 8.1.4 and Section 8.1.5.)

• cflow

  Analyzes C application files (as well as yacc, lex, and assembler files) and builds a graph that charts the external references made in the application.

• ctags

  Creates a tags file that you can use with the ex editor. The tags file specifies the location of functions and typedef declarations in the specified set of C application files.

• cxref

  Analyzes a set of C application files and builds a cross-reference table. The table lists all the symbols used in the application.

• dis

  Disassembles object files into machine instructions.

• file

  Reads one or more files as input, performs a series of tests on the files, and determines their types.

• lex

  Generates a C language source file that matches patterns for simple lexical analysis of an input stream.

• lint

  Checks C application files for coding that is inefficient, not portable, or might cause errors. For example, this command finds unreachable statements, automatic variables that are declared and not used, and logical expressions that have a constant value.

• make

  Builds up-to-date versions of application programs. The make command updates the application program depending on whether the files used to build the program have changed. The make command updates the program only if the files used to build it have changed.

  DIGITAL UNIX also includes the ULTRIX make command. See Section 7.1 for information on using the ULTRIX make command.

• nm

  Displays symbol table information for object files and archive files.

• odump

  Displays information about an object file, archive file, or executable file. For example, you can use odump options to display an object file's header, defined symbols, or program regions.

• pixie and prof and pixstats

  The pixie command reads applications, partitions them into basic blocks, and counts the execution of the basic blocks. Use the prof command with the -pixie option to display pixie data. The pixstats command analyzes the output from pixie. These profiling tools are only supported with archive libraries. They cannot be used with shared libraries. Note that the pixstats command produces incorrect results on DIGITAL UNIX systems.

• size

  Displays the number of bytes required by each section of an object file, as well as the total number of bytes required by the object file.

• stdump

  Displays detailed symbol table information for an application or object.

• strip

  Strips the symbolic debugger information from an executable file.

• yacc

  Converts a context-free grammar specification into a set of tables that can be used by a simple parsing program.

6.4    Source File Control

Like the ULTRIX system, the DIGITAL UNIX system supports the Source Code Control System (SCCS). The DIGITAL UNIX system also supports the Revision Control System (RCS), which is an unsupported subset on the ULTRIX system. The SCCS and RCS utilities allow you to store application modules in a directory, track changes made to those module files, and monitor access to the files. The SCCS and RCS utilities on DIGITAL UNIX systems are the same as the SCCS and RCS you use on ULTRIX systems. For more information about SCCS and RCS, see the Programming Support Tools manual.

6.5    Product Installation Tools

Once you port your application to DIGITAL UNIX, you might want to create a software package for it, for distribution to other users. Like ULTRIX systems, the DIGITAL UNIX system has utilities that you can use to install, remove, combine, validate, and configure applications.

To create a software package, you use the following utilities:

• newinv

  Processes a master inventory input file. The output of the newinv utility is a file that contains a list of all the files that compose your application. The file also contains information about the subset in which each file belongs. The newinv utility operates the same on DIGITAL UNIX systems as it does on ULTRIX systems.

• gentapes

  Produces magnetic tape distribution media (MT9 or TK50). This utility has the same features on DIGITAL UNIX and ULTRIX systems. The location of this utility has changed from /usr/sys/dist to /usr/bin on DIGITAL UNIX systems.

• gendisk

  Produces disk distribution media. On ULTRIX systems, the name of this utility is genra. The features of these utilities are the same. The location of the utility has changed from /usr/sys/dist to /usr/bin.

• kits

  Produces subset images, inventories, and control files from the input files that have been transferred from your source directory. The utility also generates data files that make up the media master in the output directory. This utility is the same on DIGITAL UNIX and ULTRIX systems.

• setld

  Installs software on the user's system. The setld command can install software from the following distribution media:

  • Data disks, including CD-ROM optical discs

  • TK50 tapes

  • MT9 tapes

  On a DIGITAL UNIX system, the setld command resides in the /usr/sbin directory. On an ULTRIX system, the command is in the /etc directory.

Unlike the ULTRIX setld command, the DIGITAL UNIX setld command does not install software into a Diskless Management Services (DMS) area. The DMS software is not provided on DIGITAL UNIX systems.

See the Programming Support Tools manual for descriptions of the program installation tools and the process of building setld-compatible kits.

6.6    Shared Libraries

The DIGITAL UNIX system provides shared libraries as part of the programming environment. Shared libraries are libraries linked in a file organized like a demand-paged executable program. Like other programs, the libraries contain data and text sections and export entry points or data objects. Multiple processes can use the entry points simultaneously or use the data objects (each process has a private copy of the data objects).

Unlike most programs, shared libraries contain no fixed-base address. Shared libraries contain symbol and relocation information. When you link your application with a shared library, the executable application does not contain the library routines; instead, the application contains the information it needs to load the shared library at startup time and to access the shared routines and private data at execution time.

The following shared libraries are elements of all DIGITAL UNIX systems:

The following shared libraries are also elements of all systems, but were not documented earlier in this manual:

Starting with DIGITAL UNIX Version 3.0, the following shared libraries are elements of all systems:

These libraries are located in the /usr/shlib directory.

In addition to shared libraries, the DIGITAL UNIX system provides archive libraries. Archive libraries are traditional ULTRIX libraries. When you link your application with them, the image for library routines you call is included in your application image. You can link DIGITAL UNIX applications to either the new shared libraries or the traditional archive libraries. To help you decide which libraries to use, this section describes some advantages of using shared libraries and some restrictions on using them.

For information on how to link your application with DIGITAL UNIX shared libraries and how to create shared libraries, see Chapter 8.

6.6.1    Using Shared Libraries

The following list details the advantages of using shared libraries on DIGITAL UNIX systems:

• Disk space savings

  When multiple applications use a shared library, you save disk space. If five applications use the same library image, the library image occurs only once on the disk. By contrast, if you link each process statically with a set of library routines, the image of the library routines occurs five separate times on the disk.

• System memory savings

  When multiple processes run applications that are linked with a shared library, you save physical memory. As with disk space, you see the memory savings when multiple applications use the same shared library.

• Reduced paging

  Like other routines, a shared library routine is read into memory the first time a process needs it. Because more than one process can use the image of the shared library routine, the second process that calls it might find the routine already in memory. If several processes are using the same routine, that routine tends to remain in memory. Thus, processes that use shared libraries often require less paging than processes that use archive libraries.

• Better application and system performance

  Using shared libraries improves the performance of your application when multiple applications use the same shared library routines. This situation often occurs on a typical multiuser system when multiple applications are using shared libraries. In addition to improving the performance of individual applications, this situation improves the overall performance of your system.

  However, benchmark applications linked with shared libraries might show a degradation in performance when compared to the same application linked with archive libraries. Benchmark applications normally run on an unloaded system, so your benchmark loses the opportunity to benefit from sharing library routines with other applications. In addition, on an unloaded system, the startup time for an application linked with shared libraries is somewhat slower than the startup time for an application linked with archive libraries. Run-time performance of your benchmark might be slower because references to symbols exported from a shared library are made indirectly. References to symbols in an archive library are made directly. Indirect references are somewhat slower than direct references.

6.6.2    Changing from Archive Libraries to Shared Libraries

Normally, you can use shared libraries in any application and create any library as a shared library. In most cases, the effect of using shared libraries instead of archive libraries should be transparent; however, a few restrictions on using and creating shared libraries do exist. The following list describes these restrictions:

• The /usr directory must be mounted when you run an application that is linked with shared libraries.

  If your application is designed to run when the /usr directory is not mounted, do not use shared libraries. When you link your application with shared libraries, your application executable does not include the shared library; it includes only information it needs to load the shared library. If the shared libraries are unavailable when you run your application, it fails.

• You cannot use -O3 or -O4 optimization options when you link your C application with shared libraries or when you create shared libraries.

  If you want to optimize your C application by using one of these options, you must link with archive libraries. (You might be able to optimize applications written in other languages that you link with shared libraries. For more information about linking applications written in languages other than C with shared libraries, see the documentation for the language you are using.)

• All code must be position-independent code when you create a shared library.

  You must recompile and link your code with a DIGITAL UNIX compiler in order to have position-independent code. Assembler code must also be written to be position-independent code, using the rules mentioned in the DIGITAL UNIX Calling Standard for Alpha Systems manual.

• Do not use profiling with shared libraries.

  The pixie and pixstats commands are supported only with archive libraries.

• Do not link shared libraries with archive libraries.

  Shared libraries should only depend on other shared libraries. Linking a shared library with an archive library could create conflicting references at run time, causing unpredictable program behavior.

• Applications might need to be modified when linking with shared libraries if they depend on specifics of the ULTRIX call frame or on run-time stack tracing of libraries.

  See the DIGITAL UNIX Calling Standard for Alpha Systems for specific information on changes.

• The stack version of the alloca() function is currently unusable in shared libraries.

6.7    Standard Application Programming Interfaces

In addition to making your source code portable with respect to applicable language standards, you must make your applications conform to specific application programming interfaces (APIs) in order to link correctly and produce correct results. The DIGITAL UNIX system supports the following APIs:

• Application Environment Specification (AES)

  AES is the specification to which OSF/1 Version 1.0 was built. Applications that use only the interfaces specified by the AES will compile and run successfully on all implementations of OSF/1 Version 1.0 and all compliant platforms.

• POSIX

  POSIX (IEEE Std 1003.1-1990; ISO/IEC 9945-1:1990(E)) describes run-time behavior and provides definitions for programming interfaces. It provides applications with the maximum portability across OSF/1 and other platforms. The DIGITAL UNIX system also meets the National Institute of Standards and Technology (NIST), Federal Information Processing Standards (FIPS) 151-1.

• XPG3 Base

  X/Open's XPG3 Base describes the definitions and run-time behavior for a set of interfaces. This standard extends beyond the POSIX standard to cover additional features in the X/Open environment.

• ANSI C

  The ANSI C language standard (ANSI X3.159-1989; ISO/IEC 9899:1990(E)), in addition to specifying a definition for the C programming language, contains definitions for the standard library functions.

• System V and BSD

  System V Release 3 (based on the System V Interface Definition (SVID) 2), System V Release 2, and BSD represent implementation standards and are available for applications that depend upon specific behavior unique to the System V and BSD environments.

  There are areas in which these implementation standard APIs conflict with the more formal standard APIs described earlier. You can resolve these conflicts by using the compiler and linker options described in Section 7.6.2 and Section 7.6.3.

6.8    Network Programming Software

The networking programming facilities available in the DIGITAL UNIX system provide a high degree of commonality and interoperability with the ULTRIX system. Both systems provide APIs, including X/Open Transport Interface (XTI), Data Link Interface (DLI), and sockets, as described in the following sections. In addition, DIGITAL UNIX provides support for STREAMS, which is compatible with System V Release 3.2 STREAMS.

6.8.1    X/Open Transport Interface

The X/Open Transport Interface (XTI) defines a transport interface for networking applications that is independent of any specific transport provider. The XTI design and implementation on DIGITAL UNIX are new. XTI applications are interoperable between ULTRIX and DIGITAL UNIX systems. XTI is similar to, and backward compatible with, the System V Transport Layer Interface (TLI). Libraries for both XTI (-lxti) and TLI (-ltli) are provided. See Section 7.8 and the Network Programmer's Guide for more information.

6.8.2    Data Link Interface

The Data Link Interface (DLI) defines a transport interface for networking applications on Ethernet and Fiber Distributed Data Interface (FDDI) networks. DLI applications are interoperable between ULTRIX and DIGITAL UNIX systems. On DIGITAL UNIX systems, the location of the dli_var.h library is /usr/include/dli/dli_var.h. In addition, the sockaddr_dl structure has a new field, dli_len, in the first byte. See the Network Programmer's Guide for more information.

6.8.3    Sockets Interface

Sockets are the end points of communication channels and are used much the same way as file descriptors are used. The socket interface provided by DIGITAL UNIX is compatible with the ULTRIX socket interface. See the Network Programmer's Guide for more information.

6.8.4    SNMP Compatibility

DIGITAL UNIX and ULTRIX both support the Simple Network Management Protocol (SNMP) Agent. The DIGITAL UNIX system does not support the ULTRIX Extended SNMP Agent for defining private Management Information Base (MIB) objects through a set of library routines. See Section 7.6.1 for more information.

6.9    Distributed Services Programming Software

This section discusses the following distributed services programming facilities:

• Remote procedure calling (RPC)

• Kerberos authentication service

• Berkeley Internet Name Domain (BIND) service

• Network Information Service (NIS, formerly YP)

• Hesiod naming service

6.9.1    Remote Procedure Calling

The ULTRIX system provides a general RPC mechanism, DEC RPC Version 1.0, which is based on and is compatible with the RPC component of the Hewlett-Packard/Apollo Network Computing System (NCS), Version 1.5. DIGITAL UNIX systems do not provide a development or run-time environment for DEC RPC Version 1.0. Specifically, the DEC RPC Version 1.0 components, which include the Network Interface Definition Language (NIDL) compiler, the Location Brokers (Local Location Broker and Global Location Broker), and the RPC run-time library, are unavailable.

DIGITAL UNIX and ULTRIX systems both provide the capabilities to interoperate with the Sun Microsystems ONC (Open Network Computing environment). DIGITAL UNIX systems also enable ONC RPC application development by providing a high-level set of operations that can be used to execute procedures on remote systems across a network. See the Programming with ONC RPC manual for more information on using ONC RPC.

As part of the Distributed Computing Environment (DCE), OSF has defined an RPC mechanism that integrates with the other DCE components (for example, Cell Directory Service and Global Naming - X.500). Components to support this mechanism are not part of the base DIGITAL UNIX product. See the DIGITAL DCE Starter Kit for these features.

6.9.2    Network Authentication

Kerberos is an authentication service that validates the identity of a user or service, preventing fraudulent requests. It provides a programming interface for authentication by applications communicating across a TCP/IP network with a socket interface. The ULTRIX system supports a version of Kerberos that is derived from MIT/Athena's Kerberos Version 4. No Kerberos programming interfaces are available on the DIGITAL UNIX system. Many binaries that were built with Kerberos on an ULTRIX system will run on DIGITAL UNIX systems when using an ULTRIX server, as long as the ULTRIX system is Version 4.2 or higher. See Section 7.6.1 and Section B.18 for more information.

6.9.3    Naming Services

The DIGITAL UNIX system supports both the Berkeley Internet Name Domain (BIND) service and the Network Information Services (NIS, formerly YP) service. Both of these services are interoperable between ULTRIX and DIGITAL UNIX systems. By itself, the BIND name service allows you to distribute a host naming database. The NIS service can distribute several different databases. BIND and NIS support equivalent functions in the run-time library.

The Hesiod service, available on ULTRIX systems, is not supported by the DIGITAL UNIX system. No Hesiod programming interfaces exist on DIGITAL UNIX systems. See Section B.18 for more information.

6.10    Internationalization Features

An internationalized application allows users to interact with that application in their native language. The application is also designed to reflect the culture of the user's region. For example, data such as dates and monetary values are displayed or read as input in the style of that region.

The DIGITAL UNIX internationalization features are compatible with the ANSI C, POSIX, and XPG4 specifications for an international programming environment.

In addition to the ULTRIX internationalization features, the DIGITAL UNIX internationalization features provide the following:

• Support for more locales

• Support for the LC_MESSAGES environment variable

• Internationalized library routines and system commands

Some differences exist between the ULTRIX and DIGITAL UNIX internationalization features. The following sections give an overview of the differences. For more information about the DIGITAL UNIX internationalization features, see Writing Software for the International Market and the i18n_intro command.

6.10.1    Message Catalog System

The message catalog system isolates program messages from the body of your program. This isolation makes it easier for you to translate messages into other languages. The message catalog system consists of message extraction tools, tools for translating messages, a tool for generating message catalogs, and routines for accessing message catalogs.

6.10.1.1    Message Extraction Tools (extract, strextract, and strmerge)

Like the ULTRIX system, the DIGITAL UNIX system provides the extract, strextract, and strmerge commands that extract message text from your program and store it in a message text source file. In most ways, these commands are the same as their ULTRIX equivalent. This section describes the two ways the commands differ between the DIGITAL UNIX and ULTRIX systems.

The output file name for the strextract command, and therefore the input file name for the strmerge command, is different. On DIGITAL UNIX systems the intermediate file that strextract creates is named filename.str. On ULTRIX systems, this file is named filename.msg.

The other difference is the name of the internationalization directory. On DIGITAL UNIX systems, related internationalization files are stored in the /usr/lib/nls directory. On ULTRIX systems, these files are stored in the /usr/lib/intln directory. This change affects the following:

• The location of the systemwide patterns file, which on DIGITAL UNIX systems is /usr/lib/nls/patterns.

• The location of the help file for the extract command, which on DIGITAL UNIX systems is /usr/lib/nls/help.

• The search path for user-specified patterns and ignore files. On DIGITAL UNIX systems, the extract, strextract, and strmerge commands search for patterns and ignore files in the current directory, your home directory, and then /usr/lib/nls.

6.10.1.2    Tool for Translating Messages (trans)

You can use the DIGITAL UNIX trans command to help you translate message text source files from one native language to another. This command is the same as the ULTRIX trans command.

6.10.1.3    Tools for Creating a Message Catalog (mkcatdefs and gencat)

The DIGITAL UNIX system provides the mkcatdefs and gencat commands, which work together to generate a formatted message catalog. Some system limits that affect the gencat command have increased on DIGITAL UNIX systems. See Table B--1 for complete information. Other than the difference in the system limits, the DIGITAL UNIX gencat command is the same as the ULTRIX gencat command. The mkcatdefs command is the same on both systems.

6.10.1.4    Routines for Accessing a Message Catalog (catopen, catgets, and catclose)

You use the DIGITAL UNIX catopen, catgets, and catclose library routines to open, read messages from, and close message catalogs. These routines are the same as the ULTRIX routines of the same names.

By default, these routines search the /usr/lib/nls/msg/%L /%N path for a message catalog. In the preceding pathname, %L represents the locale name specified by the LANG environment variable, and %N represents the name of the message catalog passed to the catopen function. Typically, the name of the message catalog is messages.cat.

The DIGITAL UNIX catopen routine differs from the ULTRIX catopen routine in two ways. First, the DIGITAL UNIX catopen routine does not search the current directory for message catalogs. The ULTRIX catopen routine searches the current directory for message catalogs it does not find in either the /usr/lib/nls/msg/%L /%N directory or the directories specified by the NLSPATH environment variable. Second, the DIGITAL UNIX catopen routine ignores the NLSPATH environment variable when it attempts to find a message catalog for the root user. The routine searches only the /usr/lib/nls/msg/%L /%N directory. This difference affects applications that use the setuid system call to become the root user.

6.10.2    Program Localization

Writing an international application involves more than isolating and translating program messages. The application must also reflect the culture of the user by displaying dates and times, monetary values, numbers, alphabetic lists, and so on in the style that the user expects. On DIGITAL UNIX systems (as on ULTRIX systems), the application behavior in these areas is controlled by the program's locale.

6.10.2.1    Announcement Mechanism

You control which locale an application runs in by defining environment variables. The environment variables announce to the system what local data the application should use.

The DIGITAL UNIX system provides the same environment variables as the ULTRIX system, with the addition of LC_ALL and LC_MESSAGES. The following list describes these environment variables:

• LANG controls all categories of an application's locale. However, you can override the setting of LANG by defining one of the environment variables that control a specific category ( LC_COLLATE, LC_CTYPE, and so on).

• LC_ALL controls all categories of an application's locale. Unlike LANG, you cannot override the setting of LC_ALL by defining one of the environment variables that control a specific category.

• LC_COLLATE controls the collation category of the application's locale. The collation category affects the operation of the strcoll and strxfrm library routines.

• LC_CTYPE controls the character classification category of the application's locale. This variable affects the operation of the isdigit and isalpha library routines, among others.

• LC_NUMERIC affects the radix and thousands separator character as it is used by the printf and scanf library routines.

• LC_TIME affects the behavior of the strftime library routine.

• LC_MONETARY affects what the strmon library routine returns as the format for monetary values.

• LC_MESSAGES affects the format of application messages and the string the user can specify to answer a yes or no question.

The only difference between these environment variables on a DIGITAL UNIX system and on an ULTRIX system is the naming convention used for the locales. For information about defining these environment variables, see Section 3.1.3.

6.10.2.2    The setlocale Routine

To determine what locale has been set, you call the setlocale routine in your program. This routine has the following format:

setlocale (category, locale)

The category argument specifies the category for which you are requesting locale information, that is, LANG, LC_COLLATE, LC_CTYPE, and so on. The locale argument is usually an empty string ( "" ) that causes the setlocale routine to determine the setting of a category by reading the corresponding environment variable. However, you can specify a locale name in this argument. If you do, be aware that the naming convention for the DIGITAL UNIX locales is different from the ULTRIX naming convention. For information about the names of DIGITAL UNIX locales, see the Technical Overview.

By default, setlocale expects the locale-specific data to be in the language support databases contained in the /usr/lib/nls/loc directory (the /usr/lib/intln directory on ULTRIX systems).

On ULTRIX systems, you can store the locale-specific data in a directory that is not in the default search path. You specify where the locale-specific data is by defining the INTLINFO variable. On DIGITAL UNIX systems you specify where the locale-specific data is by defining the LOCPATH variable.

Except for these differences, the setlocale routine is the same on DIGITAL UNIX and ULTRIX systems.

6.10.3    Creating Locale-Specific Information

On DIGITAL UNIX systems, you can create your own locale-specific information. Use the localedef command to process locale and character map files and produce a locale database. This command replaces the ULTRIX ic command. For information about using the localedef command, see localedef(1).

6.10.4    The iconv Command

Like the ULTRIX iconv command, the DIGITAL UNIX iconv command converts the encoding of characters in one codeset to another codeset. On DIGITAL UNIX systems, you can use iconv to convert between a number of character sets. The system provides conversion tables in the /usr/lib/nls/loc/iconv directory. For information about using iconv to convert codesets, see iconv(1).

6.11    Event-Logging Software

On DIGITAL UNIX systems, system events are recorded using two facilities:

• A systemwide event-logging facility, which logs events in ASCII format.

• A binary event-logging facility, which logs hardware and software events in the kernel in binary format records.

The binary event logging is like the binary error logging provided on ULTRIX systems. There are differences between the system logging facilities on ULTRIX and DIGITAL UNIX systems. Both the ULTRIX and DIGITAL UNIX systems provide a set of application interfaces for syslog. See Section B.16 for more information.

6.12    Security

The Security manual contains information about migrating a programming interface from ULTRIX to DIGITAL UNIX, including basic migration issues and ways to move ULTRIX authentication files to a DIGITAL UNIX system.

The DIGITAL UNIX system does not support the functions for getting and setting authorization entries in the auth database. See the discussion of secauthmigrate in the Security manual for more information. Additionally, Section B.18 contains a list of security-related header files that exist in ULTRIX but do not exist on a DIGITAL UNIX system.

6.13    Curses Libraries

The curses package is a set of cursor optimization routines for writing screen-management programs. ULTRIX and DIGITAL UNIX systems both support X/Open and BSD curses library routines. The capabilities in both of these libraries have been extended beyond what is available with Version 4.2 and Version 4.3 of the ULTRIX system. For example, the DIGITAL UNIX curses package provides multibyte character support.

ULTRIX applications will need to change references to header files and libraries. See Section 7.2, Section 7.7, and Section 4.7 for more information.