Many concurrent, distributed and real-time applications has to tightly co-work with other objects, which are called service providers. A service is formally specified by a set of primitives (operations) available to service users (applications). These primitives describe some action or report on an action taken by a peer component/entity to be performed. The service primitives can be classified into four categories: request, indication, response and confirm. [1]
This article describes how to run state machine application framework based Win32/WinCE programs using window message hooking technology.
Why run state machines based Win32/WinCE applications ?
It is natural to use state machines in modeling such applications, as an application that must sequence a series of actions, or handle inputs (responses and indications) differently depending on what state it's in, is often best implemented as a state machine.
State machine application framework is widely used for embedded systems development. Embedded system developers may use Windows platform as a modeling and simulation environment, so that software development and debug can commence long before a hardware prototype is available. In simulation environment, developer can design some simulator using Windows program as service providers. These simulators have identical interface with target service providers' interface. On target environment, developer may take little effort to integrate state machine applications with these service providers to real environment.
However, for Windows applications, in particular with the emerging of WinCE operation system for smart phone, PDA applications, such methodologies will become increasingly important as systems hardware and software become more complex, and as the systems themselves become more connected and distributed.
Tranditional State Machines implementation
A typical state machine thread works just like the following:
SmeRun()
{
do {
Wait for an external event which is posted to this running thread;
if ( the event is valid)
{
Dispatch this event to active applications and trigger state transitions.
} else break;
} while(1);
}
The disadvantage of this running mode is that we have to create an separate thread for state machine applications.
Hooking technique in Windows® Environments
Hooking in programming is a technique employing so called hooks to make a chain of procedures as a handler. Thus, after the handled event occurs, control flow follows the chain in specific order. New hook registers its own address as andler for the event and is expected to call the original handler at some point, usually at the end. Each hook is required to pass execution to the previous handler, eventually arriving to the default one, otherwise the chain is broken. Unregistering the hook means setting the original procedure as the event handler.
Hooking can be used for many purposes including debugging and extending original functionality, but also misused to inject (potentially malicious) code to the event handler. [2]
And since Windows-based applications are event-driven, hooking seems to be very interesting. In fact these applications do not make explicit function calls (such as C run-time library calls) to obtain input. Instead, they wait for the system to pass input to them. The system passes all input for an application to the various windows in the application. Each window has a function, called a window procedure, that the system calls whenever it has input for the window. If we hook the window messages, when service providers (other objects) post external events (with a type of specific Windows message) to this hooked window, state machine engine will get the event data and then dispatches them to the active state machine applications.
Comments