Heavenly Dog food: Building a DVR with WinTV7

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.

Selecting the Appropriate Technologies

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:

• Use your best guess and judgment as to what modules are needed.
• Use Process Monitor or other tools to analyze an application’s dependencies and modules.
• Install a comprehensive, near-maximum image of Windows that ensures application compatibility.

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:

• .NET Framework 3.5 & 4.5
• Application Development Frameworks\Legacy Support folder
• Adobe Flash Player 11 and Adobe Reader X (under Application Support)
• Bluetooth, USB UI and Local PnP Device Discovery from under the Devices folder
• The whole Enterprise Management node
• The whole Graphics & Multimedia node
• Several non-English fonts (but not language packs) from Language Modules\Languages\Tools, Additional Fonts Natural Language Support\Additional Fonts
• The whole Networking node
• The whole Security node
• Accessibility tools, Internet Explorer, Remote Desktop Connection, Notepad, and Windows Media Player from the User Applications Folder

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.

Deploying the OS and Application

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)

Uninstall: hwclear.exe

Setting up a Custom Shell

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:

1. Creating a Config Set
   1. In ICE, create a new configuration file.
   2. Add the Shell\Shell Launcher module.
   3. Select Shell Launcher in configuration file and find the Shell setting in the settings pane.
   4. Change that setting to the installation path of your application.
   5. Resolve dependencies.
   6. Select “Create Configuration Set” on the Tools menu.
   7. Install the Config Set onto your end device by using DISM.
2. Using the Embedded Lockdown Manager
   1. Learn more about Embedded Lockdown Manager and how to install it here.
   2. Connect to your device and select Shell Launcher and then click “Add a Shell” under Actions.
   3. Select the user or group for which you want to set the shell and then select your shell.
3. Editing the Registry
   1. On your device, edit the following registry key to be the path for your application’s executable:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

For this exercise, Tien chose to follow the third approach changing the registry key to edit the default shell or user interface.

Key Takeaways

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:

• To import a configuration file into IBW and have it successfully complete setup, product keys must be included in the configuration file. There is currently no option to enter the product key later, after the modules are installed on the system. A workaround to this is to import your configuration file as a template, which can be done several steps later in IBW.
  • You can include the product key in your configuration file by selecting the Embedded Core in ICE, navigating to the UserData setting in the settings pane and changing the Filter view by: dropdown to “1 WindowsPE” and then editing the value of the ProductKey\Key setting.
• The Windows Preinstallation Environment (WinPE) does not contain all drivers, so several drivers may not be mapped or included in your image. This can be somewhat confusing because “Auto Detect Drivers” may not detect all the drivers. The best way to include necessary drivers is to install Windows 8 on your target device, copy tap.exe from the toolkit ISO and then run it to generate a PMQ file that you can import into ICE or IBW.
• To ensure all drivers deploy correctly with your OS, it may be best to create a whole configuration set, not just a configuration file, to import into IBW. This configuration set can include all necessary “in box” drivers as well as any other drivers that you add by using custom modules.
• A bug was found where Windows Embedded Standard 8 did not start up if Message Queuing was included. We resolved this issue.
• Sometimes it may not be obvious what version of .Net is needed. Tien learned that, although .NET 4.0 was included by default, he needed .NET 3.5 which wasn’t included.

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.