Monday, November 24, 2008

Debugging Windows Mobile devices

Another boring notification while debugging Windows Mobile devices, is linked to the default security level of the OS. On every start of the debugger, VS2005 launch required applications on the device that are not digitally signed, so device warn you.
One solution to disable those warning messages, is to disable and change the security level. Of course this will completely remove all the security on the device... so make sure to revert your changes after debugging process to avoid any damages on your device.
On the device you have to set the following :

- Nicolas

ActiveSync Tweak

If you are like me, connecting, disconnecting, all day long, various Windows Mobile and Windows CE devices to you computer through ActiveSync, at each connection ActiveSync bother you make a partnership !
Partnership are nice while it's your personal or business device and you bring it everywhere with you to get an updated schedule and email... but while you are debugging applications, you don't want to be prompted.
ActiveSync have a "secret" registry key to always associate connected device as guest and will never prompt you anymore for any partnership.
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows CE Services]

Set this value on your desktop computer and then plug your devices !!!

To revert this, just set GuestOnly to 0(zero) and partner ship will be enabled.
- Nicolas

Wednesday, November 19, 2008

ARM European Technical Conference

The ARM European Technical Conference will take place tomorrow November 20 th in Paris. It's not too late to register for the event (link).

- Nicolas

Monday, November 17, 2008

Dll Imports

When you are connecting managed code to native, it is often a pain to figure out how to write the “DllImport” properly. I'm using this site CONSTANTLY when I need access to native code from C#. It allows you to search on a function name and see user contributed definitions for the DLL Import…

(Thanks to Joe)

- Nicolas

Tuesday, October 14, 2008

Flash back to Windows CE .Net 4.2

Last few weeks I have been involved into a customer project running Windows CE 4.2…. Woooaa a big jump in the past. I don't know if you were already involved in Windows CE at this time, but a big gap is visible between this version of Windows CE and the latest one… Thanks to Microsoft for all those improvements… Connectivity options was Configure Remote Connection… so i took me 10 minutes to find the right menu, as every thing change… But one thing that I found really surprising is the time spent to do a sysgen under Windows CE 4.2 with the most up-to-date development Platform. It took me only 10 minutes, while it was around 40 minutes on the best computer available at the release of Windows CE 4.2… oups I should say Windows CE .Net 4.2, the time when the .Net revolution starts :-).

The KITL over serial implementation give me a big headache, as at the time of Windows CE 4.2 the frames sent and received by the target where created and checked by the OAL itself before forwarding them to the upper layer of KITL… meaning that you had to know exactly the format of the frames sent and received by Platform Builder, otherwise the default KITL over serial implementation of Platform Builder was not able to communicate with the target. You can imagine that finding this information is not so easy as the MSDN documentation at this time was not so complete as it is now. But thanks to free sample BSPs, and to my favorite web search engine , I found my grale : "The definition of the KITL frames".

So as an archive for the Windows CE community here is the KITL header definition for Windows CE 4.2 : Header - Data - Trailer

typedef struct _SERIAL_PACKET_HEADER
UCHAR pktType;
UCHAR Reserved;
USHORT payloadSize;
UCHAR crcData;
UCHAR crcHdr;

With :
  • headerSignature : the signature of the header : { 'k', 'I', 'T', 'L' }
  • pktType : use by KITL to identify the service associated to the frame
  • payloadSize : packet data size, not including this header
  • crcData : packet data check sum (simple, 8-bit crc)
  • crcHdr : header data checksum (simple, 8-bit crc)

The simple 8 bits check sum algorithm :
UCHAR ComputeChecksum(PUCHAR pBuf, USHORT len)
USHORT s = 0;
UCHAR csum = 0;

for(s = 0; s < len; s++)
csum += *(pBuf + s);

return csum;

- Nicolas

Wednesday, October 1, 2008


I will present on the Microsoft booth at the Freescale FTF EMEA 2008 that will take place October 7th in Paris. If you get a chance to come, it will be a great pleasure to exchange with you about the Microsoft Embedded Technologies.
If you didn't register yet, follow this link. See you then.

- Nicolas

Wednesday, September 17, 2008

Exam Preparation Kit in foreign languages available for download

The Exam Preparation Kit book (link) for the Microsoft Certification for Windows Embedded CE 6.0 is available for download in the following languages:

  • English
  • French
  • German
  • Simplified Chinese
Other languages will be soon available for download.

- Nicolas

Adeneo delivers Windows Embedded CE training course with FREE development kits

Adeneo announced the planning for the next training session in the USA.

  • Seattle, WA – Sept 22nd to 26th 2008
  • Dallas, TX – Nov 17th to 21st 2008
  • Los Angeles, CA - Feb 16th to 20th 2009
  • Boston, MA - Apr 13th to 17th 2009
  • Denver, CO - Jun 8th to 12th 2009
  • Seattle, WA - Sept 21st to 25th 2009
  • Dallas, TX - Nov 16th to 20th 2009
Content: Microsoft official Windows Embedded CE 6.0 training with labs done on ARM based development kit
Cost per attendee: $2,500
Included in price:
  • 5 days of instructor led training on Windows Embedded CE 6.0. The training is delivered by one of our Senior Windows Embedded Developers who has the highest level of technical expertise on Windows Embedded CE - Training materials (printed manuals and a CD with all training manuals and files needed to complete the different labs)
  • Complete ARM based development kit which attendees can keep after the training session ($975 value)

Registration and information: Please contact
- Nicolas

Thursday, August 14, 2008

SQL Compact 3.5 SP1

The SQL Compact 3.5 SP1 has been released few weeks ago for Windows Mobile and was accessible only as a cab file for the Windows CE platforms. Now with the July's Windows CE QFE a component has been added to the catalog to give you a chance to easily integrate this feature inside your runtime images.

CE 6.0 July Update 2008 (includes SQL Compact 3.5 SP1)
CE 5.0 July Update 2008 (includes SQL Compact 3.5 SP1)

- Nicolas

Windows CE 6.0 MCTS Exam - Companion CD

I'm receiving lots of email asking me about the Windows CE 6.0 MCTS companion CD that illustrate the different labs of the MCTS exam book. Microsoft had to delayed the delivery of the CD as we get more work to do for the translation in the 6 different languages of the book.
This translation is nearly done and the release of those books will be grouped to the access to the companion CD.

- Nicolas

Thursday, July 31, 2008

Registry Modifications Notifications

The Windows CE registry is a good place to store applications, users settings. Those information are shared between the different processes running on the system, so content can be modified from every where.
One concrete exemple, is the backlight control panel applet that allows user to change the different timeout for switching off the screen when user inactivity is detected.So when user make changes using this applet, registry content is modified to reflect the changes. At this time, if a backlight driver exist for the platform, this driver have to update his internal timers according to the new values.
You can imagine the same mecanism between your applications and a driver, two drivers or two applications. In this case, you have to be notified when modification are done in this registry. Use the CeFindFirstRegChange,CeFindNextRegChange, CeRegGetNotificationInfo, CeRegTestSetValueWand and CeFindCloseRegChange functions for this.

- Nicolas

Wednesday, July 30, 2008

New Books

Two new books are available for the Windows Embedded CE 6.0 operating system

  • Professional Microsoft Windows Embedded CE 6.0 from Samuel Phung

  • Windows® Embedded CE 6.0 Fundamentals from Stanislav Pavlov and Pavel Belevsky

Another FREE companion book for this technology is the Microsoft Certification for Windows Embedded CE 6.0 Exam Preparation Kit, from Nicolas Besson, Rajesh Kakde and Ray Marcilla from Adeneo.

- Nicolas

Hardware runnning Windows CE ?

From the Microsoft website you can find the referenced hardwares running Windows CE.

Have a look to this list here.
- Nicolas

Search Engine for Windows CE

Looking for a Windows CE API definition, but want to get only the one for this specific OS... try the Live Search engine for Windows Embedded CE 6.0.

Go there.

[Note] Thanks to Pierre for this link.
- Nicolas

Thursday, June 12, 2008

An alternative solution to web browsing for Windows Mobile

The Mozilla Labs has posted a video of an alternative solution to web browsing, a direct competitor to the Pocket Internet Explorer. The Firefox browser for Windows Mobile, with current project codename Fennec.

See the video here
- Nicolas

Microsoft North America Awards 2008

Microsoft announced during the TechEd in Orlando, FL the list of the Windows Embedded Partner Excellence Awards for North and South America.

Awards were listed by Microsoft as follows:

  • Distributor -- Bsquare, "for continuing to raise the bar on providing Microsoft customers with world-class professional services and logistics capabilities for connected devices"
  • Independent Hardware Vendor -- Phytec, "for driving adoption of Windows Embedded CE by providing single board computers and board support packages"
  • Portable Navigation Device Partner -- Intrinsyc, "for the impact it has had with its strategic OEM design engagements"
  • Silicon Vendor -- RMI, "for its innovative work in providing highly integrated system-on-chip modules"
  • Systems Integrator -- Bsquare, "for its leadership role in providing a broad range of engineering services for Windows Embedded CE and Windows XP Embedded"
  • Training Partner -- Adeneo, "for its leadership in providing a variety of innovative training deliverables"
  • WEPOS (Windows Embedded for Point of Service) OEM -- NCR, "for its commitment to leading how the world connects, interacts, and transacts"
  • WEPOS partner -- Odyssey Software, "for delivering innovative device management solutions to key strategic retail customers"
  • Windows Embedded CE OEM -- Magellan, "for its commitment to creating devices"
  • Windows XP Embedded OEM -- HP, "for its continued leadership in the thin-client space"

- Nicolas

Tuesday, May 27, 2008

Windows Embedded CE book

A good way to learn about Windows Embedded CE 6.0 is by reading the training book associated to the Microsoft Certification for Windows Embedded CE 6.0 Exam.
Enjoy the reading here.

- Nicolas

Monday, May 5, 2008

Who want to be an MCP II

As discussed in a previous post, Microsoft launches a certification program for Windows Embedded CE 6.0. This MCP Exam is officially launched and to be ready to pass the exam, Microsoft provides a FREE Training Kit that review all the subjects covered by the test. The Training Kit is a FREE 6 Chapters electronic book available for download. For now only Chapter 1 and 3 are ready for download but others will follow in the next days.

  • Chapter 01: Customizing the Operating System Design

  • Chapter 02: Building and Deploying the Runtime Image

  • Chapter 03: Performing System Programming

  • Chapter 04: Debugging and Testing the System

  • Chapter 05: Customizing a Board Support Package

  • Chapter 06: Developing Device Drivers
The authors, Nicolas Besson, Ray Marcilla and Rajesh Kakde have a deep experience in the development of BSP, drivers and runtime images, and provide tips to improve your skill before passing this exam.

If you are not a English native reader, this book will be translated in 5 additional languages in the next weeks and will be also accessible for download for FREE.

I hope that you will enjoy reading this book as much as I had writing it.

For the exam details and download follow the link .

- Nicolas

Tuesday, April 29, 2008

Running Windows Mobile 6.1 on your PC

Microsoft provides a way to test the last release of its operating system for Windows Mobile devices. The Windows Mobile 6.1 Runtime images provided can be loaded in a VirtualPC 2007 instance.

A good way to test the compatibility of your applications with the next release of the OS for a time to market as short as possible.
Get the WM 6.1 Images on the Device Emulator with MDM here.


- Nicolas

Monday, April 28, 2008

Accessing native API from C#

The .Net Compact Framework, in his CLR (Common Language Runtime), contains a fixed set of API, and when working on an embedded device running Windows Embedded CE, most of the time, the managed code developers require access to some native APIs like custom DLL provided by a third party company. In this case the required APIs cannot be directly accessed in C# by the application and developer have to use the P/Invoke mechanism for the marshalling of the data from the managed to the native environment.

[DllImport ("coredll.dll")]
private static extern int CreateFile(
string lpFileName, int dwDesiredAccess,
int dwShareMode, int lpSecurityAttributes,
int dwCreationDisposition, int dwFlagsAndAttributes,
int hTemplateFile);

The DllImport macro is used to specify to the CLR that the next function declared is located inside a native dll, coredll.dll for instance. The tricky operation when defining Marshalling operation is the way to define the native types into managed types. Because if the wrong type definition is used, the CLR is going to Marshall the data in a way that is not expected by the native functions, and can be the reason of a crash or memory leaks on the system (null pointer, bad type conversion, …).

Accessing Device Drivers from C#
You have the same issue when trying to access device drivers from a C# application as the .Net Compact Framework do not contain any classes that allow developer to load a open driver and access it. Under Windows Embedded CE, device drivers are managed by the device manager, and in any case you do not access a driver directly through its Dll. You always have to use file system API to do so. For this reason, the CreateFile, CloseHandle, WriteFile, ReadFile, SetFilePojnter and DeviceIoControl functions should be redefined in C# to specify the Marshalling of the various functions’ parameters.

[DllImport ("coredll.dll")]
private static extern int CreateFile(
string lpFileName,
int dwDesiredAccess,
int dwShareMode,
int lpSecurityAttributes,
int dwCreationDisposition,
int dwFlagsAndAttributes,
int hTemplateFile);

[DllImport ("coredll.dll")]
private static extern int CloseHandle(int hObject);

[DllImport ("coredll.dll")]
private static extern int ReadFile(
int hFile,
byte[] lpBuffer,
int nNumberOfBytesToRead,
ref int lpNumberOfBytesRead,
ref OVERLAPPED lpOverlapped);

[DllImport ("coredll.dll")]
private static extern int WriteFile(
int hFile,
byte[] lpBuffer,
int nNumberOfBytesToWrite,
ref int lpNumberOfBytesWritten,
ref OVERLAPPED lpOverlapped);

[DllImport ("coredll.dll")]
private static extern int SetFilePointer(
int hFile,
int nDistanceToMove,
ref int lpDistanceToMoveHigh,
uint nMoveMethod);

[DllImport ("coredll.dll")]
private static extern int DeviceIoControl(
int hFile,
uint dwIoControlCode,
byte[] lpInBuffer,
uint nInBufferSize,
byte[] lpOutBuffer,
uint nOutBufferSize,
ref uint lpBytesReturned,
ref OVERLAPPED lpOverlapped);

The OVERLAPPED parameter, used by ReadFile, WriteFile and DeviceIoControl, should also be re-defined as this type is unknown in C#. In native code this object is a structure of basic types and will be defined like this in C#:
private class OVERLAPPED
public int Internal; // Reserved for operating system use.
public int InternalHigh; // Reserved for operating system use.
public int Offset; // Specifies a file position at which to start the transfer.
public int OffsetHigh; // Specifies the high word of the byte offset at which to start the transfer.
public int hEvent; // Handle to an event set to the signaled state when the operation has been completed.

To have a nice way to use those different native functions, the DllImport definition should be wrapped inside a standard C# class and public function with managed types parameters can be provided to the developer.
For example the Open function published by a device driver wrapper class could be write like this :

int m_intHandle = INVALID_HANDLE_VALUE;

public bool Open(String strDriverName)
m_intHandle = CreateFile(strDriverName, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
return m_intHandle != INVALID_HANDLE_VALUE;

Avoid Memory Leaks
Unlike managed code when allocating memory in native, do not forget to explicitly destroy those objects to avoid memory leaks. Even if you are accessing the native code from a managed application, the Garbage Collector is not able to detect those memory objects and freed them for you.

- Nicolas

Thursday, April 17, 2008

ESC Silicon Valley (San Jose, CA)

The Embedded System Conference (ESC) runs this week at San Jose, and Kevin Dallas general manager of the Windows Embedded Business at Microsoft, helped by Nick McCarty from Adeneo, did a very cool presentation of Windows Embedded CE 6.0 R2 to a large audience.

Mike Hall, who appreciates this monkey demo, talks about it on his blog.

- Nicolas

MVP Global Summit 2008

All the worldwide MVPs (Most Valuable Professional) met this week at the Microsoft Headquarter for a yearly information and feedback discussion. Most of the information provided during this week are under NDA and cannot be shared with you but the thing that I can say is that the next version of Windows CE, the version 7.0 will have a lot of new cool features for the graphical interface development, connectivity, … And the name of Windows CE 7.0 will be 'Windows Embedded Compact 2009' according to the new marketing naming scheme for the Microsoft Embedded operating systems.

This 4 days event has been closed by Steve Ballmer, who as usual, did his show and received few gift from the Canadian MVPs and an US MVP (the Simpson tie).

- Nicolas

Saturday, April 12, 2008

Power Management under Windows CE [part 3/3]

Applications can also interact with the power manager to change the current power state of the system or to be notified on power state transitions.

Application System Interaction

Using the Power Manager, applications can request system power state using the SetSystemPowerState. This is true for the system but applications can also interact with drivers. Imagine that a device driver is powered off after being used, this for power consumption reason, when applications requires an access to this driver, the driver must be turned on again. Using SetPowerRequirement, applications can ask drivers through the Power Manager, to switch to a specific power state. Then using ReleasePowerRequirement, the power requirement will be release and the driver will switch back to his original power state.

Request power notification

Using message queue, applications can be notified of power transition occurring on the system. When system is entering suspend, this is transparent for applications, and the only way for applications to be notified of resuming from suspend is to register to this message queue using the RequestPowerNotification function. The messages read from the message queue provide information on the status of the system.

Modify the Power Manager

The source code of the power manager is provided with Windows Embedded CE and can be located in %_WINCEROOT% \PUBLIC\COMMON\OAK\DRIVERS\PM . This gives you a chance to adapt the behavior of the Power Manager to your requirements. Most of the time, you do not have to make any modification in the code; instead use the registry to change the default behavior.

In conclusion the power management is straightforward for Windows Embedded CE when the power requirement of your device is simple, but can start to be tricky when more complicated. In any case, the system can be fully customized through the registry or for advanced usage by modifying the behavior of the Power Manager by directly modifying the source code. Applications can be notified of power transition and act if required, but it can also interact with the system to change the power state of drivers or the system. On their side device drivers can implement power management to support 5 different levels, and optimize the power consumption of your device. The Power Manager is the only one on the system to manage the power, applications and drivers always have to send request to the Power Manager that will relay the requests to the correct system component according to his internal state machine.


Friday, April 11, 2008

Power Management under Windows CE [part 2/3]

In the last article we saw that the Power Manager is in charge of the management of the power on a Windows CE device, and interact with the system to change the system power consumption according to the user and system activity. Each driver can support 5 different levels of power states that can be setup from the registry.

Device Drivers Interface

The Power Manager is using IoControls to communicate with the drivers, to set, get the current power state of the driver. So drivers have to implement the support of those IoControl codes if they can manage the power of the managed device. The command codes are the following:

  • IOCTL_POWER_CAPABILITIES: used by the Power Manager to identify the power capabilities of the device driver. This command is called once when Power Manager enumerates the device on the system.
  • IOCTL_POWER_GET: used to get the current power state of the device.
  • IOCTL_POWER_SET: used to request a power transition.
  • IOCTL_POWER_QUERY: used to validate that the driver will support a power transition from its current state to the specified state.

Power Manager interface for device drivers

The device drivers cannot change their power state by themselves, without notifying the power manager; otherwise the power manager is not aware of state modification and cannot optimize the power on the device. When drivers require power level modification, they should request the power manager for that by calling DevicePowerNotify from the driver. Then the power manager will use the IoControls to request user to change is power state.

Next time we will identify how the applications can request system power transition.

[Updated] : Access to part 3/3

- Nicolas

Thursday, April 10, 2008

Power Management under Windows CE [part 1/3]

Embedded devices are usually powered by batteries and the power have to be correctly managed to improve the device autonomy and by the way the user experience. Windows Embedded CE is provided with a Power Manager that will interact with the different drivers of the system to reduce power consumption when required.

System Power States
The OS have 4 different power states that will be the four states of the internal power manager state machine. The state transition will be linked to system conditions : user activities, system activities, application requests and timers.
The four states are :
  • On : in this state the device is full active and user can use all the different peripherals, and by consequence the current consumption is maximum
  • User Idle : this state is reach when user is not using the device after a time out, the power consumption can be reduced by, for example, decreasing the display backlight intensity and disabling peripherals.
  • System Idle : after application inactivity, the power manager switch to this state.
  • Suspend : in this state the device is consuming the less power as possible, but the device cannot be used, the processor clock is decreased (or turned in a suspend state if supported), the peripherals are usually turned off and the SDRAM is still refreshed.
The transition from On to User Idle and User Idle to Suspend is done after timers expirations, those timers value can be setup through the registry to customize your device. You can managed timers when device is powered by a battery and/or by AC, to optimize your device current consumption depending on the power source.
"ACUserIdle"=dword:5 ; in seconds

This will set a timeout of 5 seconds to enter the User Idle state when the device is powered by AC. The status of the power source is not identified by the Power Manager, itself, it will require the development of a battery driver. The battery driver will provide power source transition notifications to the power manager.

Drivers Power States
On the system drivers can support 5 different levels of power according to the peripheral capabilities:
  • D0 : Full on, the peripheral is fully functional
  • D1 : Low On, fully functional the device consumption is reduce comparing to D0 state
  • D2 : Standby, device is partially powered, and able to wake up on request
  • D3 : Sleep, the device is consuming as less power as possible and can be used to wake up the system
  • D4 : Off, the device is off an do no consume any power
Each state is optional and a driver can support only few of them. The power manager will request to the driver the different supported power state at initialization.

System Power States vs Drivers Power States
The Power Manager is fully configurable through the registry, so default configuration is provided to at least manage power by its own without any pre-requisite. Each power state of the drivers will be associated to a system power state as follow :
  • On -> D0
  • User Idle -> D1
  • System Idle -> D2
  • Suspend -> D3
The Power Manager will request device driver to change their power state at system power state transitions, according to this list. As explained before, those values can be overridden using the registry by creating new entries like this :
"bkl1:"=dword:4 ; backlight off

"bkl1:"=dword:4 ; backlight off

"bkl1:"=dword:4 ; backlight off

In this example, the driver named bkl1: will be turned off when the system power state will switch to User Idle, System Idle and Suspend states. You can either define power state for drivers individually in the registry or group them into IClass definition. When defining a driver in the registry you can specify which class of driver this driver is associated to.
[HKLM\SYSTEM\CurrentControlSet\Control\Power\State\SystemIdle\{ A32942B7-920C-486b-B0E6-92A702A99B35 }]
"Default"=dword:4 ; D4

This configuration will turn off all the device from the Iclass (A32942B7-920C-486b-B0E6-92A702A99B35). This IClass value is the GUID used by the power manageable devices.

That’s all for today, but two additional articles are following in the next few days. I will talk about the device driver interface requirements, and application interface used to communicate with the Power Manager and receive notification from him.

[Updated] : Access to part 2/3

- Nicolas

Tuesday, April 8, 2008

NXP LH7A404 ARM-9 based processor runs Windows CE 6.0

Adeneo has announced a Windows CE 6.0 board support package (BSP) for NXP's ARM9-based LH7A404 SoC (system-on-chip). The BSP supports the 200MHz SoC's display, touchscreen, audio, and USB functionality, along with peripherals found on a separately available Logic Product Development development board.

- Nicolas

Friday, April 4, 2008

Windows Embedded CE Webcast

Few weeks ago I did a live web cast session for the device drivers development under Windows Embedded CE 6.0 R2. All the webcast sessions recorded at this time are available now from the Microsoft Embedded Seminars website. For the Device Driver development session use this link.

Enjoy the nice French accent of your host.

- Nicolas

Thursday, March 27, 2008

Enable Bluetooth support in Windows Embedded CE

The Bluetooth stack is natively supported by Windows Embedded CE, and can be integrated to your runtime image. This required of course a Bluetooth controller that can be either a Serial, USB,… dongle. Based on this stack you can enable Bluetooth capabilities to your device and applications, using the Bluetooth API. Enabling Bluetooth in your applications is not straightforward, as it requires to implement mechanism for at least the discovery and pairing with other devices (paired devices are trusted devices).
A Windows Embedded CE device can either connect to services provided by other devices or host service for other devices.

On a Bluetooth device, the different remote or local services provided by the Bluetooth stack are called profiles. The Bluetooth specifications provides a complete definition of the different Bluetooth profiles that can be enabled on a Bluetooth device. Unfortunately Microsoft do not provide all the profiles listed in this specifications, but only a subset is accessible like:

  • Service Discovery Protocol (SDP) used to discover the other Bluetooth enabled devices in the range of your device
  • Serial Server Profile (SPP) providing a serial interface for communication between two devices
  • Object Push (OPP) to send files to other devices, can be used to send business card
  • File Transfer Protocol (FTP) to provide an access (push or get) to a remote file system
  • Personal Area Networking (PAN) to enable IP support to communicate through the bluetooth connection
  • Dial Up Networking (DUN) to perform network connection to remote servers
As evocated previously those profiles required development to manage the access to the Bluetooth stack and handle communication errors and requests.

Existing Bluetooth Manager:
When using Bluetooth, you need a Bluetooth Manager that will allow user (or applications) to support the discovery of the in range Bluetooth devices and provide access to the remote and local Bluetooth profiles.
  • Microsoft provides by default a very basic Bluetooth manager for the discovery and pairing to remote devices.
  • Adeneo provides a Bluetooth Manager with an interesting layered architecture that provide a way to easily integrate in your applications the Bluetooth support. A GUI illustrates how their Bluetooth engine works. More details on their product is available here. They also provide a version compatible and certified for Windows Mobile 5.0 (Product Reference).

Required System Components:
To enable the Bluetooth on your platform, it will requires the following components in your OSDesign:
  • USB Host Support (or Serial Port Support)
  • Bluetooth Stack with Integrated CSR Chipset Driver
  • Bluetooth Stack with Integrated USB Driver (or UART-Only Driver)

Sample source code:
You can find some sample source code for the Bluetooth handling :

- Nicolas

Thursday, March 20, 2008

.Net Compact Framework 3.5

The January Windows CE 4.x, 5.0 and 6.0 QFEs (Quick Fix Engineering) enable the .Net CF 3.5 for Windows CE. Now this feature can be directly integrated inside a runtime image by selecting the associated component in the platform builder catalog. The .Net CF 3.5 introduce new graphical components and fix some well know issues of the framework.

Windows Embedded CE QFEs are accessible here

- Nicolas

Business Solution Accelerator 2008

Need help to implement features in your .NET Compact Framework 3.5 application, Microsoft just released the Business Solution Accelerator 2008 for Windows Mobile, providing free and reusable source code and associated documentation.
In the mean time, the Windows Mobile blog will in the future discuss of the best practices in .Net CF development (blog link).

[Updated] Microsoft's Reed and Steve wrote a complete article on this LOB Solution Accelerator.
[Updated] See also Fabien's blog article for details about it.

The complete package and detail are accessible from the Microsoft Web site.
- Nicolas

Tuesday, March 4, 2008

Who want to be an MCP

Microsoft is currently working on a Microsoft Certification Professional (MCP) Exam for the Windows Embedded CE technology. Few months ago some eMVP has been consulted to create a set of questions on the different technical aspects that must be masterized to generate, debug and use Windows Embedded Runtime binary images.
The exam 70-571, actually in beta test, should be accessible by every body in April time frame.

- Nicolas

Thursday, February 28, 2008

Windows Mobile Trojan

WindowsForDevices post an article on the first trojan discovered by MacAfee's Avert Lab on WiMo devices. This trojan opens security permission on the device and can contaminate other devices using SDCards.

Read full article ...

- Nicolas

Tuesday, February 26, 2008

Readers contribution

First of all, thanks all for your fidelity.

To exactly match your expectation in term of content, I'm opening a suggestion emailbox to submit your questions and ideas for the next articles to publish on this blog.

You can send your requests to : nbesson DOT blog AT gmail DOT com
Again, thanks for your help.

- Nicolas

Tuesday, February 19, 2008

Smart Device deployment and debugging using VS2005

When developing smart device application, in C# or C++ (Win32 or MFC) using Visual Studio 2005, you have different solutions for the deployment and debugging of your application.

ActiveSync :

This is the easiest way as it just required the support of ActiveSync in your Run Time image and a Serial or USB Function interface correctly setup. When connecting the device to you development computer ActiveSync should start and connect to the device. VS2005 is setup to use the ActiveSync link automatically for the deployment and debugging. No particular actions are required for this connection type.


If you have the chance to have a KITL connection between the device and Platform Builder, you can directly use this connection with another instance of VS2005.


Before been able to use the KITL connection from VS2005, you have to create and setup a device configuration. To do so you have to open the Connectivity Options window in the VS2005 instance running the Platform Builder plug-in. Use the Create Device button to add a new device to the list of devices identified by Platform Builder. Associate this new device to an SDK if you got one or to the Generic Platform Builder OSDesign in the drop list as shown bellow.

Then select this new device and setup the Transport and Download information as you are usually doing it with your target device. Then attach and download the Runtime image to the target. This VS2005 instance will be use to debug the OS, and not your application. You will be able to add break point in the drivers and/or OAL.


In the second VS2005’s instance start/load your application solution and go to the Tools menu followed by Options then Device Tools group, select Devices, select the device created previously in the list and edit the Properties. Check that the Transport configuration is KITL. Validate all the open windows and close.

Now your system is ready to deploy and debug your application on the device using the KITL layer.

Corecon :

Corecon use the network interface to communicate with Visual Studio and requires to launch two applications on the device, but before you need least the following files on your device:

  • clientshutdown.exe
  • CMAccept.exe
  • ConmanClient2.exe
  • DeviceDMA.dll
  • eDbgTL.dll
  • TcpConnectionA.dll

Those files can be directly integrated in the nk.bin using the project.bib file or copied on the device at runtime using USB flash key or FTP connection.

Those files are not provided directly with the Windows Embedded CE 5.0/6.0 development environment, but are located in the VS2005 folders in the folder :

c:\Program Files\Microsoft Shared\CoreCon\1.0\Target\wce400\ProcessorType\

Binary versions are available for all processors supported by WinCE (ProcessorType).


The two applications, CMAccept and Conmanclient2 have to be launched manually when a connection to VS2005 is required. To do so you have to get a way to launch them, using the explorer window on the device, or using a telnet connection. You will also need the IP address of your device to correctly setup VS2005 connection. Without this IP address VS2005 would not be able to connect to the device.

Launch and connect

Under VS2005 you have to select and edit the device connection property by going to the menu Tools followed by Options then Device Tools group, select Devices, select the device in the list and edit the Properties.

In the Properties window select the Transport as TCP Connect Transport and then Configure. In the Configure window check the Use Specific IP address andx enter the IP address of the device. Validate all the open windows and close.

On the device you have to launch the ConmanClient2 application, followed by CMAccept. At this time you have approximately 3 minutes to connect the VS2005/2008 instance with your target. Elapsing this time you will have to launch the CMAccept application again before trying to connect.

In the VS2005, select the device in the device drop box list and click on Tools followed by Connect To Device. The connection may succeed and you should be able to start the deployment and/or debugging.

Those three configuration are using different communication layers but will provide the same set of functionalities for the deployment and debugging of Smart Device applications.

[Updated on 02/19/2008]
For the Windows Mobile user, to get all the steps for those platforms, you can check out the article on the Fabien blog.

- Nicolas

Monday, February 18, 2008

Catalog item notification

BSP components (drivers, or custom applications) require some attention from the user and should notify him. A catalog description of a you can easily integrates a notification messages that will show up when user will add this component to the OSDesign, like the one displayed when adding the FTP server or Telnet server to an OSDesigns.

By adding that kind of notification message Platform Builder will also display an exclamation mark icon next to the check box of the catalog component. The notification message and title can personalized, for that add to a specific component the Notification Html (body message) and the Notification Title (shown in bold in the notification window) as shown bellow.

- Nicolas

Monday, February 11, 2008

Dynamic JIT Debugging [Updated]

Booting a device with the debugger is sometime a real challenge due to the stability of the device. So loading the debugger later could be the solution. To do so, we have to include the JIT debugger files in the Windows Embedded CE binary image, to launch it when required.
If the debugger is not launched exceptions are not handled correctly, and second chance exceptions neither.

Inclusion of the JIT Debugger
In the project.bib file of the current OSDesign, add the following lines in the FILES section :
kd.dll $(_FLATRELEASEDIR)\kd.dll NK SHK
osaxst0.dll $(_FLATRELEASEDIR)\osaxst0.dll NK SHK
osaxst1.dll $(_FLATRELEASEDIR)\osaxst1.dll NK SHK

The files are added to the FILES instead of the MODULE section to ensure that the debugger will not be launched 'till you launch it manually.
[Update 07/25/08] You can also include the loaddbg.exe file to the runtime image to avoid the loading of this files over KITL. But do not include hd.dll, otherwise the debugger will be started automatically at startup.

OSDesign configuration
Select the following options for the OSDesign:
- Unselect Kernel debugger
- Enable KITL

Launch the debugger
To launch the debugger when required, you just have to launch the loaddbg.exe application using the target control window.
s loaddbg.exe
Note : When activating the debugger, the system may take few seconds load all the symbols files from your hard drive.

- Nicolas

Monday, January 14, 2008

Automatically add files to an SDK

When building an SDK using Platform Builder 6.0 (and previous), you may need to include your own files. Those files are the list of IOcontrols of drivers you implemented, or header files required to link to a new library that you want to provide in your SDK. In that case you have to include those files to your SDKs.
The first one is a manual inclusion of those files using the configuration wizard of the SDK. That’s mean that every time you generates the SDK you have to take care of those files.
The second solution is to automated this mechanism by copying those files to a specific folder that will be used automatically by the wizard during the generation of the SDK.

Identification of the sdk folder :
The SDK tool uses the content of the cesysgen folder (located in your OSDesign folder), and the sdk folder located in the same folder as the cesysgen and OAK folder.
The SDK tool adds the content of the sdk\Inc and sdk\Lib folder to the SDK msi file. So you must store the files you need to provide with the SDK in those sub folders. Doing it manually is never the solution, so by asking the Windows embedded CE build environment to do it, it is more reliable. This could be done during the build of those libraries or drivers.

Add an automated task :
Using the sources files you can add dependencies and enable automated task for the build engine. You could also use the postlink macro, but this is not the purpose of this article.
In the sources file add the following lines :
# SDK files
# Enable copy to the SDK directory
SDK_FILES=gpio_iocontrol.h driverheadertoshare.h

Any target files that you specify using WINCETARGETFILES are added to the list of dependencies that must be satisfied to generate a successful build. Also by listing the files you need for your SDK in the SDK_ FILES variable, you will generate a list actions that will be solved later in the
In association to the sources file you must provide a (located in the same folder), this file is proceeded after your sources files during the build. In this file you must satisfy the dependency list, so it must contain information about the CopyFilesToSDK. content will be something like this :
#REM copy the files listed in SDK_FILES to $(_PROJECTSDKROOT)
The copy will be done in batch script language and executed by the build engine.
After the build of the driver or the library, you may find all your required files in the $(_PROJECTSDKROOT) folder.
In this article I described only one list of files to be proceeded, but it make sense to have two lists, one for the header files and the sdk\Inc folder and another one for the sdk\Lib folder for the libraries.


Thursday, January 3, 2008

Happy New Year

I wish you an Happy New Year 2008.

For this new year, I'm glad to announce that I have been awarded as Windows Embedded MVP for the second time. So thanks to the Mike Fosmire and the MVP team for this award.

- Nicolas