Thursday, July 11, 2013

WaitForMultipleObjects

Please take care while using WaitForMultipleObjects

Today I was trying one of the example given by Microsoft on Windows CE. 

Basically the code is written for Windows Desktop and the code can be seen at the following URL: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686927(v=vs.85).aspx.

In the above given example the main function is creating two threads and waiting for the threads to close using WaitForMultipleObjects API. 

As this example is for desktop in WaitForMultipleObjects API the third parameter fWaitAll is set to TRUE.

I made some modifications such as printf is changed to RETAILMSG and on entry and exit of main, thread function we have enable more RETAIL Messages.

After running the application we are not seeing any messages that are being printed from the worker threads. All we see is the main function entry and exit messages.

After debugging, we came to know that fWaitAll in WaitForMultipleObjects API shall be set to FALSE in Windows CE 6.0.

Hope This Helps.

Monday, July 8, 2013

File Persistence Issue Faced With Compact 7

This post talks about one of the issue that is faced during implementing the File and Registry Persistence on eMMC with Windows Compact 7 OS.

Issue Faced: Whenever OS is updated using Boot-loader it is observed theat entire eMMC area is erased so that old peristence data is erased. 

After the OS is booted completely copy a file to root directory to verify the file persistence. 

To test whether the file perists or not reboot the device and check whether the file is present or not. It is observed that the file copied on first boot disappears. 

Copy the same file on second boot, reboot again to see whether the file copied is persistent or not. It is observed that from second  reboot the files and registry persists where as the files or registry modified during first boot does not persists.

When we did the same experiment on a EVM the file persistence works across all the boots.

One difference we observed between eMMC present on EVM and eMMC present on our custom hardware is that, the default values on eMMC after erase are all 1's on our custom hardware where as on EVM the default erase value equals to all 0's.

So, in boot-loader we applied the following fix. 

When ever we erase persistence storage area on eMMC, the area is filled with all 0's. 

After applying this patch we hadn't observed the first boot persistence issue.

Hope This Helps