Programming an application on a Compact 2013 device is done through API calls, where WIN32 is the C language API provided as the foundation for application development. You may think that we should say native application development as we are talking about C language, but remember that managed developers can also access the WIN32 API through the InteropServices facility inside the .NET Compact Framework.

Using the gearbox metaphor a native application may be represented as a gear that rotates on another gear which is the WIN32 API. If we extend this representation to a managed application we insert the .NET Compact Framework is inserted as an extra gear in the middle, as it relies on the WIN32 API for system services. The different application models are represented as gearboxes in Figure 19-1.

Figure 19-1: Native & Managed models as gearboxes

To understand the relationship between the gearbox metaphor and Real-time, imagine the quality of control you have on the bottom “WIN32 gear” from your top “Application gear”.  In a real gearbox the quality of control depends on mechanical gap between gears, if the gap is tight the control is perfect; if the gap is loose the control is approximate. Moreover if you add gears to the gearbox, gaps will be added as a consequence.

You know computers don’t rely on gears (if we except Babbage’s machine) but the notion of mechanical gap may be transposed in the notion of time gap in the sense: “variation in the time spent to achieve an operation”. A good example of an API with a variable time gap is the dynamic memory allocation, the response time of the WIN32 HeapAlloc( ) function to allocate a buffer depends on heap fragmentation. Therefore a developer concerned with time stability must consider dynamic memory allocation as a potential threat.

Another difference with mechanics is the vocabulary because developers in the computer programming domain don’t use the terms tight and loose. Instead the terms Hard and Soft Real-time are used. A Hard Real-time system does not show variations in its time response whereas a Soft Real-time system is expected to show response time variations. The terms Hard and Soft do not directly reflect performance and may not reflect its intended meaning properly to the developer and project manager who do not have experience with Real-time development. Perhaps using terminology such as Tight Real-time and Loose Real-time may give a better meaning of what we are talking about, see Figure 19-2 for an illustration.

Figure 19-2 Hard Real-time & Soft Real-time