I find I’m really liking the new Windows Phone 8.1 ‘Project my Screen’ feature. This feature enabled the projection of the handset to a secondary screen via wireless Miracast (newer handsets only, as it requires special hardware) or a wired USB connection. This is great for presentations and demos. It even works in the opposite direction: you can remote control your phone by interacting with the projection using your mouse or your touch screen! Also great is that it has support for displaying multiple touch points, so your audience can actually see where you touch your device. Great stuff!
If you haven’t already, I suggest you give the feature a try yourself. Microsoft’s Cliff Simpkins has done a great writeup on his blog on getting this thing to work.
In order to use the ‘Project my Screen’ feature on your Windows PC, you have to download and install the official ‘Project my Screen’ app. By default the app shows a pretty boring image of a nondescript Windows Phone, much like the Windows Phone SDK emulators do. Fortunately Microsoft included the ability to customize the appearance of the app, so it may suit our own needs. Here’s a short video that shows a quick customization I made using the application:
As you can see I’m using a custom background image featuring the Cortana logo. Also the projected phone’s skin matches my real phone (a yellow Nokia Lumia 920). Let me tell you how I did that:
If you look inside the ProjectMyScreenApp’s installation folder, which by default is located at
C:\Program Files (x86)\ProjectMyScreenApp, you’ll notice there’s a file called
config.xml. This is a XML configuration file that can be used to alter the appearance of the app. By default it’s not used by the app, though. To use it you need to explicitly launch the application with the configuration file passed in as a parameter. To complicate things a little further: in its original state the configuration file doesn’t work. It refers to images that don’t exist in the installation folder (they do exist, but are embedded as resources inside the application’s executable). So you HAVE to alter the
config.xml (or create your own file based on it) to get it to work.
So, how do we configure this thingy? Fortunately the
config.xml file itself contains instructions on how to use it. The basic structure of the file looks like this:
<?xml version="1.0" encoding="utf-8"?> <Config> <PhoneConfigurations> <PhoneConfiguration> <Background /> <PhoneImage /> <VideoOutput /> <!-- <TouchDots /> --> </PhoneConfiguration> <PhoneConfiguration> . . . </PhoneConfiguration> </PhoneConfigurations> </Config>
config.xml file contains
PhoneConfiguration elements for five different resolutions: WXGA (768×1280), HD1080 (1080×1920), HD720 (720×1280), WVGA (480×800) and FWVGA (480×854 with the new on-screen soft buttons). I suppose you can add additional resolutions as devices are released, but I’m currently not able to test this. The application will start up with a default configuration (which you can define; see below). When you connect an actual device and allow screen projection the application will switch to the configuration that matches the connected device’s resolution.
PhoneConfiguration element has three attributes. The
resolutionY values are used to specify the resolution that this configuration belongs to. The
default attribute is used to specify whether this is the default configuration to use when no device is connected.
<PhoneConfiguration resolutionX="768" resolutionY="1280" default="true">
phoneConfiguration section we can configure three settings: the background image, the phone’s skin and the size and placement of the projection. Actually, there is a fourth element,
touchDots, that’s present in the file, but I couldn’t get it to work. I suspect it should be used for configuring the appearance of the dots that appear when you touch your device, but it didn’t seem to respond to changes I made to it.
Let’s go into detail about each element:
Background element controls the application’s background. The entire app background will be filled with the specified color. On top of that you can place an image that will also be scaled to fit. Note that using a background image is optional. If you only want to use the solid background color, you still have to add the
imageRelPath attribute, but just give it an empty (“”) value.
<Background color="0x00000000" imageRelPath="Cortana.png" />
PhoneImage element you can control the appearance of the on-screen phone (i.e. the skin). The
imageRelPath attribute specifies the path to the image to use. For my demo video I used one of the official Nokia Lumia 920 press images that I downloaded from the Nokia Press media library. I cropped the image, so it didn’t have any border, and saved it as a PNG. You need to specify the path to the image relative to the ProjectMyScreenApp’s executable file. The easiest way to do this is by adding your image file to the application’s installation folder, so you only need to supply the filename without any additional path information.
scaleFactor attribute specifies the scale factor of the phone image as a fraction of the background image’s width or height, whichever is more constrained. If no background image was specified, the app window’s dimensions are used instead. I used a value of 0.9, so the phone is nice and large, but doesn’t go edge to edge.
centerOffsetY values you can position the phone image relative to the background image. I’ve used this to place my phone on the right side of the screen, so it doesn’t obscure the Cortana logo of my background image. Interestingly, if you didn’t supply a background image, these values are ignored and the phone is always displayed in the center of the application’s window.
For devices that have physical buttons we can configure the location of the Back, Windows and Search buttons. For each button you need to supply the coordinates of its bounding box. This way the application can determine which button to press when you click on the skin image with your mouse/touch screen. The
searchButton attributes accept a value that consists of four numbers that represent the left, top, right and bottom coordinates of the hardware back, Windows and search buttons.
Here’s my complete
<PhoneImage imageRelPath="Lumia920-2.png" scaleFactor="0.9" centerOffsetX="350" centerOffsetY="0" backButton="128,2357,400,2600" windowsButton="610,2357,900,2600" searchButton="1160,2357,1370,2600" />
Next up we need to specify the location of the video output using the
videoOutput element. Using the
topLeftOffsetY you specify the top left coordinates of the video image. Unfortunately you cannot specify the width of the video window. Instead you have to do some math and calculate the weight value, which is defined as being ‘the width of the video output as a fraction of the phone image’s width’. So we need determine the width (in pixels) of the phone’s image display as it appears in the skin image (i.e. the bounding box where you want to projection to appear) and divide that by the total width of the skin image. For my Lumia image that results in the following formula: 1273 / 1535 = 0.8293159609120521.
Here it is:
<VideoOutput weight="0.8293159609120521" topLeftOffsetX="125" topLeftOffsetY="233" />
So the complete
phoneConfiguration section for my Lumia 920 skin looks like this:
<PhoneConfiguration resolutionX="768" resolutionY="1280" default="true"> <Background color="0x00000000" imageRelPath="Cortana.png" /> <PhoneImage imageRelPath="Lumia920-2.png" scaleFactor="0.9" centerOffsetX="350" centerOffsetY="0" backButton="128,2357,400,2600" windowsButton="610,2357,900,2600" searchButton="1160,2357,1370,2600" /> <VideoOutput weight="0.8293159609120521" topLeftOffsetX="125" topLeftOffsetY="233" /> </PhoneConfiguration>
Now launch the ProjectMyScreenApp using the
config.xml file as an input parameter. One way to do this is starting it from a Command Prompt window like this:
C:\Program Files (x86)\ProjectMyScreenApp>ProjectMyScreenApp.exe Config.xml
You can also create a Shortcut with the parameter passed in. The ProjectMyScreenApp should start in full-screen mode. You can press the
[ESC] key to switch to windowed mode.
You can download my sample Lumia 920 files here. Just unzip the files into the ProjectMyPhoneApp’s installation folder (consider making a backup of the original
config.xml file, just in case). As a bonus I’ve extracted the default phone images that are contained within the ProjectMyPhoneApp executable and added them too.
Please note that if you connect using a device that has a different resolution than my Lumia 920, you won’t get to see the custom stuff I mentioned above. Instead the ProjectMyScreenApp will use one of the other phone configurations and I didn’t bother changing those.
Maybe someday someone will create a nice tool that assists in creating the
config.xml and/or the image files, just like Geert vd Cruijsen has done in the past with his Windows Phone 7 Emulator Skin Switcher application. Or maybe we can build a repository of compatible skin images. I’m even willing to host/link to them from here.
In any case: have fun! You know I am 😉
I am so evil… Whoahahahahaha…
Earlier today I sent out the following tweet:
So I fired up this old blog of mine to tell you why I just had to laugh:
Last night I was playing with the latest version of the popular Windows Phone 7 benchmarking app WP Bench, made by Robert Varga. Some time ago Robert added the ability to upload your benchmark results to his server and compare them with others.
However, WP Bench does not only publish the benchmarking results. It also publishes information about the phone models and the Windows Phone OS versions that are used. And these two lists have become an important source for people to scout for new Windows Phone models and OS versions. In fact, every new device/OS version that is listed in those stats is sure to get some headlines at popular news sites like WMPowerUser.com.
That’s when my evil plan starting taking shape. What if I could alter some of the data that WP Bench uploaded to its server and pretend I was using some new, unknown (and fake) Windows Phone model? Surely WP Bench had built in some mechanism that would prevent this, wouldn’t they? But I just had to try. Maybe it was possible to generate some buzz amongst the Windows Phone community and even get featured on some news sites…
First thing to do was to actually inspect what data and in what format is being sent back to the server. So I quickly hooked my Windows Phone to Fiddler, the popular HTTP debugging proxy. I started WP Bench on my phone and ran a simple speed test. I then uploaded the results to the WP Bench server.
The Fiddler Web Sessions list showed that benchmark results are uploaded to the server by using a single HTTP GET request that has all relevant result data specified as query string parameters, like this (I’ve removed my phone’s unique device ID from the URL):
What was even more interesting was that there didn’t seem to be any verification mechanism in place, to make sure this data wasn’t tampered with. No verification hashes or any of that kind. So this meant I could easily tamper with such a request and pass my own, fake, data.
I activated Fiddler’s Automatic Breakpoints feature, so it would intercept each request and allow me to edit it, before it was passed on to the WP Bench server. I again ran the WP Bench speed test and uploaded the results. This triggered the Fiddler breakpoint and I made the following changes to the request:
- I slightly changed the deviceID parameter, so the results wouldn’t be related to results I had previously uploaded using the same device.
- I changed the deviceName parameter from ‘7 Trophy T8686’ to ‘7 Mini T86861’.
The fun part of this was that I came up with the name ‘Mini’, because just days ago HTC had announced a new and very large Windows Phone device, called the ‘Titan’. I really didn’t know that HTC had actually once shipped a device called the ‘HD Mini’, which ran Windows Mobile 6.5. So I guess by accident this ‘Mini’ name added more credibility to my fake model name.
- I changed the OS version from ‘7.10.7712’ to ‘7.11.1131’, hoping that a previously unseen change from 7.10 to 7.11 would generate some buzz. Also, the 1131 part refers to the birthday of someone very close to me 🙂
I didn’t change any of the performance scores, but of course could have easily done so. After that I allowed Fiddler to send the altered request to WP Bench’s server and went to bed.
So today I visited WMPowerUser.com and sure enough there it was: a nice new article titled ‘HTC 7 Mini running OS 7.11.1131 shows up in WP Bench’. It talked about the fact that WP Bench stats showed this mysterious new model, the HTC 7 Mini, complete with a totally new OS version in the 7.11.xxxx range. There was talk about the fact that this could be the first evidence of Windows Phone Apollo running on a handset. It was also mentioned by many other news sites and of course there was some buzz on Twitter.
So that’s how easy it was to create some fake Windows Phone news. Just to be clear: as far as I know the HTC 7 Mini does NOT exist. Also there is no Windows Phone OS version 7.11.1131 (yet…). It was all made up by me. Whoahahahahaha…
Lastly, as a suggestion to WP Bench’s creator Robert Varga, I would advice him to add some sort of protection scheme, so that uploaded WP Bench results cannot easily be tampered with. I also wouldn’t list a new device/model in the WP Bench stats, unless it has been seen more than once, preferably with result uploads coming from a variety of IP addresses. Remember it took only one little request to get my fake phone to show up in the WP Bench stats.
Update: It appears Surur from WMPowerUser.com wasn’t happy about this and has banned me from posting comments to WMPowerUser. This is a JOKE, guys! Why so serious… !?
Update 2: WMPowerUser.com today has posted an article about another new phone. This one is probably legit, but notice the screenshot that accompanies the article. There is a device called ‘NA NA’ in the list. I know for sure that device was already present before I conducted my little experiment. So I have a strong feeling I wasn’t the first to submit fake data to WP Bench…