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
Interoperating Between Programming Environments
Open System Services Porting Guide—520573-006
5-15
Design Considerations and Steps
the SYSTYPE pragma to direct the compiler to generate code appropriate for each
environment. Specify SYSTYPE OSS for OSS modules and SYSTYPE GUARDIAN for
Guardian modules. Using mixed-module programming should be minimized because
of the knowledge required to keep code easier to maintain.
The SYSTYPE pragma also defines the appropriate feature-test macros for each
environment. Feature-test macros and pragmas are discussed more in OSS C
Programming Considerations on page 7-10. More information about mixed-module
programming can be found in the C/C++ Programmer’s Guide.
Design Considerations and Steps
When designing mixed-module programs, the first task is to decide on whether your
program will run as an OSS process or a Guardian process. Guardian objects are
manipulated from the Guardian module and OSS objects are manipulated from the
OSS module. If the majority of a program’s code uses the resources of and
manipulates objects in the Guardian environment, consider writing the program as a
Guardian process. Likewise, if the majority of a program’s code uses the resources of
and manipulates objects in the OSS environment, consider writing the program as an
OSS process. Other factors, such as the availability of resources and services unique
to each environment, can also influence your decision.
After deciding on the environment in which a program runs, choose a development
environment. The development environment is the environment in which you compile,
link, and optimize (or accelerate) the program. While you can develop a program in
one environment that runs in the other environment, it is easier to develop a program in
the environment in which will run.
After choosing the development environment, you can begin writing the program. Write
the program’s main() function in the environment in which the process runs; write
code for the other environment only when necessary, and then place it in separate
modules.
For TNS interpreted and accelerated programs, both Guardian and G-series OSS
modules must use the 32-bit (or WIDE) data model and the large-memory model (the
size of a pointer and type int is 32 bits). For TNS/R and TNS/E native programs, both
Guardian and OSS modules use the same data and memory models, so there is no
concern for mixing different models.
Mixed-Language Programming
The Common Run-Time Environment (CRE) coordinates many run-time tasks on
behalf of the run-time libraries, thus providing a common environment for all routines in
a program, regardless of language. The CRE provides services that significantly
enhance your ability to create mixed-language programs.
Note. You must compile Guardian and OSS modules separately (on the command line, not in
source code). The c89 utility cannot compile two modules with different SYSTYPE values.