|
|
|
ApplicationShell(3) -- The ApplicationShell widget class
|
|
ApplicationShell is used as the main top-level window for an application. An application should have more than one ApplicationShell only if it implements multiple logical applications. |
|
atexit(3) -- register a function to be called at program termination
|
|
atexit() registers the function func to be called, without arguments, at normal program termination. Functions registered by atexit() are called in reverse order of registration. An atexit() call during exit processing is always unsuccessful. The number of registered functions should not exceed ATEXIT_MAX as specified in . When necessary, crt0() or dld.sl() (see crt0(3) and dld.sl(5)) re... |
|
|
audit_intro(3) -- Introduction to the DCE Audit API runtime.
|
|
This introduction gives general information about the DCE Audit Application Programming Interface (API) and an overview of the following parts of the DCE Audit API runtime: + Runtime services + Environment variables + Data types and structures + Permissions required |
|
close_secdef(3) -- security defaults configuration file routines
|
|
open_secdef opens the security configuration file /etc/default/security. This function must be called prior to calling get_secdef_str or get_secdef_int. close_secdef closes the security configuration file. get_secdef_str and get_secdef_int return the value of the specified parameter defined in the security configuration file. See the security(4) manpage. Programs using these routines must be compi... |
|
Composite(3) -- The Composite widget class
|
|
Composite widgets are intended to be containers for other widgets and can have an arbitrary number of children. Their responsibilities (implemented either directly by the widget class or indirectly by Intrinsics functions) include: + Overall management of children from creation to destruction. + Destruction of descendants when the composite widget is destroyed. + Physical arrangement (geometry man... |
|
Constraint(3) -- The Constraint widget class
|
|
Constraint widgets maintain additional state data for each child. For example, client-defined constraints on the child's geometry may be specified. When a constrained composite widget defines constraint resources, all of that widget's children inherit all of those resources as their own. These constraint resources are set and read just the same as any other resources defined for the child. This ... |
|
copydvagent(3) -- manipulate device assignment database entry for a trusted system
|
|
getdvagent, getdvagnam, and copydvagent each return a pointer to an object with the following structure containing the broken-out fields of an entry in the Device Assignment database. Each database entry is returned as a dev_asg structure, declared in the header file: struct dev_field { char *fd_name; /* external name */ char **fd_devs; /* device list */ mask_t fd_type[1]; /* tape, printe... |
|
Core(3) -- The Core widget class
|
|
Core is the Xt Intrinsic base class for windowed widgets. The Object and RectObj classes provide support for windowless widgets. |
|
crt0(3) -- execution startup routines
|
|
The C, aC++, and FORTRAN compilers link in the object file crt0.o for statically-bound programs to provide startup capabilities and environments for program execution. It contains startup code that must be linked using ld to every statically-bound program. In a dynamically linked program (the default method), the crt0.o object file is not used, and all actions normally associated with it are inste... |
|
crt0.o(3) -- execution startup routines
|
|
The C, aC++, and FORTRAN compilers link in the object file crt0.o for statically-bound programs to provide startup capabilities and environments for program execution. It contains startup code that must be linked using ld to every statically-bound program. In a dynamically linked program (the default method), the crt0.o object file is not used, and all actions normally associated with it are inste... |
|
crt0.o_ia(3) -- execution startup routines
|
|
The C, aC++, and FORTRAN compilers link in the object file crt0.o for statically-bound programs to provide startup capabilities and environments for program execution. It contains startup code that must be linked using ld to every statically-bound program. In a dynamically linked program (the default method), the crt0.o object file is not used, and all actions normally associated with it are inste... |
|
crt0.o_pa(3) -- 64-bit ELF uses crt0.o only
|
|
PA-RISC 32-bit SOM The C, Pascal, and FORTRAN compilers link in the object files crt0.o, gcrt0.o, or mcrt0.o to provide startup capabilities and environments for program execution. All are identical except that gcrt0.o and mcrt0.o provide additional functionality for gpro profiling support respectively. The following symbols are defined in these object files: _environ An array of character pointer... |
|
crt0_ia(3) -- execution startup routines
|
|
The C, aC++, and FORTRAN compilers link in the object file crt0.o for statically-bound programs to provide startup capabilities and environments for program execution. It contains startup code that must be linked using ld to every statically-bound program. In a dynamically linked program (the default method), the crt0.o object file is not used, and all actions normally associated with it are inste... |
|
crt0_pa(3) -- execution startup routines; PARISC
|
|
PA-RISC 32-bit SOM The C, Pascal, and FORTRAN compilers link in the object files crt0.o, gcrt0.o, or mcrt0.o to provide startup capabilities and environments for program execution. All are identical except that gcrt0.o and mcrt0.o provide additional functionality for gpro profiling support respectively. The following symbols are defined in these object files: _environ An array of character pointer... |
|
cr_close(3) -- close a crash dump descriptor
|
|
The cr_close() function closes the crash dump descriptor structure pointed to by crash_cb. The crash_cb structure is a crash dump descriptor filled in by a cr_open(3) call. All associated resources (memory and files) are released. |
