Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

system-managed swap files for native processes. The space guarantee attribute
(pe_space_guarantee) of a process can be used by KMSF to reserve space in system swap
files. If the requested space is not available at process creation, an error is returned and the process
is not started.
Native Shared Run-Time Libraries
Native shared run-time libraries (SRLs) are supported in the TNS/R native environment. TNS/R
native programs can use multiple public SRLs. The run-time libraries for C, CRE, and Open System
Services are shipped as separate, public SRLs. SRLs are loaded when a processor is started. The
installed set of public SRLs is available for use by all programs; public SRLs are loaded quickly,
because they are already open. Processes share SRL code in virtual memory, but each has its own
SRL instance data.
Dynamic-Link Libraries
Dynamic-link libraries (DLLs) are supported in the TNS/R and TNS/E native environments. They
provide the same functionality supported on other platforms throughout the industry. Like SRLs, DLLs
are loaded at process-creation time. However, unlike SRLs, additional DLLs can be dynamically
loaded into an executing process by using run-time calls. DLLs are composed of position-independent
code (PIC) and can therefore be addressed at different virtual addresses in different processes.
This allows multiple versions of a DLL to be executed. One copy of a DLL can serve multiple programs
and processes.
To create a DLL or create a program that uses DLLs in the TNS/R native environment, you must
specify a compiler option to create a PIC linkfile, then use the ld linker to produce a PIC program
or loadfile. In the TNS/E native environment, all code is PIC; therefore there is no need to specify
a compiler option to create a linkfile; you simply compile the program to create a linkfile, then use
the eld linker to produce a PIC program or DLL.
Signal Handling for Guardian Processes
Signal handling replaces the TNS form of “trap handling” for native Guardian processes. The
existing OSS signal-related functions, such as sigaction(), are available for native Guardian
processes, replacing the TNS trap-handling procedures, such as ARMTRAP. All signal-related
functions are supported in native Guardian processes except for kill(), because Guardian
processes do not have an OSS process ID. Signal handling for the TNS environment is unchanged.
The Guardian Programmer’s Guide discusses the signal-related functions available for Guardian
processes.
OSS and Guardian API Interoperability
Guardian and OSS API interoperability is provided by having similar OSS C and Guardian C
APIs. The C run-time library supports two variants of some functions that support different semantics
in the OSS environment than in the Guardian environment. These include fopen(), freopen(),
remove(), rename(), tmpfile(), and tmpnam(). Explicit calls to the rename_oss() and
rename_guardian() variants can be made in the source code when the behavior of one
environment is desired from the other environment. For details on using these calls, refer to the
reference pages either online or in the Open System Services Library Calls Reference Manual and
Open System Services System Calls Reference Manual.
C/C++ Development Tools
The TNS/R and TNS/E compilers for C and C++ produce native object files in the executable and
linking format (ELF). ELF is commonly used on UNIX systems and is an open standard that allows
extensions.
There are fewer steps involved in compiling code using the native development tools than using
the TNS development tools. With the native tools, the programmer can compile source files using
172 Native Migration Overview