Then Windows Embedded Compact 2013 dropped support for the Pi 2’s ARM core, so the project was stuck on WEC 7. Finally, Microsoft has moved away from the entire Windows CE/Windows Embedded Compact OS, so I really didn’t see a reason to update the BSP. I still love Windows CE and still support a variety of Windows CE and Windows Embedded Compact projects but unless someone really needed the port, I’m not going back to the Pi.

Microsoft has (finally) announced Windows Embedded Compact 7.  The release would more appropriately be called Windows CE 7 but the marketing people decided they knew better.  This is a significant update to Windows CE (oops, Compact, or Embedded Compact, or Windows Embedded Compact, or WEC) with an updated kernel, network stack, better integration with Win 7 device technologies and lots more.

The big news from a technical perspective is OS support for multicore processors (I’ve run it on a 4 core ARM CPU and it rocks!) and support for up to 3 GB of physical RAM.  The new kernel also supports ARM 7 (but as a tradeoff, ARM 4 support is dropped).

The network stack has been upgraded to a more modern version of Winsock.  A component has been added to allow WEC-based devices to integrate seamlessly into Windows Device Stage.  They’ve also added back the Office Viewer applications that were removed in CE 6.

Silverlight For Embedded, first released in CE 6 Release 3, has been updated to support Silverlight 3 constructs and is accompanied by a powerful development tool that eases the integration work to hook in the C++ code behind. Multitouch and gesture support has also been added.

There’s lots more to this significant release.  Check out www.microsoft.com/windowsembedded/en-us/products/windowsce/compact7.mspx for details.

There is a huge amount of interest in the new Windows Phone platform.  This new platform is new and cool and provides a great platform for applications.  The new Windows Phone programming model uses a custom built Silverlight runtime to execute 3^rd party applications.  Native code access to the system is limited to Microsoft and OEM / Cell Carriers that have access to the proper certificates.

While managed application development is quite limiting to those of us who have had the freedom of the system for over 10 years of Mobile devices, it’s clearly easier to develop a good looking Silverlight application than it is to write the same application using the basic Win32 API.

So, unless you work for a device manufacturer or cellular carrier, you’re left with writing Silverlight apps that not only can’t access the system and, according to Microsoft, can’t even run in the background.  To quote SNL’s Seth Myers; “Really!?!”  Fortunately, applications aren’t quite that limited.

First, a caveat.  This post is based on some investigations of the current emulator image provided in the April refresh of the Windows Phone tools.  There may be changes by the time the OS reaches “real” hardware or simply due to changes due to tuning as the OS comes close to release.  Now, with the lawyers satisfied, let’s look at what is “really” going on.

Basic Application Start up and Termination

Let’s do some basic stuff first.  The user can switch from a running Windows Phone application essentially two ways.  First, the user could hit the Back button while the application is running.  If this occurs, the OS closes the application. If the user later starts the application, a new instance of the application is launched.  It’s the responsibility of the application developer to restore any state to the application to reproduce where the application was when the user hit the back button.

Applications can be notified of startup and shut down by adding the appropriately named Application_Startup and Application_Exit events fired by the System.Windows.Application class.  You can add handlers for these events two places.  The first way is to add the event by adding attributes to the Application class element in App.xaml.

The other way to hook these events is to do it programmatically in the Application class constructor.  This is the way the default Windows Phone template code hooks the third Application class event, UnhandledException.

When the application is started, the class constructor is first called then the Application_Startup event handler is called.  When the application terminates, the Application_Exit event handler is called.

Suspending and Resuming an Application

If the application is running and the user hits the Windows or Search buttons, the application is not (normally) terminated.  Instead the OS places the app in a “suspended” state in memory.  If the user later returns to the application either by restarting it or simply hitting the back button to dismiss the newer screens, the application resumes.

In these cases, the Application_Exit event isn’t fired since the application never terminated and since it was never restarted the Application_Startup event isn’t fired on resume.  However, there are two events that are: WindowsPhoneEvents.Pause and WindowsPhoneEvents.Resume.  These events are in the Microsoft.Phone.Execution namespace.  They can be hooked in either the Application class constructor in App.xaml.cs or the MainPage constructor in MainPage.xaml.cs. These events fire as expected, when the application goes into the background and then when it returns to the foreground.

If the application terminates, the Pause event fires before the Application_Exit event, so you can use the Pause event has an indication of both suspending and exiting.  In general, this is also true if the application is running in the background.  The Pause event will fire on going to the background and then when the application is terminated, the Application_Exit typically event fires.  I say typically because I’ve seen places where the Application_Exit event doesn’t fire if the application is in the background. This may be a bug in the current implementation, but it is something you should know.

Background operation

The Windows Phone team made waves when the platform was introduced by indicating that, at least initially, Window Phone would not multitask 3^rd party applications.  The answer sounded pretty absolute.  The actual implementation isn’t.

This isn’t the place for a treatise on multithreaded managed applications. But briefly, very briefly, Windows Phone applications can be multithreaded.  The main thread of the application calls the appropriate methods to create the main application form and is the “user interface thread”.  Other threads created by the application can’t directly interact with the user interface.  These threads are called “worker threads” or “background threads”.

When an application is sent to the background, the foreground thread is suspended.  However, any worker threads currently running in the suspended application continue to run.  These worker threads can call base class library methods such as querying the file system, reading and writing files, and such even while the application is “suspended”.

When a worker thread tries to invoke a method on the foreground thread, that request is queued but not executed.  When the application is resumed, the queued calls are invoked.

Of course, “suspended” applications live on borrowed time.  If the system needs the memory used by the application it will be terminated.  At that point, the Application_Exit event should (but sometimes doesn’t) fire.

A Feature and a Consequence

So, while true multitasking doesn’t exist on the Windows Phone, applications can ‘borrow’ some background processing time as long as the system is lightly loaded. This sounds great and can be used to the advantage of the application.  However, developers should understand this “feature” and if their applications have worker threads that don’t need to run while the application is suspended, they need to ensure that those “worker” threads block while the application is suspended.

It should go without saying that all threads should block (almost) all the time.  Threads that poll or simply run too long will quickly drain the battery of any mobile device.  A poorly written worker thread combined with the system’s ability to run these worker threads while suspended could easily ruin the battery life on a phone.

The new Windows Phone platform has attracted interest from a vast array of .NET developers who are quite familiar with desktop and server development.  However, phones, PDAs, and other battery powered devices are very different animals.

Remember, you’re developing on a phone, not a desktop, things are different down here!

Okay, I’m not the best blogger in the world.  Actually, I’ve been a horrible blogger.  Aside from the trip blog I did last year, my last post was 2 years ago…  Still, I’m going to try, try again.

Windows Phone has finally gone public.  As it is a direct descendent of the Windows Mobile series (despite the marketing effort to separate the two) it’s right down my alley.  I’m going to blog about the platform and some of my other interests.  We’ll see how this restart goes…

One other thing… I’m battling spam comments so until I can get this worked out I’ve disabled comments on the blog.  If you have a comment, send me an email.

Doug

I have a Thinkpad T60p and I wanted to upgrade to one of these new 7200 RPM 320G disks.  I purchased a Seagate Momentus drive and, as I’ve done with other disk upgrades, just plugged the drive into the laptop and launched my system restore DVD.

While the drive could be seen by the BIOS, the restore app couldn’t see it.  I tried a number of things, including hard wiring the disk to SATA 150, which the PC expects.  Unfortunately, nothing worked.

I eventually ran across a BIOS setting that set the hard drive controller into “compatibility mode”  I resisted this approach for a while as  typically compatibility == slow, but after looking into it I learned that compatibility mode simply meant that the controller disabled the AHCI mode in the drive.

What surprised me was that with a little research (Google is great if you know what you’re looking for) I found out that the install code for Windows XP (and my restore disks) didn’t understand ACHI disks.  So how did I get around this problem when I restored my system last year?

The answer was that the Hitachi disks that I’ve previously been faithful to (Hitachi purchased IBM’s DeskStar/TravelStar drive biz a few years ago) disabled ACHI mode by default so the BIOS setting didn’t matter for those drives. Now that I had a Seagate drive, I needed to make the mod in the BIOS.

Once I made the change things worked just fine.  I can re-enable the mode if necessary with an XP driver update but AHCI isn’t apparently necessary on a single user laptop, so I may keep things the way they are.

Live and learn.

Doug

Hi,

My name is Doug Boling and I’ve been working on Windows CE since before it was released by Microsoft in 1996. I’ve written a book on Windows CE called appropriately enough Programming Microsoft Embedded Windows CE The book is now in it’s 4th edition. You can find the book on Amazon here.

These days I spend my time consulting and teaching classes on Windows CE and Windows Mobile systems.

After years of resistance, I’ve finally been assimilated into the blogging world. I hope to use this blog to provide useful information on Windows Embedded CE, Windows Phone and the old Windows Mobile platform and to occasionally vent on things that matter to me. I hope the information in the blog will be useful. We’ll see how things turn out.

Doug