The iwin32 subsystem, provided as a parallel API to the INtime API, provides a Win32 API for the INtime kernel to make porting of existing Win32 applications easier. A subset of the Win32 functions is implemented, and some extensions are defined to handle INtime features such as interrupt handling and shared memory. The functionality of the subset is broadly similar to the Windows CE version of the Win32 API, since Windows CE and INtime have similar goals. Some groups of functions have been omitted where INtime does not require the functionality, such as with the GUI functions.
The elements covered by the iwin32 API include:
In addition a number of real-time extension (RTX) functions are provided where more real-time functionality is required; this includes functions for:
This topic also describes the iwin32x API, which gives access to real-time iwin32 objects from a Windows application, in much the same way that the NTX API gives access to INtime objects from a Windows application.
Iwin32 provides an alternative to the standard INtime API. Iwin32 includes a number of objects that are similar to INtime objects and some that are specific to iwin32; INtime also provides some objects for which iwin32 provides no interface and in that case API mixing may be used.
We now get to the situation that there can be more than one API choice for a specific function (for example: CreateSemaphore, CreateRtSemaphore or RtCreateSemaphore). All APIs can be mixed with the restriction that once a handle to an object is obtained with one particular API choice, that API must be applied to all uses of the particular handle. For example, if the handle is obtained with CreateSemaphore, you can use ReleaseSemaphore, WaitForSingleObject and CloseHandle but not ReleaseRtSemaphore, WaitForRtSemaphore and DeleteRtSemaphore. Further restrictions are explained in the paragraph on API mixing in the "iwin32 Design" topic.
iwin32 includes a number of functions useful for real-time applications or providing source compatibility with existing applications.
Description | Function calls |
---|---|
Physical memory functions map physical memory to virtual addresses, which may be required for access to hardware components. | RtGetPhysicalAddress RtMapMemory RtUnmapMemory |
Memory allocation, already available via malloc and free, includes these functions for compatibility. | RtAllocateContiguousMemory RtAllocateLockedMemory RtFreeContiguousMemory RtFreeLockedMemory HeapAlloc HeapFree HeapReAlloc HeapSize |
Real-time Shared Library (RSL) functions help in the use of RSLs at execution time (load-time use of RSLs does not require any functions). |
FreeLibrary GetModuleHandle GetProcAddress LoadLibrary |
Quick synchronization functions allow do-it-yourself synchronization without the expense of a system call. | InterlockedCompareExchange InterlockedCompareExchangePointer InterlockedDecrement InterlockedExchange InterlockedExchangeAdd InterlockedExchangePointer InterlockedIncrement |
These functions perform no action, but provide source compatibility with existing applications. | RtCommitLockHeap RtCommitLockProcessHeap RtCommitLockStack RtDisablePortIo RtEnablePortIo RtIsInRtss RtLockKernel RtLockProcess RtTranslateBusAddress RtUnlockKernel RtUnlockProcess RtUnmapSharedMemory |