New Orleans, March 21, 2003 - Today the Mobility Developer Conference is rounding up, although still with a number of interesting presentations. Due to the nature of DotNetForDevices, most coverage has been on using the .NET Compact Framework, but there have been tons of other technical presentations. Topics covered were devided in a number of different tracks:

• Mobile client development, including all the .NET CF presentations

• Server applications and services for mobile devices

• Wireless industry forum

All in all, this conference gave a great view of what is currently going on in mobile computing with Microsoft technologies.

How responsive the .NET Compact Framework can be was made clear in a presentation totally dedicated towards game development. In this presentation, Seth Demsey showed lots of examples of games, many being developed internally at Microsoft. The games were targeted both to the PocketPC and the Smartphone. One of the advantages of building games with the .NET CF is the fact that those games will actually run in a sandbox, the .NET managed execution environment. Since applications running in the sandbox can by no means hang devices, this might be a determining factor for telecom operators to allow games on Smartphones. All demo’s run with smooth animation, giving an impressive feel of what the .NET CF is capable of. Having said that, it is necessary to develop keeping speed in mind. Game development is typically all about custom drawing on a Windows Form. It is absolutely essential to only paint those pixels that are strictly necessary. To get a great user experience techniques like double buffering should be used. This basically means painting all information off screen in a bitmap and when all information is in the bitmap transferring it with efficient function calls to the visible screen. Something else that is very important is to calculate the dirty area, this is the area that has became invalid. By calculating the dirty area carefully, only a limited part of the screen needs updates. Techniques that can be used to achieve this are union, intersection and non-overlaping drawing techniques. All of these require a bit of calculation but performance will benefit tremendous from it. It is probably a very good idea for all device developers to take a look at these drawing techniques, because it can make all kinds of applications more respondent.

A totally different topic, actually a bit more under the hood of Windows CE was Steve Maillet’s presentation on the device driver architecture of PocketPC and Smartphone devices. Steve is an absolute guru on this topic and he had some great suggestions for debugging device drivers. In general it is hard to debug device drivers for mobile devices because of the way the Windows CE operating system is hosting drivers. Device drivers are user mode DLL’s, but they are running within the context of the Device Manager. Device drivers are developed using embedded Visual C++, but unfortunately this tool cannot be used to debug drivers. To be able to do so, the debugger should attach to Device Manager, but the debugger makes use of device drivers itself to communicate between the device and the development system. Whenever a breakpoint in a device driver would be reached, not only the device driver under debug, but the entire Device Manager would halt, making it impossible for it to communicate any longer with the development environment. Making use of Platform Builder’s kernel debugger is no option either, because it is impossible to connect Platform Builder to a released device. Therefore Maillet suggests creating a local version of the NKDbgPrintfW API in your own project. This API is defined in the dbgapi.h header file that comes with device SDK’s. Making a local version means you can direct debug output using DEBUGMSG and RETAILMSG to wherever you want, allowing at least some “basic” ways of driver debugging.

The last presentation of today covered very interesting subject: “writing custom controls for the .NET Compact Framework”. This is something that many people are probably interested in. It is not entirely trivial to write a custom control that also shows up in the designer part of Visual Studio.NET. This is however absolutely necessary for commercial available components to give developers the same experience they will get when using built-in controls. To be able to show .NET CF custom controls within Visual Studio.NET’s designer pane as well, two different versions of the control must be build, the actual control and a copy that can be used in the Visual Studio development environment. This is different from writing custom controls for the desktop. On the desktop the control appearing in an application can also be shown in the designer pane of Visual Studio.NET. To be able to show controls during design time, design information has to be added to the control. To make the .NET CF smaller, design time information is lacking from it. The only way to get a good design time experience is to create a design time equivalent of the control. Thanks to the fact that the .NET CF is a true subset of the .NET framework, most of the code of the runtime control can be used to create a design time control. Only make sure that device specific code is removed from the design time control. The design time control needs additional designer attributes from the System.ComponentModel namespace. In the near future, Microsoft will post a whitepaper on this subject on GotDotNet.