Development | .NET Compact Framework

Running state machines based Win32/WinCE programs
Written by Jerome D  [author's bio]  [read 8273 times]
Edited by Derek

   

Page 1  Page 2 

Introduction

Many concurrent, distributed or real-time applications have to work closely 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.

Traditional 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 handler 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. Un-registering 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.

In UML StateWizard (An UML dynamic model tool for concurrent, distributed real time application development ); the procedure is defined as follows:

1. Hooking window messages

The following function MfcHookWnd() hooks a HWND object by sub-classing it, in the Windows sense that is by inserting its own window proc ahead of whatever procedure is there currently, usually AfxWndProc. [3]

class CEgnSubclassWnd: public CSubclassWnd

{

public:

CEgnSubclassWnd();

virtual ~CEgnSubclassWnd();

virtual LRESULT WindowProc(HWND hwnd, UINT msg, WPARAM wp,LPARAM lp);

LRESULT OnExtEvent(MSG& WinMsg);

};

CEgnSubclassWnd::CEgnSubclassWnd()

{

}

CEgnSubclassWnd::~CEgnSubclassWnd()

{

}

LRESULT CEgnSubclassWnd::WindowProc(HWND hwnd, UINT msg, WPARAM wp,LPARAM lp)

{

struct SME_EVENT_T* pExtEvent=NULL;

MSG WinMsg;

WinMsg.hwnd = hwnd;

WinMsg.message =msg;

WinMsg.wParam = wp;

WinMsg.lParam = lp;

LRESULT ret = 0;

switch (msg)

{

case WM_EXT_EVENT_ID:

// External event is triggered. App go to running state.

OnExtEvent(WinMsg);

break;

default:

break;

}

ret = CSubclassWnd::WindowProc(hwnd,msg,wp,lp);

return ret;

}

2. Dispatching events to state machines

Usually all applications (state machines) run at one thread only. However, state machine engine allows applications to be divided to several groups and the applications in each group runs at its separate thread at one time. The following Figure: Running State Machined Based Applications illustrates several groups of applications run at each group respective thread. At each thread, the state machine engine hooks a window which runs at this thread.

Figure: Running State Machined Based Applications

Next Page 

Back to .NET Compact Framework | [Article Index]