Search

Wednesday, March 17, 2010

Comparing Windows Phone with .NET Compact Framework 3.5

Bidar - Fort

In the comments of my previous post Windows Phone 7 Series Programming Model and elsewhere (e.g. twitter, WP7 forum) there seems to be a lot of confusion around how NETCF 3.5 compares against the new WP7 programming model powered by NETCF 3.7. People are asking why some API got removed from 3.5, or is 3.7 a subset of NETCF 3.5 as they are not seeing some familiar 3.5 APIs.

First I’d urge you to go visit the Windows Phone 7 Series Programming Model to see what it offers.

Essentially NETCF 3.5 can be broken down to

  1. NETCF 3.5 runtime (the Execution Engine)
  2. NETCF 3.5 BCL
  3. NETCF 3.5 UI programming model (WinForm based)

Now each of this has been updated (in order) as follows

  1. NETCF 3.7 runtime (hugely updated Execution Engine)
  2. NETCF 3.7 BCL (essentially offering the Silverlight 3 BCL Apis with a small delta)
  3. The UI model has been replaced and offers two options
    1. Silverlight 3 UI + Windows Phone device specific features (e.g. accelerometer , location service)
    2. XNA features with Windows Phone device specific features (e.g. accelerometer , location service)

So the runtime is hugely updated (and hopefully you’d feel the improvements, especially in performance).

For #2 and #3 the level of difference is same in magnitude as you compare WinForm with Silverlight on desktop. They are simply two different programming models.

In case you hit a 3.5 API  that’s missing then it’s either because it’s (a) WinForm based API that got totally replaced, or (b) a BCL API that the Silverlight profile doesn’t support. The workaround is to search for how to do the same thing in Silverlight (e.g. use XDocument instead of XmlDocument). In some cases you’d get into situations where there is no direct alternative. E.g. there is no P/Invoke and if your code say P/Invoked to get data from a bar-code scanner you cannot do so now.

Also keep in mind that the bits available right now is just early preview bits and subject to a lot of change. The whole purpose of having CTPs is to hear our customers and ensure we use the remaining time before release in fixing issues that helps our customers the most. Hopefully some of the gaps will get closed before the final release.

1 comment:

Stephen said...

No P/Invoke? Ouch! That one has always been a must to allow getting an functionality that was left out of the CF.

I am guessing that the Windows Phone OS is not for "enterprise" like applications (where scanners and other p/invoked integrations are a must).