Dr. Dobb's Journal April 2001
Starting with a signal processing console application that ran under standard Windows NT, I envisioned a black-box system that was completely turnkey — the user interface would consist of a power switch. It would have a passive PCI backplane chassis with a single-board computer and two A/D PCI cards. Analog signals would go in, and processed digital data would come out over a network to a client display system. There would be no monitor, keyboard, or mouse to bother with. A flash memory card would hold the entire operating system, along with vendor and proprietary software. Finally, shutdown would consist of switching off the power — no waiting for the operating system to clean things up and tell me when it's safe.
Just about everyone is familiar with the idiosyncrasies of standard NT. Try booting up without a keyboard. What about all the read-writes to disk for virtual memory paging and bookkeeping tasks? Need I mention the nasty things that happen after a sudden power off?
Fortunately, Windows NT Embedded 4.0 lets you configure systems such as the black box I envisioned for my project. Windows NT Embedded 4.0 is a toolkit for creating an embedded OS by choosing the essential components of Windows NT 4.0 for a particular application. The toolkit is part of Microsoft's Windows Embedded family of operating systems, which also includes Windows CE and Windows 2000 Server Appliance Kit, available through approved third-party vendors (http://www.mswep.com/partlist.htm). The toolkit runs on a standard NT system (the development platform) and is used to create an image on a local/networked filesystem. This can then be transferred to another system (the target platform) to be used for the embedded system.
In this article, I examine the Windows NT Embedded 4.0 toolkit by explaining how I used it for my black-box project. I also recommend an approach to configuring the embedded OS using the tools provided with the kit. In a nutshell, the approach consists of the following steps:
1. Install and test the application(s) on the development platform before loading them on the embedded target.
2. Configure the target platform to use the image that will be created on the development system.
3. Use the Target Designer tool to configure a complete nonembedded NT operating system.
4. Augment the nonembedded NT configuration with custom and third-party components.
5. Copy the nonembedded NT configuration to a new configuration and perform subtractive synthesis to create the smallest embedded footprint desired.
6. Finally, use special components that support the embedded system concept.
Understand that embedded does not mean real time. In fact, the word embedded is slightly misleading because the tool can be used to build full-up versions of the NT operating system. Windows NT Embedded is a scalable version of the standard OS, custom designed to include only the required drivers, services, and applications. For an application that already runs under standard NT, it is an adequate solution because the NT footprint can be scaled down to a minimum.
Before starting to build the embedded operating systems, make sure the development platform is similar in form to the target system. This means you have installed all third-party software and are able to run the target application on the development platform. This will also facilitate setting component parameters and adding third-party software to the configuration. If you cannot get your application to run on standard NT, you will not get it to run on NT Embedded.
Next, set up your environment to test the image that will be created on the development platform. For my black-box target, the boot device was a PCMCIA flash memory card mounted as the primary IDE drive. On the development platform, the flash card appeared as a secondary removable drive. I built the image onto the card, popped it out, transferred it to the black-box system, and powered up. Although this is a small consideration, simplifying this step will save development time. It is worth thinking about how to minimize boot cycles and alterations to the BIOS.
The main tool provided with NT Embedded is Target Designer, which builds an operating system almost like a cross compiler builds images for a target processor. As Figure 1 shows, this application looks similar to Windows Explorer with an expanding tree on the left side and a branch view on the right. The branch view can be configured to show selected components, files, or registry settings. For the most part, focus stays on the left portion where the components of an NT OS are listed. Until you are ready to add third party components not found in canonical NT, you probably do not need to pay much attention to the right side. I quickly came to trust the tool to specify the correct files and registry settings for the components selected.
The top node on the left side hierarchy is called "TDSD," short for Target Designer Software Database, from which all target images are descended. Below the TDSD node is the level consisting of collections. A collection is simply a set of configurations, which are custom-built NT operating systems. The tool comes with a collection called "Examples" that shows embedded operating systems for an assortment of targets. It also comes with an empty collection called "User Configurations" to be filled by you, the developer.
For my project, I created two configurations — one called "Full Monty" and the second called "Black Box." In truth, I only wanted one configuration, the latter. However, I found it easy to get comfortable with the toolkit by building a full-featured NT with all the goodies (the Full Monty configuration). Since Target Designer has a function for duplicating configurations, it was easy to copy the first one after getting it to work and stripping away items I did not need. I call this approach "subtractive synthesis."
I also figured that if I messed up, I could start afresh from the first configuration. This last worry was unfounded since there is nothing really to mess up; a dependency checker makes sure you include the things you need and vice versa. However, I still recommend the approach as a good way of getting started with the tool. It quickly builds confidence.
The nice thing about Target Designer is that all the components are arranged in folders grouped according to capability. Building the OS is roughly a matter of traversing the tree and picking a component from each set. A right click on the component reveals a menu to "Add" or "Remove" the component. Some components have a "Properties" choice that results in a dialog box identical to that appearing through the Control Panel in standard NT. If the target and development platforms are identical, you can copy Control Panel settings when setting component properties for the target OS.
Each new configuration begins with "System" and "Applications" capability folders. The System folder contains more for Platform, Devices, Network, Windows Services, and others. Digging deeper, there are yet more subfolders inside each of these until a list of components is revealed. Usually, the list is made up of mutually exclusive choices.
For example, under the Platform folder is the capability for Virtual Memory. For the Full Monty configuration, I chose to have the Default Page File component. When I stripped down the configuration for the black-box configuration, I selected the "No Page File" option; see Figure 2.
In no time flat, each species of component provided in the software database can be addressed. At this point, an image can be built, installed, and tested on the target platform. At the press of a button, the Target Designer stitches together an OS according to the prescription given in the configuration tree. A Full Monty configuration, such as I outlined, results in an operating system that looks like, well, standard NT. Nothing embedded here — yet. Now the hard part.
For my black-box application, I was using vendor software not native to NT, and therefore, not an inherent part of the Target Designer Software Database. This is the only difficult part of getting an embedded configuration that works for your application. The black box uses two PCI A/D converters that come with their own drivers. I was also using Intel's Native Signal Processing libraries. On the desktop environment, these packages are easily installed using InstallShield or some other tool that unpacks files, sets environment variables, and muddles with the registry. Unfortunately, this way is no good to the embedded NT builder. Assuming that you have stripped the operating system to include the facilities needed to run InstallShield, once you rebuild the image again to be the final read-only headless version, the registry is recreated and the third-party changes are gone.
Enter the second tool, Component Designer, which has a similar Explorer-like design and is used for configuring components not part of the canonical NT environment; see Figure 3. Once created, these components can be imported into Target Designer's Software Database and used more or less like the other components that come with the toolkit. You can Add/Remove them from the build.
Component building is where things get tricky. The overall result of Component Designer is a text file called a "Component Definition File" (also known as KDF from the file extension) that prescribes the files, registry settings, and other adjustments made to NT to install the software in question. If you are lucky, someone out there on the Internet has created the KDF you need (but don't count on it).
At this point you face some choices:
I first tried talking with Intel, makers of the NSP library, figuring if anyone was on board with a Microsoft Standard, it would be Intel. Alas, they'd never heard of a KDF.
Too cheap and impatient to pay someone or take a class, I opted to figure it out on my own. It is a testament to the toolkit that this was easy to do after some trial and error. There are features of the tool that make it easy to generate your own component. Principal among them was a button called "Copy from Local Registry." This is where having the target application running on the development desktop comes in handy. Creating the right registry prescriptions became a simple drag and drop operation.
There is some help available. Microsoft has a technical memo entitled "Microsoft Windows NT Embedded 4.0: Defining a Component Using Component Designer" (http://msdn.microsoft.com/library/default.asp?URL=/library/techart/definecd.htm). There is also a reference to a Knowledge Base article, "Q247824 INFO: Tips on How to Create Components for Microsoft Windows NT 4.0 Embedded," which may be helpful. If that's not enough, there are other tools available that will monitor changes in the file system/registry when installing software. Regmon and Filemon are examples available from SysInternals (http://www.sysinternals.com/). A log of changes during installation on a test NT platform can be transcribed to the Component Designer with some effort.
Once a component is created, it can be imported into Target Designer using the Component Manager, the third tool. My custom components were listed under the Applications->Add Ins capability folder. At this stage, you can build and test an image that runs a full-up NT operating system with vendor software along with your own applications — the Full Monty.
The embedded configuration now becomes a simple matter. With a few mouse clicks, I copied and pasted Full Monty and renamed it "Black Box." Then I began stripping away components: no virtual page file, no Windows Explorer, and so forth. It is probably a good idea to remove from a group of categories, test, and then continue the subtractive synthesis. Also, one may wish to keep the task manager, performance monitor, and other diagnostic tools. Even on a headless system, there is a way to use these applications.
As you begin to make the system embedded, all the trappings of the standard OS will disappear. No icons, toolbars, or properties menus; just a green background with a command window. As one gets closer and closer to the embedded product, certain questions arise:
The last thing to do with the new operating system is to make it headless so it can boot up and run application(s) without the installation of a keyboard, mouse, and monitor. This is easily accomplished by selecting the Null VGA, Null Keyboard Driver, and Null Mouse components in the corresponding device categories.
When the system is fully headless, any monitor attached will show NT booting up to the blue screen interval, but no further. Now for Embedded Uncertainty Principle: Can you see what's going on in the headless configuration and have the headless target image at the same time?
Fortunately, by adding the remote administration component, another computer can run Microsoft NetMeeting to look in on the black box. What appears on the remote host is a window that shows the desktop as it would be on the embedded system if it had a VGA display driver plus a monitor. With the remote administrator, you can point and click on the command shells, type from the remote keyboard, or run installed windows applications (performance monitor, task manager, and the like). This is a good tool for running application software experiments without rebuilding the OS image each time.
At this point, the black-box configuration is essentially complete. The system is embedded. The only thing left to do is to crank out licensed targets.
In the end, there were few complaints using the toolkit. Installing the image on a top-level file system (such as E:\ or C:\) was impossible from inside Target Designer. This may have been a deliberate move to keep the absent minded from trashing the operating system of their own development platform. In any case, it required an extra step to copy the image from one folder to the top-level directory of the target boot device. Forgetting to do this was an annoyance, but certainly less annoying than trashing the development platform.
And of course, more documentation would have been helpful, especially a tutorial of some kind. But I suppose that would take the fun out of it. Parting peeve: Microsoft will only sell target licenses in powers of 10 starting from 101, 102, 103, and so on. Alas, I only needed 100 for my deliverable. I suspect I'll use the other nine anyhow.
Overall, the Windows NT Embedded toolkit achieved everything I set out to do with my black-box project. I found it easy to use once I got oriented with the Target and Component Designers. Based on material I was able to dredge up from Microsoft's web site, there are no plans for an embedded development toolkit based on Windows 2000. Microsoft is apparently targeting the next generation product, named "Whistler Embedded," for the updated embedded toolkit, as Figure 4 suggests.
DDJ