Anyone who develops applications for devices can vouch for the importance of having a powerful emulator that can help accelerate the overall development and debugging process. This articles talks about the new Microsoft Device Emulator and how you can exploit some of its capabilities and make yourself a more productive Windows Mobile and Embedded developer.
Getting the Device Emulator
The Microsoft Device Emulator first shipped with Visual Studio 2005 in October 2005. The Microsoft Device Emulator emulates the ARM instruction set which implies that it provides a very high fidelity of emulation, especially on the Windows Mobiles devices which are based on the ARM Processor. This is a significantly different experience from the emulator that was shipped with earlier development tools, such as embedded Visual C++ and Visual Studio 2003, which shipped an emulator emulating the X86 instructions. In this article, you will see some of the benefits of using the ARM based emulator.
As mentioned above, installing Visual Studio 2005 will install Microsoft Device Emulator 1.0, however, if you wish to use only the Device Emulator, you can download it from the Microsoft Download Center. The download page is www.microsoft.com/downloads.
At the time this article was written, Microsoft Device Emulator Version 2.0 was available as a Community Technology preview download and would be shipping as part of the Windows Embedded CE 6.0 release within a couple of weeks. I highly encourage you to use the Version 2.0, as it not only enhances emulation performance significantly, but also adds many new emulation capabilities.
The download details for Version 2.0 can be found at www.microsoft.com/downloads/details.aspx?familyid= 13F5DE85-30CD-4506-9C5B-A2068FA1EE9E&displaylang=en.
It's a No-Touch Install
While the Microsoft Device Emulator setup package ships as an Installer package (MSI), the Device Emulator executable (DeviceEmulator.exe) itself can work without any kind of install requirements on the desktop. This means that you can enable a scenario in which you can host the device emulator and a device image on a remote machine, and then be able to run them from any other machine without having to install anything on it. This is a useful scenario in cases where, say, your sales force wants to demo an application installed on an emulator image but don't want to install anything locally on their machine. To achieve that, you can, for example, host a small batch file on an HTTP server which would load a pre-configured device image on the client machine without installing anything on the client machine.
For example, host a demo.bat file on your server:
http://mydemoserver/emulator/demo.bat
Then in the demo.bat, include something like this:
\\mydemoserver\emulator\deviceemulator.exe /s <filesname>.dess
When clicking on the link (The .BAT File) from a client machine, the emulator and the image would load on the client without any installation requirement.
Emulating ARM Instructions. So What's the Benefit?
As a Windows Mobile developer you have three advantages. The first one is that you no longer have to build two different binaries: one for an emulator and one for a device. The binaries compiled for your Windows Mobile device will work unmodified on the emulator as well, so there are fewer binaries to maintain. The second benefit is that there is now parity in the code that is executing on the device with what is running on the emulator, which means you can debug with a high degree of accuracy on the emulator itself.
The third benefit you get as a developer is indirect. It actually benefits the consumer of your application because now if they want to try your application without risking their device, they can run the application binaries on the emulator to experience your application. With high fidelity emulation of sounds and graphics, many apps will work just as well on the emulator. Unless you are using some specific features of the device such as a camera, you can expect your application to work without any issues on the emulator.
Figure 1 has a screenshot of "The Age of Empires" running inside the Microsoft Device Emulator. I have also successfully installed and used products like Microsoft Voice command to talk to my emulator.
In the next few sections, I will show you how easy it is to install an application on the device emulator using its capabilities to cradle with Active Sync.
ActiveSync Synchronization - It's Just Like a Device!
This was a new capability added to the Microsoft Device Emulator, which enables it to be treated like a real device in the eyes of ActiveSync. Once ActiveSync establishes a partnership to it, you can imagine the amazing number of scenarios that it opens up for you as a developer. You can install your application, simulate connectivity and Sync scenarios, and even use this feature to test complex scenarios like cradling and un-cradling support in your applications.
To cradle the emulator with ActiveSync, here is what is needed:
Figure 4 The Green Play sign indicates that emulator is running.
Where Is the Store Card?
The Device Emulator can also be used to emulate a storage card. It is actually very simple - you can map just about any existing folder on your development machine to be used as a storage card for the emulator. This can be done by pointing the "Shared Folder" property to any folder on your disk. Once that is set, all files on this folder will be available to the image running inside the emulator as if they were on a storage card.
The shared folder will show up as a Storage Card, (see Figure 4), when using the Files Manager. You can even install Device Applications on it when prompted during the install phase.
I have also used this feature to run Power Point files that were actually on my PC but rendered by Power Point on the Emulator. It is also interesting to observe that the emulator rotates automatically to show the presentation just like a real device would.
Another benefit of this feature comes in handy when you are building applications that require a large amount of static data (say a large SQL Mobile Database) that needs to be deployed as part of your application. In this case, you can put it in a Folder on your hard disk, share that folder with the emulator, then have your application access this data from the storage card, saving lots of time by deploying big files to the emulator.
Using the Command Line to Launch Emulator Images
While you can always use the Device Emulator Manager to start various emulator images, that capability depends on the existence of what is called a "Data Store" which is installed with Visual Studio 2005 and Platform Builder. This is information used by various tools to be aware of what's installed on your machine that can be used for device development. This is stored as a collection of files under \documents and settings\All Users\Application Data\Microsoft\corecon\1.0
In case of a standalone emulator (when you don't have a Data Store on that machine) you can launch any device emulator image using the command line as well.
When you start the emulator from the command line, almost every aspect of the device emulator can also be configured using the command line.
The simplest way to run a device emulator image would be to pass the name of the .bin file which is the emulator image file to DeviceEmulator.exe. For Example, running the following will launch the Pocket PC 2003 Second Edition VGA Emulator:
DeviceEmulator.exe PPC_2003_SE_VGA_WWE_ARMv4.bin
While some of these images are installed with Visual Studio 2005 or the Windows Mobile SDKs, you can also download and install standalone images from the following location: http://msdn.microsoft.com/windowsmobile/downloads/tools/install/default.aspx
When launching the emulator from the command line you can also specify to that emulator image how much memory you want to emulate by using /memsize parameter. Therefore, you can try your application in a variety of memory settings with ease.
My ALT+TAB Is Not Working and I Can't Take a Screenshot of the Emulator. Why?
Many people have asked me how I take screen shots of the emulator because when they try PrtSc or ALT+PrtSc, nothing seems to be captured. Also, they have reported that when the emulator has the focus, the ALT+TAB to another desktop application does not appear to work.
Well, no it is not a bug. It is how the emulator handles "Host Keys." If you look at the properties of the emulator (File->Configure), you will see that the host Key is set to Right Alt. Hence, if you want to take a screen shot of the emulator just use the RIGHT ALT Key along with the Print Screen button, or you can change the Host Key to Left Alt, which would cause things to work as expected. The host key allows you to use the keyboard for the development computer to control certain emulator actions, such as displaying its shortcut menu and predefining key combinations for operations such as shutdown, displaying file menu, and shortcut menus.
Connecting to the Internet Using the Emulator
The
Emulator can also be used to connect to the Internet or any other
server on your network. If you have cradled the emulator using
ActiveSync, there is really nothing special that is needed to be done.
Once ActiveSync is in the "Connected" state you should have Internet
connectivity from the Device Emulator. If you are on a corporate
network and access external Web sites via a proxy server you will be
prompted to set it up as you would on a real device. The settings used
here are similar to the ones that you would use to set up your desktop
IE (Tools -> Internet Options -> Connections -> LAN settings).
You can then connect to local intranet and Internet sites using the
emulator.
However, if you wish you connect via TCP and do not want to use ActiveSync, you need to download the Virtual machine Networking driver and follow the steps below. The Virtual Machine Networking Driver can be downloaded from www.microsoft.com/downloads/details.aspx?familyid= DC8332D6-565F-4A57-BE8C-1D4718D3AF65&displaylang=en.
Once this driver is installed, change the default transport of the emulator from DMA to TCP/IP, and give your emulator and IP Address. This can be done in Visual Studio 2005: click Tools | Options | Device Tools | Devices.
The emulator usually uses DHCP connectivity to get its own IP address, but if you use static IP addresses, give the emulator an IP address that is valid for your network.
From the configuration properties of the emulator select the Network tab and select the Enable NE2000 PCMCIA network adapter and bind to box. In the drop-down list, select the Connected network card, which represents the network card on the host computer. Close the dialog boxes.
Then from the emulator image, Click Start | Settings | Connections tab | Connections | Advanced tab | Select Networks to configure the Pocket PC Connection Settings. Be sure My ISP is selected under both drop-down lists.
You can get more details on this scenario on our Team Blog at http://blogs.msdn.com/vsdteam/default.aspx.
Testing an Application that Behaves Differently When Cradled
This is my favorite scenario; I find the new device emulator extremely
useful. In this scenario I have an application that has to behave
differently when connected to the PC (Cradled with Active Sync) from
when it's not. This is very typical of any real life Line of Business
Application, and the Device Emulator can even help you test
applications of this nature.
In my case, I also depend a lot on the new Managed APIs for State Notification - which ship as part of the Windows Mobile 5.0 - to reduce the amount of code I need to write to check if my application is running cradled or not. The new Managed APIs in Windows Mobile 5.0 make it very simple not only to detect the current state, but also to notify your application when it changes.
In my Visual Studio 2005 project (targeted for a Windows Mobile 5.0 Pocket PC application), I add reference to the following assemblies:
Microsoft.WindowsMobile
Microsoft.WindowsMobile.Status
Then, in my Form Class, I create an instance of a SystemState Property called SystemState.Cradle-Present:
public SystemState S = new SystemState(SystemProperty.CradlePresent);
When my application starts, I hook it up to listen to the notifications fired when this property changes. This notification will be fired when your device is cradled to your machine and when it is un-cradled:
S.Changed += new ChangeEventHandler(S_Changed); //add handler
Then, I create a simple event handler that will handle the change of this property. The code would look something like this:
void S_Changed(object sender, ChangeEventArgs args)
{ if (Convert.ToInt16(args.NewValue) == 1)
{ //Your code to handle connected state
Label1.Text = "Connected"; }
else
{ //Your code to handle disconnected state
label1.Text = "NOT Connected"; }
}
Once I have defined the different behaviors in my application, I don't need a device to test the scenario. This is where the Active Sync Partnership feature comes in handy.
You can deploy the application to the emulator as normal. One the application is running, you can bring the Device Emulator manager and select cradle with your emulator image. You will notice that as soon as the partnership is established, the notification will be sent to your app and the event handler for that will be called. In my case I will see the Label1.Text change to connected. Then you can Right Click again using the Device Emulator Manager and select UnCradle and you will see that the event is fired again and now the label will change to NOT connected.
This was an over-simplified scenario, but it really highlights how powerful the combination of the new Windows Mobile Managed API and Device Emulator can be for you as a Windows Mobile Developer.
Saving State of the Images
When you install Visual
Studio 2005, and launch and emulator image, you will notice how quickly
the image loads up. This is because of a feature called "Saved State."
As a developer, you can create your own saved states for these images.
For example, if you want the image to always have a certain program on
it or some specific settings, you can install / set it when the
emulator is running and then select Save State and Exit from the File
Menu. This way, when you bring up the emulator next time, you will find
that your settings are all preserved.
The way I use this feature for everyday productivity is by pre-installing .NET CF 2.0 on my images to speed up the deploy time of my applications. The Windows Mobile Emulator images don't have .NET CF 2.0 installed (since Windows Mobile 5.0 ships with .NET CF 1.0 Sp3 in ROM), but most of the applications I use are based on .NET CF 2.0. So instead of waiting every time for Visual Studio to deploy .NET CF 2.0 to my emulator, I install it once and then save the image. Now, every time that image loads, it already has .NET CF 2.0 on it, which saves me a lot of time deploying and debugging my applications.
To launch a Saved State image from the command line, just use the following and pass on the name of .dess image:
DeviceEmulator.exe /s ImageName.dess
While the Device Emulator does not have the ability to save and load multiple Saved States, here is a technique I find useful.
In the Tools->Options->Device Tools->Device, I select a basic image, for example, Windows Mobile 5.0 Pocket PC Emulator, as shown in Figure 5.
Then, do a Save As and save that image under a different name.
Now, when deploying the application, you will notice a new emulator available in the Deploy to Device Dialog.
You can then deploy your application to it, alter the setting, etc., and those will be available to you on your machine. As you can see from the dialog, I have an Image Called "Windows Mobile 5.0 Pocket PC Emulator with .NET," which I created the same way, and .NETCF 2.0 is pre-installed on that image. If you are wondering where the My Computer came from, you can read find out on this blog: http://www.danielmoth.com/Blog/2005/01/deploy-to-my-computer.html.
Starting the Emulator in a Preconfigured Manner
There are times when you wish that as soon as you start the emulator,
it has already been configured in a specific manner. This feature is
referred to as "XML provisioning," and it allows you to pre-configure
your emulator to add Internet Explorer favorites, have the correct
Internet Explorer proxy server set up, add registry keys, set time
zones and locales, etc.
Let's say you wish to pre-configure Internet Explorer in Pocket IE to have a shortcut to your favorite link, such as .NET Developer's Journal (http://dotnet.sys-con.com/). First, you would create an XML Provisioning File, say, with the name myIEFavorite.xml like this:
<wap-provisioningdoc>
<characteristic type='BrowserFavorite'>
<characteristic type='MSDN Mobility'>
<parm name='URL' value='http://dotnet.sys-con.com'/>
</characteristic>
</characteristic>
</wap-provisioningdoc>
Now, from Inside Visual Studio 2005, click Tools | Options | Device Tools | Devices, and in the Options dialog box, under Devices, select the Windows Mobile 5.0 Pocket PC Emulator. Click Properties. In the Windows Mobile 5.0 Pocket PC Emulator Properties dialog box, click the Configure button next to Device Emulation Startup Provider, and in this dialog, for Configuring the Emulation Bootstrapper, click the ellipsis button, and then browse to and select the myIEFavorite.xml file.
The next time you connect to this emulator from Visual Studio, Visual Studio will boot strap the emulator with this file, and you will notice that this favorite is added to your existing favorites in Pocket IE.
Do You Want to Write Your Own Emulator?
Believe me
when I tell you that writing emulators can be very hard, but I am
pleased to inform our readers that the source code for the Device
Emulator 1.0 has been released under the academic license. http://blogs.msdn.com/barrybo/archive/2006/07/17/668492.aspx has the details of this project.
You can download the entire project for Device Emulator 1.0, which you can compile in Visual Studio 2005 to build your own emulator. It's great for experimenting and learning how emulators are built.
What's Next?
The device emulator continues to
enhance performance as well as add support for emulation of additional
device peripherals. For example, The Device Emulator V2.0 (CTP), when
used with images rolled by Windows Embedded 6.0, will be able to
emulate even the batter setting for the device.
Using the emulator, you will be able to alter the battery strength, and test your application's behavior in different battery configurations. (This feature does not work with the existing Windows Mobile 5.0 images but will be supported in images of the future releases of Windows Mobile OS).
Having the ability to change the battery on-the-fly can save developers hours of precious time of waiting for their battery to drain on their real device, while trying to test how their application works in a low battery scenario.
Currently, all the configuration for the emulator is changed via the configuration dialog, however, in future releases, the emulator will support these changes via automation, and hence, you can write an application to change the setting on-the-fly on a running instance of the emulator without having to go to the configuration dialog.
To stay in touch with what's happening in the device development space and emulation technologies, subscribe to the RSS Feed for our team blog and use the forum (http://forums.microsoft.com/msdn/showforum.aspx?forumid=76) to discuss issues with us. You can also learn about the device emulator first hand from the blog of the Architect Barry Bond (http://blogs.msdn.com/barrybo/), who created the Microsoft Device Emulator.