gtpa2m0vApplication Programming

E-Type Program Chart and Program Attributes

Figure 6 shows the kinds of E-type executable programs in the TPF system. A description of the attributes and characteristics of these programs follows the figure.

Figure 6. Kinds of E-Type Executable Programs


Load Module Attributes

This section describes some of the attributes of the various kinds of load modules. 1 Unlike classic TPF segments, load modules are link-edited (or bound). In general, load modules may include a variety of object files, which may be compiled or assembled from source code written in:

The build script of the load module specifies the type of load module (DLM, LIBRARY, or DLL) and the object files (but not the source language or compiler options) that the load module contains. The system initialization program (SIP) macro, SPPGML, specifies the source language and some of the compiler options, including RENT, NORENT, DLL, and NODLL, for TPF source code.

The primary distinction among the kinds of load modules is the kind of startup object file that is linked into them. The three main types of load modules are: applications (DLMs), run-time (nondynamic) libraries, and DLLs, each with its own separate startup object file. This determines many of their other attributes and ways that the TPF system handles them. The kind of load module is specified by the keyword in the first noncomment line in its build script. See ISO-C Load Module Build Tool (CBLD) for more information about build scripts.

A secondary distinction concerns the name of the entry point function that is called first when an application (DLM) load module is run. This entry point function may either have the same name as the DLM or it may be named main. 2

Load modules that contain object files written in C and compiled with the DLL option or written in C++ are DLL applications because they have the capability of implicitly referencing functions or variables that are defined in DLLs. Run-time (nondynamic) libraries are more restrictive than other kinds of load modules in that they cannot be DLL applications: they cannot contain object files compiled from C++ source code or from C source code compiled with the DLL option.

Table 6 lists the attributes of the various types of load modules.

Table 6. Load Modules and Their Attributes

Type of Load Module and Attribute Application (DLM) Run-Time (Nondynamic) Library DLL
With non-main Entry Point Function With main Entry Point Function
Keyword for the first noncomment line in the build script DLM DLM LIBRARY DLL
Name of the startup object file CSTRTD CSTRTD CSTRTL CSTDLL
Allocator residency requirements File resident (FR), core resident (CR), or PRELOAD FR, CR, or PRELOAD PRELOAD FR, CR, or PRELOAD
Number of entry points one one one or more one or more
Contains a main function No Yes No No
Specification of entry points Function with same name as load module main function Specified by library interface script 1 Specified by the EXPORTALL compiler option, #pragma export directive, or _Export keyword 2
Name used by callers to call entry points DLM name DLM name Names declared in API header files Names declared in API header files
Linkage to entry points C function call syntax, or enter- or create-type C function or assembler macro 3 system function, declared in stdlib.h Library call stubs, AUTOCALLed into load module by prelinker or binder Resolved at run time either implicitly or explicitly
Linkage type of entry points C (requires extern "C" declaration in C++ source code) C (handled implicitly by the system function and TPF C run-time initialization code) C (requires extern "C" declaration in C++ source code C or C++
Can include assembler source code object files Yes Yes Yes Yes
Can include C source code object files compiled with the NODLL option Yes Yes Yes Yes
Can include C source code object files compiled with the DLL option Yes Yes No Yes
Can include C++ source code object files Yes Yes No Yes
Can call other executable E-type programs (using DLM call stubs) Yes Yes Yes Yes
Can call run-time library functions (using library call stubs) Yes Yes Yes Yes
Can explicitly access DLL functions and DLL variables using run-time library functions Yes Yes Yes Yes
Can implicitly call DLL functions and access DLL variables Yes (requires C source code compiled with the DLL option, or C++ source code) Yes (requires C source code compiled with the DLL option, or C++ source code) No Yes (requires C source code compiled with the DLL option, or C++ source code)
Can export DLL functions and variables No No No Yes
Notes:

1 The interface to run-time (nondynamic) libraries, including the library call stubs, is built by the LIBI offline program. See "Run-Time (Nondynamic) Library Function Linkage" for more information about run-time library linkage. For more information about the LIBI offline program, see "Library Interface Tool".

2 When a DLL is built, one of the prelinker or binder outputs is a definition side-deck, which contains information about the functions and variables that the DLL can export. When you build a DLL application, its build script specifies which definition side-decks are to be given as input to the prelinker or binder, which uses them to build the trigger functions that import DLL functions and variables.

3 A load module can use C function call syntax to enter another executable E-type program (either classic TPF segment or DLM) with a DLM call stub. DLM call stubs are created by the STUB offline program or by SIP (if STUB=YES is coded on the SPPBLD macro in SPPGML) and AUTOCALLed into the load module by the prelinker or binder. See "DLM Call Stub Generator" for more information about the STUB tool.

Classic TPF Segment

We use the term classic in this context to describe the TPF E-type segment that is written in basic assembler language (BAL) or TARGET(TPF) C language. Its characteristics are as follows:


Footnotes:

1
There are other types of load modules in the TPF system, but here we are discussing only real-time load modules.

2
A special case of DLM is an iconv translate table, which has its own unique entry point function naming convention.