Windows Phone 7 Series Programming Model


Bidar - Barid Shahi tombs


Just sometime back I posted on the MIX 2010 announcements. One of the major aspects of the announcement was


“The application model supported on Windows Phone 7 series will be managed only and will leverage Silverlight, XNA and the .NET Framework”


That’s a mouthful and includes 3 framework names in once sentence :). This was already disclosed and has resulted in some flutter over the web and twitter. Let me try to explain how these 3 interplays in the application model with the following diagram


image


Managed only


First of all the application model allows users to write only managed code (to repeat native code is not allowed). That means they do not have direct access to any native APIs and cannot use platform-invoke to call into native user or system code. So all resources including phone capabilities have to be accessed using the various managed APIs provided.


Two Flavors of applications (XNA and Silverlight)


There are 2 variants or flavors of applications users can write, XNA Games and Silverlight applications. Obviously the former is for writing games and the later is for your typical phone applications (nothing stops you from writing a Silverlight animation based game though). So you cannot mix-match SL and XNA UI in the same application.


However, do note that the traditional NETCF development using WinForm based UI is not supported.


Common Services available to both


That said, beyond the UI rendering and controls there is the common services which both SL and XNA applications can use. This includes all the phone capabilities like microphone, location, accelerometer, sound, media, networking, etc… Some of these features come from SL and others from XNA but land up in the common pool usable by either types of applications.


Core Runtime is .NET Compact Framework 3.7


The core runtime for both SL and XNA applications is .NET Compact Framework (henceforth called NETCF). This is the team I work for.  .NETCF is a highly portable and compact (as in smaller size and footprint) implementation of the .NET specification. It is designed to run on resource constrained devices and on disparate HW and SW configurations.I will have a post later on the detailed architecture or .NETCF.


Over the last two years a lot of work has gone into .NETCF to scale it in terms of features, performance and stress to meet the requirements of Windows Phone and other newer platforms on which it is being targeted. We also added a lot of features which I hope you will enjoy. Some of the features is just to reach parity with the desktop CLR and others are device specific and not available on the desktop.


Over this blog in the course of the coming months I’ll try to share with you what all we did to reach here.

Comments (23)

  1. Mick.Lang says:

    Firstly, can you confirm applications running on Compact Framework 3.5 cannot run on Phone 7 ?

    Secondly, how does an enterprise deploy a LOB application on Windows Phone 7?

    For many enterprise LOB applications it simply wouldn’t be appropriate to deploy the application via a Marketplace portal open to the general public.

  2. NETCF 3.5 applications will not run on the Windows Phone 7.

    Recarding #2, that is outside my area of expertise. It is however, being discussed in the forum

    http://social.msdn.microsoft.com/Forums/en-US/windowsphone7series/thread/71769792-db5b-45df-a498-49a0f21bf9c6

  3. Fowzi says:

    Will NETCF 3.7 be released as a stand alone release for platform builders? Will I be able to get NETCF3.7 and integrate it on a MIPSII device? the same question apply to SL and XNA. or are these 3 framework only for the Mobile Phones?

    Thanks,

    Fowzi

  4. Fowzi, right now NETCF 3.7 is targetted only for Windows Phone 7 series for both the Silverlight and XNA variants.

    Currently there is no work underway to make it available for integration to other platforms.

  5. foo says:

    Why did you remove features from the NETCF in this release, which were available in previous versions of the CF, such as XmlDocument or HttpWebRequest.GetResponse()?

  6. System.IO.Compression was an important block. Why remove it from .NET CF 3.7? What’s the rationale? Where can we get a clear list of changes between .NET CF 3.5 and 3.7?

  7. Martin, I do not think approaching WP programming model from the pre-existing NETCF 3.5 will help. The differences between them are of the same magnitude as the difference between WinForm and Silverlight on desktop.

    On Windows Phone NETCF provides the runtime and implements Silverlight 3 surface area (with a small delta). If something isn’t present in Silverlight it’s not present in Windows Phone. There is no list comparing NETCF 3.5 with WP7 programming model as we didn’t approach it that way. On WP you need to target the silverlight surface area and there are documentation around the delta between Silverlight and WP7.

    I do understand your pain. Please do understand that the current bits are early preview bits. Hopefully soon we will have guidance for existing NETCF customers to move to the new programming model.

  8. Its good to know that WP7 development can be done using managed code. However, where can I find APIs to deal with POOM? Previously, it was in WM SDK. Now, will it be available in (may be) next version of WP7 SDK? Apart from this, how can I handle calls, sms (Phone.Talk() kind of)? Where can I find tool like Cellular Emulator?

    I know, these are too many questions, but its pretty exciting to work on WP development.

  9. Rene Lindsay says:

    This is MADNESS!

    On WinCE, .NETCF was REDICULOSLY SLOW, compared to native code.

    The PPC cant handle a JIT compiler, so .NETCF is interpreted byte code, just like embedded VB. Surely thats why eVB was dropped in favour of native compiled eVC++.

    However, eVC++ is cumbersome for writing GUI’s. So I tried porting my Chinese Dictionary app from eVC++ to .NETCF. However .NETCF would take MINUTES to load my database, yet the same task is almost instant in native code.

    I finally scrapped the .NETCF effort, and started over in Lazarus FreePascal with KOL-CE.

    This setup makes small, fast apps, just like eVC++, yet makes the GUI almost as simple to create as in Delphi.

    Anyway, my point is .NETCF is not a realistic option, so if native code is not supported, then its time to move to a new platform.

  10. Rene sorry for the experience you had. However, did you see the MIX demos? We actually have realtime 2D/3D games and a lot of very resource hungry apps running over this. Traditionally large SQLCE based apps also run well on NETCF.

    NETCF is JITted and not interpreted byte code. I think that you should’ve contacted us when you ran into the problem you mention so that we could’ve helped you in fixing your code so that it worked correctly.

  11. Rene Lindsay says:

    Hi abhinaba,

    Thank you for your reply, and I wish I DID ask for your help at the time.  Besides the slow performance of NETCF, I had a bad experience with SQLCE too.

    My original app was written in eVC++ with a CEDB database.  Performance was fine, but ActiveSync would crash if I inserted more than 2400 records into a single Pocket Access table.  

    The SQLCE format allowed more records, but my 380kb .cdb database grew to more than 800kb in .sdf format, which is unacceptable.

    Also, data replication with SQL Server was buggy.  A later (incompatible) version of SQLCE fixed this bug, but required .netcf2!

    The DB size was still too bloated though.

    When I dumped .netcf and switched to FreePascal, I wrote my own little database engine, which is faster, and stores the same data in just 46kb. SQLCE’s .sdf database is a very bloated format indeed.

    To be honest, much of my trouble was probably due to the fact that I was using an early version of SQLCE, with .NETCF 1.0, and the Delphi for .NNET Compact Framework preview compiler.  Maybe things have improved since those days, but for now I’ll rather play it safe and switch to Android. (iPhone’s SDK EULA is too restrictive.)

    Both iPhone and Android started off banning native code too, but they both came to their senses, and eventually released a native code SDK.  Maybe Microsoft will too?

  12. Panam says:

    Hi abhinaba,

    Currently I’m using OMA Client Provisioning for device management in WM6. Can I use it in WM7? Thanks.

  13. Sorry Panam I have no idea about OMA please post the query on the WP7 forums

  14. Rene Lindsay says:

    Hi abhinaba,

    I’m still a bit reluctant to abandon WinCE in favour of Android.  It would be a shame to lose the OpenGL ES and eVC++ skills I learned on WinCE.

    Although I think .netCF is too slow, I know that Android’s Java is even slower. But, at least Android has OpenGL ES, SQLite and allows native C++ for speed critical code.

    Will OpenGL ES and native C++ be available for WP7 some time in the future, or will it remain .netCF and XNA only?

    I learned the hard way to avoid Mobile DirectX, .netCF and SQLCE on WinCE.

    There would have to be some major improvements to all three if they are to stand a chance.

  15. Rene the last time you used .NETCF was 1.0? That was like 10 years ago. Today on WP7 we are successfully running 3D XNA games with great performance. I’d suggest you actually give this a spin before making up your mind

  16. Rene Lindsay says:

    Thank you abahinaba, My .NetCF 1.1 project was 6 years ago, so I’ll take your advice and give it another try.

    However just last year I was involved in a major project to convert an evC++ Mobile DirectX application to use OpenGL ES, since mobile DirectX was performing poorly and seemed to be abandoned by Microsoft.  Its too late to switch back now, hence my frustration.

    Our GPU/hardware manufacturer also insists that OpenGL ES is the way to go, and no longer support mobile DirectX on their latest GPU’s.

    OpenGL ES certantly is easier to use too.

  17. Dave says:

    Unbelievable that Microsoft completely abandoned its entire corporate base.  The tons of time and resources spent on NETCF/SQCE applications will be a complete waste in a year or so when WM6.5 phones are no longer available.  Silverlight is worthless for secure data-intensive business apps.  

  18. @Dave – the corporate base hasn’t been eliminated. Microsoft’s approach for this operating system was to focus on the features most important for a good consumer experience. Corporate needs will be addressed later. Keep in mind the first release of Windows Phone will not be a feature complete release.

    Also unlike previous versions of Windows Mobile you’ll find that Windows Phone 7 will be getting updates. On Windows Mobile a device was pretty much feature locked when you received it. If you were lucky you may have gotten one firmware update but beyond that the capabilities of the OS on the day you got your device would never change. Since Microsoft will be pushing updates with WP7 features that are missing at launch may be available later.

  19. Vadluri Sreenu says:

    Is it possible to connect windows server 2003/2008 active directory using windows phone 7(without web service/wcf)?

    i tried, but i didn't get any solution for that.

  20. J. C. says:

    I smell a rat when it comes to Windows Phone 7.

    It is no secret that, for a long time, consumers and technology critics have (mistakenly, in my opinion), concluded that Windows Mobile was an inferior "operating system" compared to those for BlackBerry, Apple's gadgets, etc. This perception is incorrect. What was more correct was that the facade, the appearance, the thin visible layer of the user experience, was inferior. This thin, facade, is ~not~ the operating system, and the fact that it was somewhat unpolished is, technically-speaking, ~not~ Microsoft's fault.

    Ironically, of all the OS's on mobile devices, most systems experts, as in people who have knowledge of computers from digital logic, through CPU's, registers, assembly language, kernel-mode systems, device drivers, kernel-user interfaces, synchronization, threading, etc.; know that Big Windows and Windows CE are state-of-the-art compared to other OS's. By this, I mean to say that, if yolu are a serious engineer doing serious software development (as in you actually know what you're doing in software engineering, not stressed by pointer arithmetic or spin locks), Windows, more than any other OS, got the plumbing right, which is important, because you can always get a UI to look snazzier. Trying to find the equivalent of WaitForMultipleObject on a non-Windows OS, however, is another matter, and the handicap of not having it can be severe.

    So where is the rat?

    The rat is at Microsoft.

    There are actually two rats, in fact: a small rat and a large rat.

    The small rat is the hoarde of .NET fanatics who finally got their way, by making Windows Phone 7 a .NET-only, no-native code, platform. This stinks, and I can say with 100% certiftude that I will be switching to non-Windows if Microsoft does not change this policy soon.

    The large rat comes from a place you might not expect. It's the large cellular companies. Yes! The cell phone companies! In a nutshell, Windows Mobile, and the other OS's, for that matter, on smart phone, means power – power in the hands of developers. It means the ability to do many..many things with a mobile device that is essentially a small computer. This frightens the cell phone companies greatly, especially Verizon. This is why Verizon did a battery of talks with Google regarding Android. Verizon was actually quite threatened by Android, and moved quickly to "keep its enemy close." I am 90% certain that these cell phone companies have also been in talks with Microsoft, about what capability to include and what not to include in the "platform" for phones. The last thing Verizon wants to see is for someone to start using a PDA as as a phone, but not on Verizon's network. By restricting developers to XNA, Silverlight, and .NET, the power of the device as a computer becomes severely limited.

    So Microsoft caved in. And also, the management was sold on the "…we need to make everyone use .NET, and sandbox them…and control everything, to get the same experience as Apple…and have fewer glitches and irregularities in the user experience.." pitch. It's not true, IMO, but Ballmer obviously bought it.

    I say unto you Microsoft: be very careful.

    Unlike the desktop, you do not have the same developer loyalty on mobile. The last thing you want is for your brightest engineers to start experimenting with an alternative, non-Windows platforms because you tried to box them in with .NET, knowing full aware that they prefer C++, native-mode. These engineers will ask themselves the same question I am asking now – "What platform for PDA's allows me to program in native C++?" There is a chance you will end up creating nightmarish double-trouble, where senior developers not only refuse to program .NET on Windows Phone 7, but they haphazardly discover the benefits of using one code-base on a non-Windows PDA…~AND~ on another PC…a PC runing…Linux!

  21. J. C. says:

    I smell a rat when it comes to Windows Phone 7.

    It is no secret that, for a long time, consumers and technology critics have (mistakenly, in my opinion), concluded that Windows Mobile was an inferior "operating system" compared to those for BlackBerry, Apple's gadgets, etc. This perception is incorrect. What was more correct was that the facade, the appearance, the thin visible layer of the user experience, was inferior. This thin, facade, is ~not~ the operating system, and the fact that it was somewhat unpolished is, technically-speaking, ~not~ Microsoft's fault.

    Ironically, of all the OS's on mobile devices, most systems experts, as in people who have knowledge of computers from digital logic, through CPU's, registers, assembly language, kernel-mode systems, device drivers, kernel-user interfaces, synchronization, threading, etc.; know that Big Windows and Windows CE are state-of-the-art compared to other OS's. By this, I mean to say that, if yolu are a serious engineer doing serious software development (as in you actually know what you're doing in software engineering, not stressed by pointer arithmetic or spin locks), Windows, more than any other OS, got the plumbing right, which is important, because you can always get a UI to look snazzier. Trying to find the equivalent of WaitForMultipleObject on a non-Windows OS, however, is another matter, and the handicap of not having it can be severe.

    So where is the rat?

    The rat is at Microsoft.

    There are actually two rats, in fact: a small rat and a large rat.

    The small rat is the hoarde of .NET fanatics who finally got their way, by making Windows Phone 7 a .NET-only, no-native code, platform. This stinks, and I can say with 100% certiftude that I will be switching to non-Windows if Microsoft does not change this policy soon.

    The large rat comes from a place you might not expect. It's the large cellular companies. Yes! The cell phone companies! In a nutshell, Windows Mobile, and the other OS's, for that matter, on smart phone, means power – power in the hands of developers. It means the ability to do many..many things with a mobile device that is essentially a small computer. This frightens the cell phone companies greatly, especially Verizon. This is why Verizon did a battery of talks with Google regarding Android. Verizon was actually quite threatened by Android, and moved quickly to "keep its enemy close." I am 90% certain that these cell phone companies have also been in talks with Microsoft, about what capability to include and what not to include in the "platform" for phones. The last thing Verizon wants to see is for someone to start using a PDA as as a phone, but not on Verizon's network. By restricting developers to XNA, Silverlight, and .NET, the power of the device as a computer becomes severely limited.

    So Microsoft caved in. And also, the management was sold on the "…we need to make everyone use .NET, and sandbox them…and control everything, to get the same experience as Apple…and have fewer glitches and irregularities in the user experience.." pitch. It's not true, IMO, but Ballmer obviously bought it.

    I say unto you Microsoft: be very careful.

    Unlike the desktop, you do not have the same developer loyalty on mobile. The last thing you want is for your brightest engineers to start experimenting with an alternative, non-Windows platforms because you tried to box them in with .NET, knowing full aware that they prefer C++, native-mode. These engineers will ask themselves the same question I am asking now – "What platform for PDA's allows me to program in native C++?" There is a chance you will end up creating nightmarish double-trouble, where senior developers not only refuse to program .NET on Windows Phone 7, but they haphazardly discover the benefits of using one code-base on a non-Windows PDA…~AND~ on another PC…a PC runing…Linux!

  22. kaiwalya Joshi says:

    Hi Abhinaba;

    We have an application that is developed using Win32 SDK ( C++ ) for Windows Smart phone (5 to 6.5)  which interacts with API that gives us various events such as, Call has ended and details of it, SMS sent / received and its details , addition of custom menu in POUTLOOK for accessing the email and inter process communication using Win32 SDK message passing etc. For this to happen the application runs constantly in the background.

    Whats the possibility of porting this application to Windows Phone 7  ? From the above post is seems its not possible (at least for now ! or never !!! ).

    Waiting for your reply…..Thanks and Regards,

    Kaiwalya Joshi…

  23. Disgusted says:

    Wish we never wrote a single line of code for Windows Mobile…

    And, after disregarding and disrespecting thousands of developers like us, now Microsoft expects us to spend time and money to port our C++ code to this C# silverlight bimbo envirnment?

    No thanks.

    Nice to meet you Android: here we come…