Windows Embedded Home
Windows Embedded 8 Family
Windows Embedded 7 Family
Other Windows Embedded Products
Posted By J.T. Kimbell Program Manager
Here on the Windows Embedded team, we try to do more than just build software, we also “eat our own dog food” and use our software for our everyday work and to emulate possible customer scenarios. Today I wanted to share with you the first post of a small series about how one of our testers is feasting on the dog food…and loving it.
This post was written by me (J.T.), but all the hard work was done by Tien Do, a Software Development Engineer in Test on the Windows Embedded team. Tien is currently working on the Embedded OEM Tools team, which focuses on the embedded developer’s end-to-end scenarios. Before joining the Windows Embedded team, he worked on the Windows Fundamentals team, and before working for Microsoft he worked as a firmware developer for a company in the San Francisco bay area. In his spare time, he enjoys hiking, sightseeing and driving on long trips.
Tien took up this work for the same reason that many of us take the time to build something on top of Windows Embedded: to put ourselves in the shoes of our customers and understand the end-to-end experience of creating a specialized device. Tien also hoped to find bugs in our product and to be able to create some guidance and a template for other people in our team and for you, the Windows Embedded customer.
To do this, Tien had to take several steps. Some of them may be familiar or the way that you would do things, and some of them may be new or different. However, we hope that showing this process to you will make development on Windows Embedded Standard easier.
For the purposes of this exercise, Tien chose to create a device running WinTV7, because it would be an interesting type of device to have running in his office.
Determining the correct set of technologies to put on the system is possibly the hardest and most complex part of OS development on Windows Embedded Standard 8. Generally, one of three approaches is taken:
There are benefits and drawbacks to each approach and the “correct” approach could differ, depending on your expertise, schedule, and customer’s needs.
Tien decided to use the first approach, using his knowledge to put an appropriate set of technologies on the device. In the coming weeks, we’ll share some details about the end-to-end process for how to take the second approach (dependency analysis).
There was a bit of refinement needed, but Tien chose the following technologies to support WinTV7 on his test device:
You can download Tien’s template here for Windows Embedded Standard 8 CTP3.
To determine what drivers were necessary for his device, Tien installed a maximum Windows Embedded Standard 8 image on the target hardware and then ran tap.exe on that computer to obtain the list of necessary drivers. You can find Tap.exe on the toolkit ISO for Windows Embedded Standard 8 and copy it to any Windows 7 or 8 system and run to produce a .pmq file. You can then import .pmq file into ICE or IBW.
Tien took a straightforward and traditional approach to deploying this image. He chose his modules in ICE, saved the template, and then imported that into IBW. As soon as he deployed Windows Embedded Standard 8 on his device, Tien installed WinTV7 onto his device the same way you would on Windows 8: by downloading or copying the installer to his device and running it.
However, we provide tools to make deploying your application easier by using Module Designer to create your own custom module. If you want to do the same with WinTV7, here are the install and uninstall commands that you can use:
Install: \WinTV\setup.exe /q (note: your path may be different)
As soon as the application is installed on the system, we now want to make it a custom shell. After the OS is deployed, there are three ways you can do this:
For this exercise, Tien chose to follow the third approach changing the registry key to edit the default shell or user interface.
When Tien finished the exercise, the real payoff wasn’t that he had a functioning DVR in his office. The value came from the experience of walking in the customer’s shoes, learning more about our product, and finding some bugs. Here are the key learning, takeaways, and bugs found by Tien from this project:
Take a look at Tien’s device in action (image blurred for copyright reasons).
And that’s our first post on dog fooding a Windows Embedded Standard 8 device. Look for more posts over the next weeks and months.