My BSP is going to be released as “Shared Source” so that anyone can use the BSP to run Windows Compact 7 on the device.  Shared Source is Microsoft’s version of a source code license that allows the user to do just about anything they want including putting the code in a shipping product.  It’s not ‘viral’ like GPL where the any code derived from GPL code must also be GPL.

Given the nature of GPL and the rather zealous nature of some of its proponents, I wanted to avoid any accusation that I was taking GPL code and putting it into my BSP.  To minimize that possibility, I’ve avoided looking at any source code for the Raspberry Pi’s Linux distros.  I have been reading various web sites, but I haven’t downloaded any source.  I did download a binary of a boot disk so that I could test the hardware and ensure that it works.

This clean room approach is problematic given that the full programming manual for the Broadcom BCM2835 (the CPU on the Pi) is not public.  Broadcom has provided a peripheral manual that discusses the register addresses / functions of some of the embedded peripherals but it’s not complete.  Still, throughout the project I plan to stick to my guns about not looking at the Linux port.

More soon…

They’ve been pretty hard to get one of these devices but with the help of a kind soul across the pond, I’ve managed to get hold of one.  While the Pi organization is has various versions of Linux running on the device, I’m going to develop a Windows Embedded Compact (Windows CE) Board Support Package so that I can run WEC on the device. It should be an interesting project that I’m going to document my work here in the blog.  We’ll see how it goes…

In 2011, those similarities remain features of Windows Embedded Compact 7, the latest version of Windows CE. The Win32 API, file formats, and GDI/User UI remain. However, the desktop has moved, along with the other players in the industry to a more “Internetty” style user interface where the user interface is defined in a markup language and the intelligence of the application is written in code typically referred to as “code behind” Apps following this paradigm include browser-based UIs using HTML and JavaScript, along with Flash-based apps. Microsoft has pushed Silverlight, its rich-UI, cross platform, browser based solution as its entry into this programming style. Silverlight combines a power UI description language XAML, with CPU independent managed (.NET) code as the code behind. Silverlight runs across lots of browsers and even on Mac OS X systems.

Microsoft’s Embedded team has adapted Silverlight technology for use on Windows Embedded Compact, taking the powerful XAML driven rendering engine but replacing the (somewhat problematic) managed code back end with native C++ code. Running native code dramatically decreases startup time, enables direct access to the Win32 API and drivers and avoids that annoying garbage collection pause that eliminates managed code from driving real time applications. “Silverlight for Windows Embedded”, or SWE as it’s sometimes known, is a huge differentiator for Windows Compact, providing a powerful user interface engine that simply is head and shoulders above the competition.

So, how does one write an SWE application? First, download an evaluation copy of Windows Embedded Compact 7 here. If you’re not in Korea where lightning fast broadband is the norm, expect this to take a while as the download is massive. You can also contact your local Windows Embedded Rep. to get the multi-DVD package. If you are currently developing with Windows Embedded CE 6, you’ll want to install Compact 7 on a separate machine or in a VM as CE 6 and Compact 7 can’t be installed side-by-side.

With the evaluation copy of Windows Embedded Compact 7, you’ll also get an eval copy of Expression Blend 3, which is the tool used to assist in designing the SWE application’s front end. SWE uses Blend 3 because the Silverlight rendering engine used in SWE is Silverlight 3 based.

There is a great blog post on the SWE Blog that describes your first SWE application. There are other posts on how to create a Compact 7 image that supports SWE as well as one that describes how to create a control with SWE. Unfortunately, there isn’t much activity in the blog with the last post being August of 2010. However, the content that is there is quite is informative.

There was an earlier version of SWE that shipped with Windows CE 6 Release 3. However, this version supports only Silverlight 2, is slower than the Silverlight 3 version in Compact 7 and doesn’t have the powerful translation tool that auto generates the C++ native code framework from the Blend project. Some folks that used the CE 6 R3 version came away with a bad impression. The new version in Compact 7 is much better. I hope those early adapters will give the new version a try. It’s a whole new ballgame.

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

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.