System calls

Overview
NTX calls
High-level (validating) calls
Low-level (non-validating) calls
C/C++ calls
RT services (deprecated)
TCP/IP calls
PCI calls
Registry calls
Serial Communication (COMM) calls
INtimeDotNet calls
INscope calls
Input/Output calls
Structures

Overview

Several types of calls exist, and each kernel exchange object has calls of one or more type associated with it:

Real-time (RT) calls: The RT kernel uses these calls to run the RT portion of INtime applications and communicate with Windows. INtime software provides two levels of system calls for RT kernel exchange objects:
- High-level (validating) calls: Write, test, and debug your application using high-level calls with their protection and validation features.
- Low-level (non-validating) calls: Use low-level calls where there is no other choice, such as where a semaphore or a mailbox must be used with an interrupt handler.
RT services: INtime real-time applications (RTAs) which process messages from a user and events from an interface, and the service handlers required to perform service-dependent functions of the system calls.
Windows extension (NTX) calls: Windows uses these calls to communicate with the INtime kernel. NTX calls allow Windows applications to operate on objects created by, stored in, and controlled by the RT kernel.

RT kernel objects provide these RT call levels:

Object	NTX	High level	Low level
Distributed System Management (DSM)	X	X
Exception handling		X
Interrupts		X
Mailboxes	X	X	X
Message queues	X	X
Memory management	X	X
Object directories	X	X
Ports	X	X
Processes	X	X
Regions		X
Scheduler			X
Semaphores	X	X	X
Status	X	X
System data	X
Threads		X
Time management		X	X

Regarding INtime software system calls:

System call names correspond to related Windows functions, where appropriate. Where it is confusing to associate the function of an INtime software object with a Windows object, the names reflect the difference.
For example, no Windows object corresponds closely to an INtime software region, so these are left as regions. On the other hand, INtime software alarms are encapsulated as an object which somewhat correspond to a specialized Windows event object, so this is called AlarmEvent. It does not, however, perform all the same functions as a Windows event.
To avoid confusion with similarly-named Windows calls, INtime software system call names usually include the letters "Rt".
RT kernel objects and the kernel interface which differ substantially from corresponding items in the other INtime software layers, include a "kn" prefix to indicate calls that map to low-level RT kernel functions and deal with low-level kernel objects.

NTX calls

NTX calls allow Windows applications to operate on objects created by, stored in, and controlled by the INtime kernel. This allows Windows and INtime applications to communicate and coordinate their activities.

Handle conversion

The NTX DLL converts in transit NTXHANDLES sent to the RT kernel to RTHANDLES, and vice-versa. This is necessary as the RT kernel cannot operate on NTXHANDLES and NTX can't operate on RTHANDLES.

If a handle passes from RT to Windows in data, ntxImportRtHandle must convert it. Object directories and object mailboxes are converted automatically.

For a complete list of NTX calls, see NTX calls.

High-level (validating) calls

High-level calls provide higher protection and validation features. Memory is allocated automatically from the process's pool. Each high level object consumes a slot from the system GDT (8000 objects maximum).

High-level system calls validate a call's parameters; a condition code returned by the call indicates whether you used invalid parameters. Condition codes for trying to read or write memory to which you have no access also exist.

High-level exchange objects validate parameters and are protected against unexpected deletion. High-level calls exist for these exchange objects:

Object and data mailboxes
Counting semaphores
Regions (for mutual exclusion with priority inversion protection)

For a complete list of high-level calls, see High-level calls.

Low-level (non-validating) calls

Low-level calls provide higher performance, but lower protection and validation features. Low-level objects provide functionality beyond that of high-level objects.

You must allocate memory for low-level objects and may allocate memory beyond low-level object needs. You can use this additional memory to store application-specific state information associated with the object.

Low-level objects are not protected against unexpected deletion and do not validate parameters (if you need parameter validation, use high-level system calls). Low-level calls use the flat, 4 Gbyte addressing capabilities of the microprocessor. They do not use segmentation. Therefore, they do not consume a slot from the system GDT.

Use low-level objects in these situations:

For isolated parts of the application, such as signaling ordinary threads from an interrupt handler.
When performance is critical, such as high-performance, unvalidated sending and receiving of data mailbox messages and semaphore units.