Some curious facts about the Windows Phone 7 OS - from the emulator console

There is an interesting post by Nick Randolph that shows how to display the console tied to the Windows Phone 7 emulator. It is a tool that is not officially documented by Microsoft but nonetheless provides some insight as to how the mobile system works. After looking at the output for a while, here are some general observations about the Windows Phone 7 OS. The guys from xda-developers are probably well-aware of the possibilities, but this is an open method that is accessible to general public and can be tested with the existing WP7 SDK.

If the console is enabled, for some cases it is possible to see some failed loads that are referenced in CPP source files inside an actual folder:

Notice the actual path used: w:\winceroot\private\comnsplatform\ccmapi\lib\ It is safe to assume that winceroot is the main system folder that contains system data (e.g. the system libraries and language files). What's interesting is the fact that the output shows there are actual CPP files (C++ source files).

Similarly, when the application is installed on the current system instance, it is possible to track down the installation path:

Looking further, there seems to be an internal console (also known as a terminal) that accepts command related to system behavior:

While the emulator is loading the application and even when the user is in the actual system layer (e.g. using system functionality rather than an app), these commands will be shown. The purpose of each of them currently is unknown to me.

Same as in any version of Windows (plus, given the fact that Windows Phone 7 is based on the CE 6 kernel), windows  (as in application windows) have handles:

Unfortunately, there is no direct method to access the window handle since the system is pretty much a closed environment. As you can see from the image below, there is also a registry (not new - the same was present in previous releases of Windows CE) and there seems to be a resource cache:

It's interesting to see how resources and applications are called internally. Via a system navigation service, those are referenced with a res:// prefix. For example:

This would be the web browser. Whenever the user navigates to a specific system component, it seems to be called via the same resource accessor (e.g. Settings and even every separate widget there):

Whenever I tried sharing anything from the web browser, I was only able to access the message shaing mechanism (mocked SMS):

That would be my only choice in a locked emulator, however when I took a look at the console, there was an interesting thing shown:

There is actually a FBAuthClient.dll that links the phone to a Facebook account but due to specific policy restrictions, the emulator fails to load it (although there is an attempt).

There is much more in the console and I tried to highlight the most important parts. All this functionality is currently unavailable as a part of the public SDK. Currently, there is no navigation service that would allow a developer navigate to a system resource (read: item in the system application/widget list) - the current NavigationService doesn't play a major role here and will block all outgoing requests to a resource. Files as well as the registry are also not accessible for now, although there was already a workaround mentioned that allowed native invocation. The purpose of this short review is mostly educational - out of curiosity, it is interesting to see what goes behind the curtains, even though you cannot access it via documented methods.