Tuesday, February 24, 2009

Oracle Day 2009 - Smart Strategies for Uncertain Times

On March 5th 2009 in London, Oracle is holding an event "Oracle 2009 - Smart Strategies for Uncertain Times" to which Edenbrook is a key sponsor. A snip from the event website:

The Oracle Day 2009 will cover the Oracle Technology stack from the Database and Middleware through to SOA, Enterprise 2.0, Business Intelligence and Security. This event will bring together IT professionals across industry sectors to address the real challenges faced by IT today - consolidating, cutting costs and innovating. After the keynote speaker presentations the event will break into two distinct tracks, one for IT Management and one for IT professionals and architects, providing the opportunity to select the sessions most relevant to you.

The address for this event is:

Renaissance Chancery Court Hotel
252 High Holborn

To register see here or see here for more information.

Thursday, February 05, 2009

Mobility developer tools - Part 2 of 10

UPDATE: updated 15/02/09 to correct some information.

This is part 2 of 10 of the getting started with Windows Mobile development series. For previous posts in this series, please see here.

Again we are concentrating mainly on Microsoft Windows Mobile technology although other developer tools are briefly mentioned.

Unmanaged Device Development

Unmanaged device development is supported but not under Visual Studio 2008. Porting MFC code to Windows Mobile is not easy as there is no support for OLE on Windows CE. There is support for COM on Windows CE however.

Managed Device Development

The most common method for writing device applications today is using managed code. C# or VB.NET are the only supported managed languages for the Compact Framework. Very few people build applications using embedded technologies today. The sort of people doing embedded (native) development today are people who are writing low-level device driver software or managed developers who want to implement some sort of security code protection algorithm which can’t easily be reversed engineered as a managed application can.

All versions of Visual Studio 2002 had support for managed device application development. This changed from VS 2003 where the express edition dropped managed device support and this was true for VS 2005 as well. So Standard Editions or later of VS 2003 or VS 2005 are required in order to target devices. This changed again with the release of the latest version of Visual Studio which is 2008 where Professional Edition or later is required for device application development support.

VS2008 supports multi-targeting that allows the device developer to target CF 2.0 and CF 3.5. In order to target CF 1.0 you have to use VS 2005 with a CF 1.0 project. The Compact Framework is covered in great detail in a later relevant section.

When installing Visual Studio 2008, the Smart Client extensions are selected by default but prior versions you have to explicitly select the Smart Client extensions for Mobile device support.

What is the Compact Framework

The Compact Framework is a subset of the full Microsoft .NET Framework (not to be confused with the .NET Micro Framework which has a 300k memory footprint). Because device applications run on memory and CPU constrained devices, not all the classes, methods, properties etc are supported on the CF. There is a lot of stuff missing.

The Compact Framework has around a 3-4 Mb memory footprint although with each release this gets larger to satisfy developers needs and new technology but devices are shipping with more and more memory (ROM and RAM) each year.

Since Windows Mobile 2003 Second Edition, Microsoft has insisted that at the time the OEM builds the WM image, the latest RTM version of the Compact Framework is shipped in ROM. This is really cool for many reasons:
  1. This gives a developer more RAM for his/her applications and also more flash storage
  2. Before WM5 was released, there was no flash persistent storage that the OS occupied. Back then, everything resided in RAM and memory was divided between application storage space and proper RAM used to load applications. Performance was a nightmare as you can imagine. The user could customize this divide, but this was too complex for a non-technical user. So if the battery went flat, you would lose all your content. WM5 changed this. So Microsoft decided to ship the CF in ROM. This elevated some of the memory constraints but often the CF was out of date at the time of build because of the long process carriers/OEMs take to build new images they are not agile enough like Microsoft so by the time the devices hit the market, they are a version behind.
  3. As it happens, WM2003 SE shipped with version 1 of the CF, which mean’t managed developers could for the first time write an auto load application and ship it on a removable flash card such as a SD or Micro SD card. So when card was inserted into the device the application would run. Previous to this managed developers had to write this kind of auto load application in eVC++ or eVB. The later WM5 devices shipped with the CF 2.0 SP1. Even many WM6.0 devices still ship today with CF 2.0 SP1 even though CF 3.5 has been released for over 1 year. It turns out WM6.1 do ship with CF 3.5 and SQL Compact 3.0 (latest version of SQL Compact at the time of writing is 3.5)
Compact Framework – Architectural differences over the desktop version

There are some architectural differences with the Compact Framework over the desktop versions. There was no v1.1 or v3.0 of the CF. The latest version of the CF which is 3.5 has its own CLR. It’s not derived from the CF 2.0 as per the desktop. There is no *current* support for vector based UI such as WPF other than Silverlight 2 for Mobile (not even in CTP yet) – which we talk about in a later article. There is WCF client support in CF3.5 just no ServiceHost support. The WCF support is also a subset. The subset support is documented here and here.

The Compact Framework is Retargetable – which means it supports and does define the AssemblyFlags(AssemblyNameFlags.Retargetable) attribute in all it’s assemblies. So what does this mean? Well it means you can retarget the IL compiled against the CF and run it against the desktop CLR (within reason) and generate the same native code. It saves you the need to recompile for the desktop.

Below is a snapshot of the System.Windows.Forms assembly, as you can see the Retargetable enum is defined with the AssemblyFlags attribute.

// Assembly System.Windows.Forms, Version

[assembly: AssemblyVersion("")]

[assembly: AssemblyFlags(AssemblyNameFlags.Retargetable | AssemblyNameFlags.PublicKey)]

[assembly: SatelliteContractVersion("")]

[assembly: CLSCompliant(true)]

[assembly: ComVisible(false)]

[assembly: InternalsVisibleTo("Microsoft.WindowsCE.Forms,PublicKey=0024000004800000940000000602000000240000525341310004




[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Although it is possible to share your device compiled with the desktop, the reverse is not true. This is because….you guessed it the desktop assemblies do not contain the Retargetable enum.

Usually though, device developers share code, not assemblies, and have separate projects for the desktop and the device. Then in the code they will define a conditional compiler directive so that device specific instructions, for example calling coredll.dll functions are omitted on the desktop.

Although the Compact Framework and the full framework use what appears to be the same classes, methods, properties. They both use the same languages C# or VB.NET and the CLR appears to be the same – at least from the outside. The Compact Framework’s CLR is dramatically different from that of the full framework especially from a memory GC and allocation perspective. This is largely to do with the way Windows CE handles memory. Each process, this includes each AppDomain is allocated a maximum of 32 meg. This doesn’t include the System core space. So of course the CF has to work with this constraint and there are many things it does to ensure the smooth running of applications and the general OS to ensure it doesn’t grind to a hault and run out of memory. I have written a fairly lengthy article about this process here.

Platform Invocation

Because the Compact Framework is just that, compact it is inevitable that you have to call native code (OS Win32 APIs). This process is known as Platform Invocation or P/Invoke and thankfully it is supported on the CF.

Just one example of this is controlling the Telephony API (TAPI) there is no managed API to control the radio, GSM, 3G etc. So it is often beneficial for managed device developers to have a background in native C++ as it requires translation to managed code for interop.

There is a good site for doing interop between .NET and native here: http://www.pinvoke.net.

Device Emulators

Device emulators available today are true ARM emulators and they come with the relevant Windows Mobile SDKs. So for example the latest version is Windows Mobile 6.1 SDK for Windows Mobile standard and professional. See the earlier post: Windows CE, Pocket PC, Smartphone, Windows Mobile - what's the difference! - Part 1 of 10 as to what the differences are between standard and professional. Pre Windows Mobile 5 emulators were based on x86 so were not really a true emulation. So back then developers never really used the emulators.

Today they have come along way.

Since Windows Mobile SDK 6 we have had the Cellular Emulator that allows greater human testing.


OpenNETCF Smart Device Framework is a shared source project free for developers to download in a pre-compiled format.

The SDF has been around for many years and was a life-line for developers when the CF v1.0 was released. This was because there were so many features/classes missing which made device developers used to developing desktop applications very difficult.

So what is the SDF? The SDF is a series of class libraries to bridge the gap between the full framework and the Compact Framework. The OpenNETCF team identified the missing assemblies and in many cases wrote these for which now forms the SDF. The SDF also contains many device specific classes many of which form wrappers around native APIs that are absent from the CF and also include many UI controls. Even with the lastest version of the CF many featuers are still missing due to memory contraints, the SDF does in many cases offer an alternative solution.

The community edition is free in pre-compiled format. The standard or professional editions are required if you want support - for a small fee.

Please see the following link for more information:

ORMs on Windows CE

There is currently no support for NHibernate or the Entity Framework or even DLINQ (LINQ to SQL) on Windows CE and the Compact Framework. There is however support for LLBLGen but often performance becomes a bottleneck for ORMs to work effectively.

Most device developers handcraft data access layers themselves with a repository and domain model or a more Active record pattern approach.

I am currently working on building a simplified ORM for the CF. It is tailored for the CF 3.5. It doesn't include any type of lazy loading or using proxies not because of the technical challenges this will impose but because the performance would a major issue on devices. I have designed it to support persistence ignorance objects or the support for Plain Old CLR Objects. It is built on the Mobile Client Software Factory Data Access Application block. I want to find a way to abstract the repository interface from the implementation as the Castle project does. Currently the repository interface is tied to the implementor.

I'll post this code on MSDN once finished.

LINQ for devices

There is support for LINQ on the Compact Framework. However there is no support for LINQ to Entities or DLINQ (LINQ to SQL). There is support for LINQ to XML.

I've written a few posts about LINQ for devices here.

Databases on Windows CE

There are a few options of relational database management systems when it comes to mobility. The options are as follows:
  1. SQL Server Compact
  2. Sybase IAnywhere
  3. SQLite
  4. MySQL

Microsoft’s latest offering is SQL Server Compact 3.5. As with the Windows Mobile OS name changes, SQL Server Compact has gone down a similar path. The difference with SQL Server Compact today is that it can be run on the desktop as well as mobile devices. There are different installations but you can read/write the same database on both platforms. This feature has been supported since v3.1.

There is support in SQL Server Management Studio (standard or later, not express) that allows you to connect to an SDF (compact database). The database looks as if it were a normal MDF desktop database. You can run queries, change the schema, create a diagram etc. The tool also has support to connect to a database on the device when the device is connected via ActiveSync or Device Manager (Vista). Note though, SQL Server 2005 Management Studio doesn’t work with SQL Server Compact 3.5. You have to have SQL Server 2008 installed. You can however use Visual Studio 2008 to connect to the SDF if you wish, although the tooling is very limited.

The Microsoft Patterns & practices team have written a data application block that allows easy data access. This application block forms part of the Mobile Client Software Factory.

SQL Server Compact – Architecture differences over the desktop version

The main difference between SQL Server Compact and the full desktop version is SQL Server Compact is embedded. It runs within the callers context. This explains the reason why there is no support for stored procedures in SQL CE. This doesn’t mean the whole database engine is reloaded per application domain or process space. The process is shared across many applications as the system core memory space is used.

Since version 3, SQL CE is now multi-threaded so it has multi-user support. As with most device technologies, SQL CE is a cut-down version of the desktop version. It wasn’t until v3.5 recently released that the rowversion (timestamp on desktop version) data type was supported.

My Mobiler

My mobiler is a tool that allows remote control of your device over ActiveSync or Sync Center. This is great for demos. I blogged about this tool a while back here: http://www.simonrhart.com/2008/06/my-mobiler.html.

You'll notice it is very similar to ActiveSync remote display but alot better. ActiveSync remote display comes with Windows Mobile Power Toys.

Although to get it to work on later devices you'll need to read this.

Windows Mobile Power Toys

Windows Mobile Power Toys is a suite of applications to aid development. One of the most useful applications that comes with this suite is the Hopper - a user input stress simulator.

Windows Mobile API Usages Tool

The Windows Mobile API Usages Tool is a command-line tool that runs on your desktop that performs static analysis of applications and binaries to run on Windows Mobile devices and reports the usage of system APIs and other resources. The goal of the tool is to provide a report of system dependencies to the application developer, optionally including the deprecated APIs that the application may currently depend on.

The Windows Mobile team blog talk about this tool in a little bit of detail here.

Non-Microsoft Mobility Development

Recently the Google Android was released. The developer tools are freely available to download. The development environment is called Eclipse (Java based) and the Google Android SDK contains the emulators to test your code.

If you are interested in writing applications for Google Android, see here: http://code.google.com/android/

Currently you will not get the same development experience with Google Android than you do with Windows Mobile. Developing applications for mobile phones is challenging and Google Android is still yet to mature somewhat.


There are probably more tools that I have forgotten about but when I remember, I'll add them.

Sunday, February 01, 2009

Windows Mobile Development - for newcommers

This post details the internal links for 10 getting started with Windows Mobile articles in the following order parts that are designed for newcomers to mobility. The links will become enabled once published:

Windows CE, Pocket PC, Smartphone, Windows Mobile - what's the difference! - Part 1 of 10

Welcome. This is the first part of 10 articles to get you introduced to Windows Mobile (device) development. For other posts in this series, please see here.

The first question many new comers ask is, what is the difference between Windows CE, Windows Mobile, Pocket PC, Pocket PC Phone Edition, Smartphone, PDA's ? ....There are more names.
Essentially this is Microsoft marketing gone mad! The truth is, all the platforms above are Windows CE.

Windows CE

Windows CE is an embedded operating system designed to run on small memory and CPU contrained devices. The OS is highly customizable. An OEM (original equipment manufacturer) can choose which bits to add and which bits to take away.

Some ISV's (independent software vendors) build their own Windows CE using a tool called Platform Builder to provision to a generic Windows CE device. Doing this allows great control over how the device will operate. This is known as Windows CE Embedded.

Pocket PC

Pocket PC 2000 or PPC (Windows CE 3.0) was the first Pocket PC which didn't contain any GSM or radio. These are the devices you can still buy today except they are now called Windows Mobile Classic and most now are based on Windows CE 5.0. These devices were initally released with a 320x240 QVGA screen or 92DPI. So we mentioned Pocket PC is a Windows CE device.

Pocket PC/Windows Mobile devices have a different shell and a whole bunch of additional Win32 APIs and applications not seen on generic WinCE. So fundementally WinMo is a WinCE but a greatly customized version of it. The OEMs/carriers decide how the WinMo will be built, even down to what APIs are available to appliation developers and the security policy employed.


First released in 2001. The Smartphone followed the PPC that added GSM support but unlike the PPC, it didn't have a touch screen and still doesn't today. Today the Smartphone is known as the Windows Mobile Standard edition. It's worth noting that the smartphone has a much smaller screen than the Pocket PC which at the time was 176x220 QVGA - which by and large hasn't really changed much. Hi-resolution smartphone devices are rare unlike its bigger brother PPC.

Pocket PC Phone Edition

First released in 2002 (based on CE 4.1) which included GSM support with 2.5G (GPRS). Eassentially this was very similar to the Pocket PC except for radio. At the time there were very few of these devices around. Today it's hard to by a regular PPC (Windows Mobile Standard) device.

Windows Mobile 2003 Second Edition

Released in 2003 and based on CE 4.2. Contained many shell extensions - a whole UI overhaul and also the .NET Compact Framework v1.0 included in ROM which was a major benefit for managed developers for lots of reasons, the main one being it was able to write a managed app to load from a flash card on a cold boot (hard reset). Notice the naming change. This was when "Windows Mobile" replaced Pocket PC. But just to confuse the matter, the Smartphone was kept.

Windows CE 5.0

Released in 2004, but it wasn't until 2005 when Windows Mobile 5.0 devices became available from carriers and OEMs. WM 5.0 release was also when the naming changed to the following:

  • Windows Mobile Classic (touch) would become - Pocket PC
  • Windows Mobile Standard (non-touch) would become - Smartphone
  • Windows Mobile Profesional (touch) would become - Pocket PC Phone Edition/Windows Mobile 2003
Windows Mobile 5

This was a major release for Microsoft from a platform perspective and developer story perspective. This was when Visual Studio 2005 with the .NET Compact Framework 2.0 was released which contained many many enhancements. Some of the great features from a platform perspective were an intermediate GPS driver which allowed developers to code against an API to get GPS data. Previously developers had to write very low level code to parse NMEA sentenses from a serial port (bluetooth or infrared) which was painful. In addition only one application could open the port and read data at anyone time.

Previous to WM5.0 there was no support for an embedded GPS chipset. Another cool feature was a standard Microsoft stack for communicating with the devices camera. Previously you had to code against the OEM's SDK which changed from device to device. A new flash file system was employed so files didn't exist in RAM taking up valuable memory so enabling a persistent store for all files. Some of the later devices included the .NET CF 2.0. Of course support for C# 2.0 was a massive benefit for the managed developer. The new security model was also introduced in this released - a requirement from the carriers which has caused major pain for ISV's and developers. This is not going away, sadly.

Windows Mobile 6.0/6.1

Windows Mobile 6.0 was released in 2007 and 6.1 in 2008. In fact I was in Redmond when 6.1 was released in April. Many enhancements and as more and more devices are released the uptake of VGA screens (initially supported from WM5.0) are becoming more common. Now also support for WVGA screens (640x800) is becoming popular - the new X1 from Sony and the HTC Touch Pro both support these displays. It is also worth mentioning here that WM6.1 is still based on Windows CE 5.0. It's simply shell extensions that have been added. Mainly the look and feel among other things. One thing is for sure, the performance is greatly improved over WM5.0.


See here for the Windows Mobile 5.0/6.0/6.1 SKU matrix: http://www.microsoft.com/windowsmobile/en-us/meet/version-compare.mspx

Although this post has been primarilly about Microsoft device development, in a future post I will talk about other platforms and languages/developer tools such as the iPhone, the Google Android and the Symbian OS.