Open System Services Porting Guide (G06.24+, H06.03+)
Table Of Contents
- What’s New in This Manual
- About This Manual
- 1 Introduction to Porting
- 2 The Development Environment
- 3 Useful Porting Tools
- 4 Interoperating Between User Environments
- Purpose of Interoperability
- The OSS User Environment
- OSS Commands for the Guardian User
- Guardian Commands for the UNIX User
- OSS Pathname and Guardian Filename Conversions
- Running the OSS Shell and Commands From TACL
- Running Guardian Commands From the OSS Shell
- Running OSS Processes With Guardian Attributes
- Using OSS Commands to Manage Guardian Objects
- 5 Interoperating Between Programming Environments
- 6 OSS Porting Considerations
- 7 Porting UNIX Applications to the OSS Environment
- 8 Migrating Guardian Applications to the OSS Environment
- General Migration Guidelines
- C Compiler Issues for Guardian Programs
- Using New and Extended Guardian Procedures
- Using OSS Functions in a Guardian Program
- Interoperating With OSS Programs
- Starting an OSS Program From the Guardian Environment
- C Compiler Considerations for OSS Programs
- Porting a Guardian Program to the OSS Environment
- How Arguments Are Passed to the C or C++ Program
- Differences in the Two Run-Time Environments
- Which Run-Time Routines Are Available
- Use of Common Run-Time Environment (CRE) Functions
- Replacing Guardian Procedure Calls With Equivalent OSS Functions
- Which IPC Mechanisms Can Be Used
- Interactions Between Guardian and OSS Functions
- 9 Porting From Specific UNIX Systems
- 10 Native Migration Overview
- 11 Porting or Migrating Sockets Applications
- 12 Porting Threaded Applications
- A Equivalent OSS and UNIX Commands for Guardian Users
- B Equivalent Guardian Commands for OSS and UNIX Users
- C Equivalent Inspect Debugging Commands for dbx Commands
- D Equivalent Native Inspect Debugging Commands for dbx Commands
- E Standard POSIX Threads Functions: Differences Between the Previous and Current Standards
- Glossary
- Index
Native Migration Overview
Open System Services Porting Guide—520573-006
10-3
Stack and Heap Sizes
•
Dynamic-Link Libraries on page 10-3
•
Signal Handling for Guardian Processes on page 10-4
•
OSS and Guardian API Interoperability on page 10-4
Stack and Heap Sizes
User processes initially can have a stack size of 1 MB (G-series) or 2 MB (H-series),
which can be specified by processes to be up to 32 MB. You can specify the maximum
value for the size of the stack, but it is given a default size when the process is first
created. The stack can grow in size dynamically. You can also specify a maximum
heap size value with the ld, nld, or eld utility or with the process-creation
procedures.
Both selectable and flat segments are supported in the native and TNS environments.
Only flat segments are available for native processes, and all flat segments are
available at the same time. Flat segments in TNS processes are allocated to a 32-MB
boundary, and a maximum of 13 segments may be allocated per process. For native
processes, flat segments are allocated to a 128-kilobyte boundary, with no practical
limit to the number of segments for each process.
Kernel-Managed Swap Facility (KMSF)
The Kernel-Managed Swap Facility (KMSF) is a method of managing virtual memory
for native processes. It allows a native process to use kernel-managed swap space
rather than a user-specified swap file. The global data, heap, main stack, and SRL or
DLL instance data are swapped to 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 have multiple public SRLs. The run-time
libraries for C, CRE, and Open System Services are shipped as separate, public SRLs.
Public SRLs are loaded when a processor is started. All programs automatically have
access to public SRLs. 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