Today, I had a unique opportunity to work with Window XP Embedded.
*Shudders*
Microsoft has made some lousy products in the past, but the Embedded SDK has to be one of the worst. The application isn’t remotely intuitive to use, and even once you’ve learned what you’re doing, it’s not easy. The task I had was simple: create an XPe image to test a particular program with. However, this was far more difficult than it needed to be. Even though I had a list of the DLLs that I needed, there was no easy way to find those DLLs in the XPe tools. Each time that I wanted to load a DLL, I had to manually create a new filter for “Contains” and the name of the DLL, rather than use the integrated search box. For some reason, the search box would not look at the names of the DLL files themselves, just the name of the packages they were in. Even creating a filter didn’t work 100% of the time (actually, I don’t think it even found 10% of the files I needed).
Secondly, the built in dependency generation was a joke. When you clicked on “Build,” it would ask you if you wanted to automatically fulfill dependencies. You click yes, and it does that, but it’s not recursive. Whast I mean, is after it’s done, and you click “Build” again, you know have X number of new components that need to have their dependencies checked, and so XPe will go on to scan every component again. It took 5 or 6 rounds of dependency checking before it was finally happy for me. Then, I got to build the image. The software did some hocus pocus, and then spat out a standard looking C: filetree in a directory on my hard drive. Now what? I had Program Files, Documents and Settings, and WINDOWS, but no idea what to do with them. I tried putting them on a virtual 512MB hard disk and creating a virtual machine to boot to it, but no luck, there was no MBR on the disk. After 30 minutes or so of reading documentation on the matter, I called it quits for the day and went on to work on other things.
I know it’s not an impossible issue to overcome, and I’m sure I’ll get past it tomorrow, but creating an embedded image was far more difficult than it needed to be, and in my opinion, should be handled something like this:
- Start a new Embedded project.
- Load any number of executables that you need your system to run into the project. The software scans the EXEs to determine which libraries they are linked against, and copies those files into the project as well. (Visual Studio has a tool to scan an EXE and determine it’s dependencies, so this should be possible.) The included EXEs will be copied into Program Files when the image is created.
- Create a profile of the hardware that the image needs to run on, and load the appropriate drivers. For more common hardware, this could be done automatically, otherwise, the user could manually download and add the needed drivers.
- Now, perform a single, recursive, dependency check to satisfy all of the previously included components.
- Finally, export the image to a specified format, such as a CD ISO for installing the image, or a bootable USB jump drive.
That’s just a rough outline, but I think that it’s relatively feasible and that creation of embedded systems could be much easier.