Developing for Windows CE & Pocket PC

I have a new observation about the relationship between state of taskbar on a Window Mobile 5.0 device and the hardware buttons (atleast on Dell Axim x51). I have found that if taskbar is disabled by calling EnableWindow() or is hidden by ShowWindow(,SW_HIDE), the hardware buttons stop working. They don't launch their assigned applications.

Solution:
If there is a need to hide taskbar window, get its window handle and call MoveWindow() to change the location and size of taskbar window out of the viewable area.

For quite sometime I was looking for a USB webcam driver for my x86 development board. At last my wish has been fulfilled by Microsoft.

This driver has been "open sourced" (Microsoft Limited Permissive License) by microsoft. See here. The source code for the webcam driver is provided along with a sample application. It just worked fine on by development board. The driver works with webcams that support USB video specification. As soon as I plugged in the USB webcam on the host port, Windows CE popped up a message asking for the driver file path. I just entered the driver dll name as I had copied it into the \Windows folder.

You can try the driver and modify it to your needs. Atleast its worth trying....

Suppose you have a dll and it is loaded by two processes A and B and you want to share some dll data between these two processes.

One of the simplest ways to achieve this is by declaring a shared data segment in the dll. This makes sure that all processes loading this dll will have access to same data. This method provides full access to shared data information, hence no security.

Here is how you declare a shared data segment in the dll (generally at the top of the source file):

#pragma data_seg("SHARED")  // Start of shared data segment.
// Declare variables here
int iSharedData;
#pragma data_seg()          // End of shared data segment 

// The following statment instructs the linker to generate the shared data segment  
#pragma comment(linker, "/section:SHARED,RWS")

Even after adding mouse support, mouse pointer will not be visible until you add Cursor component (SYSGEN_CURSOR) from Catalog to your OS design. Easiest way to locate Mouse Cursor catalog item is to right-click on Catalog tree root, and click Find on the shortcut menu and type "cursor" text. It will most probably stop at Cursor item.

Otherwise in 5.0 Catalog tree, it is located at:

Core OS -> Windows CE devices -> Shell and User Interface -> User Interface -> Mouse

While building an Windows CE Operating System image for a target, one can specify the image so that it is built for flash. In this case bootloader doesn't copy the OS image to RAM but instead it directly jumps to kernel entry point function in flash. This is possible only if the flash media supports XIP (Execute In Place).

Sometimes it may be necessary to make a particular module A.exe run out of RAM even though the image is built for flash. This can be achieved by marking A.exe to be compressed while building the image. During execution kernel copies a compressed module to RAM, uncompresses it and then it is executed.

This is how the entry for A.exe will be in platform.bib file:

A.exe $(_FLATRELEASEDIR)\A.exe NK SC

Here SC specifies the A.exe is a Compressed, System file.

Remote Application Programming Interface or RAPI is a mechanism by which a desktop application can call routines on a windows ce or pocket pc device. There are many RAPI functions but one of the most powerful is CeRapiInvoke function. By using CeRapiInvoke function, your application can virtually do everything possible on the terminal.

For using CeRapiInvoke a dll targetted for the device needs to be created. This dll executes calls on the device on behalf of the desktop application. It can take parameters and can send back return values to desktop app. The signature of CeRapiInvoke function is:

HRESULT CeRapiInvoke( 
 LPCWSTR pDllPath, 
 LPCWSTR pFunctionName,
 DWORD cbInput, 
 BYTE* pInput,
 DWORD* pcbOutput, 
 BYTE** ppOutput,
 IRAPIStream** ppIRAPIStream,
 DWORD dwReserved
);

The dll is remotely loaded when CeRapiInvoke call is made by the desktop application. Then remote function with name pFunctionName is called. If value of ppIRAPIStream is NULL then the function is blocked and hence desktop application is blocked till the remote function returns.

I had a requirement to execute same code as in the IST function of a driver but when a different event is triggered elsewhere in the system. I tried to use WaitForMultipleObjects function for the new event along with the IST event in an array but it failed. Documentation says that only WaitForSingleObject function can be used to wait for the event that is triggered by the kernel. While looking for more information on the topic, I found this article by Mike Hall. It says that Windows CE has this restriction to ensure the upper bound on the time to trigger the event and time to release the IST. IST latency is thus guaranteed.

I solved this problem by creating another thread before IST function gets executed. The new thread has a WaitForSingleObject call to wait for the new event to get signalled. As soon as this new event is signalled, partial copy of the original IST code runs which is what I wanted.

If you are developing applications, drivers or platforms based Windows CE or Pocket PC, then this is a place to watch out. I am going to write about tips, tricks and internals of Windows CE and Pocket PC.

This is a start.