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.

I saw a blog post today saying

“You Already Are A Windows Phone 7 Programmer”

Implying that if you know Silverlight, you can develop for Windows Phone.

Those who think they can write a Windows Phone application the same way they can write a Silverlight app are in for a rude awakening.

I’ve written Windows CE and Windows Mobile applications for close to 15 years now.  I’ve even written a book about it. I’ve heard this line before. First it was “Windows CE uses the same Win32 API as the desktop, so you’re already an Embedded Programmer!” Then there was “.NET Compact Framework is the just like desktop .NET so you’re already a Windows CE/Windows Mobile developer!” Now this one… It’s all Big Lie #3, “This time it’s different!”

Windows Phone devices are fundamentally slower both in graphics and general CPU power than the desktop machine that runs a standard Silverlight application. This isn’t the fault of Microsoft or the hardware OEMs, this is by design. The slower hardware allows the phone to last a day in your pocket while a powerful radio receiver waits for the next phone call. (Not to mention the WiFi and GPS receivers.) This makes trivial things like garbage collection events distractingly noticeable to the user. The low speed system drive fundamentally different application architectures.

In addition, the user interface is fundamentally different. The phone has a much smaller screen 480 x 800 with a different user input paradigm (touch/gestures) compared to the much larger desktop monitors and classic keyboard / mouse input. This causes you do design a fundamentally different user interface.

Finally, there is the user. Silverlight applications are used by people seated, at a desk or table, and are stationary. The users of a Windows Phone application are (here’s a word the WP folks hate to say…) “Mobile”. Users are walking, or worse, driving while using your application. This makes performance, as in how quickly screens respond to input, as a safety issue. Users who spend time waiting on a screen to change tend to walk in things. I’ve actually seen this happen by “crackberry” and other PDA addicts at the airport.

I’m not saying that you shouldn’t write a Windows Phone application.  In fact, I encourage it.  However, the concept that you already know what you need to know to write a WP app is worrisome. It sets too the expectations far too high.  This isn’t good for Windows Phone.

I’m also not saying that the WP folks at Microsoft are being deliberately deceptive.  The marketing folks are just trying to get a large audience to check out the platform.  Still, its a tune I’ve heard before.

So, when I hear that Windows Phone development is just like the desktop I just smile. As a friend of mine said, “Just because it compiles doesn’t mean its right.

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 Startup 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!

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

 I just returned from the Microsoft TechEd conference in Orlando.  While there, I gave two talks and presented a Preconference tutorial. During the preconference tutorial, I discussed changes to the Windows Mobile 6.1 memory model.  Here is a short summary of the changes.

Despite the implication of the “6.x” version number, Windows Mobile 6.1, like Windows Mobile 6 and Windows Mobile 5 are based on a modified Windows CE 5.0 kernel, not the newer Windows Embedded CE 6 kernel.  The “old” kernel uses the slot based model for memory management shown in the figure below.

Processes are assigned a “slot” from 2 to 32 allowing up to 31 processes. (The kernel is counted as the 32^nd process.)  The process with the currently running thread is cloned into slot 0.  This allows each application to act as if it is running in slot 0 since when a thread in a process is running that process is in slot 0.  Slot 1 is used to load DLLs that have been bundled with the system.  Slot 63, at the top of the Large Memory Area, is used to store resource only DLLs, those DLLs that have no code, only resource data such as fonts and strings.  More detail on this memory model, and the problems associated with it can be found in a white paper I wrote a while back titled Windows CE Advanced Memory Management.  (For those interested in Windows Embedded CE 6, I wrote paper on CE 6 memory management here.)

The problem with memory in Windows Mobile has always been the vast number of DLLs in the system.  DLLs are loaded from the top of slot 1 down.  Since there are so many DLLs in the system, not only do they fill up slot 1, they encroach into slot 0.  This leaves only about 18-20 Meg of virtual space for each application.  This problem is most acute in the Device Manager process space where dozens of device drivers, each with their own interrupt service thread, tended to consume most of the virtual space in that process.

This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0.  However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.

In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot.  Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. 

In addition to the stack move, changes were also made in where DLLs are placed.  While execute-in-place(XIP) DLLs are still loaded from the top of Slot 1, any DLL that is larger than 64 KB and isn’t XIP is loaded in slot 60.  If the 32 MB of slot 60 fills up with DLLs, the OS uses slot 61 for the DLLs.   This additional 64 MB of DLLs space should go a long way in reducing the problem of too many DLLs in Windows Mobile systems.  The new memory map now looks like this:

The shared heap slot was added in Windows CE/Windows Mobile 5 but its addition wasn’t an attempt to solve the DLL problems with Windows Mobile. While in this diagram it looks like the large memory area has been shrunk significantly, it really hasn’t.  The LMA size, which is close to 1 GB was only reduced 128 MB. 

To take advantage of this change, OEMs who build Windows Mobile systems need to adjust how they assign DLLs in their .BIB files.  Now, large DLLs should be moved from the MODULES section of the .BIB to the FILES section.  This change prevents the tools from converting those DLLs to XIP.  DLLs smaller than 64 KB should be left in the MODULES section.

Third party application developers really don’t have to do anything to take advantage of this new arrangement.  It has always been good practice to combine DLL code into a few, large DLLs.  Now, if that DLL is larger than 64 KB, it’ll be loaded in one of the upper slots.  This won’t change the way DLLs operate, its just you may notice some rather unusual base addresses for DLLs when you start debugging your application on Windows Mobile 6.1.

¼/p>

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 CE and Windows Mobile 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