Interesting title, huh! What am I supposed to do with such a thing?! You can upgrade your device from Service Pack 1 to Service Pack 2 or Feature Pack 2007. Not convinced yet? Just imagine that you can create one update package for all your operating system security updates and hotfixes, configuration changes and third-party application updates. Image Diff will compare two images that are in a readable offline format and produce a folder with all the resources that are different between the two images. You package that folder together with the Image Diff Applier and the update is ready to go.
The basic end-to-end process to upgrade your image to Feature Pack 2007 is as follows:
1. Store your existing Windows XP Embedded with SP2-based device image in a readable offline format that is accessible from the development machine.
2. Upgrade the SP2 component database to FP2007 and of course, do not forget to back-up your database.
3. Upgrade the SP2 configuration (.slx) file to FP2007.
4. Build and deploy the FP 2007 image.
5. Boot and test the image on a sample device. Rebuild as needed until it works and is configured properly .
6. Store the image in a readable offline format that is accessible from the development machine.
7. Run Image Diff (IDIFF.EXE) against the original SP2 image and the new FP2007 image. The resources that are different between the two images are collected into a folder.
8. Package the diff folder along with the Image Diff Applier (IDA.EXE) so that it can be deployed and applied.
9. Test the package on a sample device.
10. Test the upgraded device for compliance and parity with the original FP 2007 image.
Ten easy steps to success, where do you get that nowadays?!
You can access the Image Difference Engine Evaluation tool via the same Microsoft Connect website as the Feature Pack (https://connect.microsoft.com/windowsxpembedded).
If you did not signed up for the XPe Feature Pack check out Andy’s article XPe Feature Pack 2007 Community Tech Preview released!
Enjoy!
- Steffen, Program Manager for Embedded Windows
The xpecmd is a good work, but the help document about it is too simple.
the document of compents cmi* properties should be a part of the help of xpecmd.
xpecmd needs a commad to commit a script file containing xpecmd actions in xpecmd shell like "exec" or "source" command in other script language interpretor.
Thanks for the feedback on XPECMD! The properties of each individual component are detailed in the Component Help file included in the XPe documentation - there isn't really any easy way to interface XPECMD with that CHM file (that we know of), so it's probably just easier to point users to that file instead.
As for the command to "commit a script file": You can use the "@responsefile.rsp" syntax to run a script at any time:
xpecmd> @myXPEscript.rsp
Hope this helps!
- Matt, XPe SDET
a reference for cmi* properties of each component is needed for ease of development. the help only describs settings of components, the settins' name are not the same as the properties' name, and some the help does not have help for some components.
The @ does not work if the script file name does not include the .rsp
"log on <file>" and " log off" command to control logging may be very helpful.
is it possible to do work using function and process control using loop and swich, for example
func myf1(inst x) {
show x.properties
}
func myf2(comp x) {
new myin Instance
new myco Component
new i String
for i in {"User Interface Core", "User Account"} {
myin = "inst:$i"
myco ="comp:$i"
myf1(myin)
myf2(myco)
Regarding the Help content: We would need to populate this data for every single component in the database in order to be consistent. I don't think that's within the scope of this tool or our documentation.
User-defined functions are not supported in XPECMD.
The @ command assumes that if you do not specify an extension, you are using a .RSP file. If your file has a different extension, you must specify that extension instead. It is generally not a good idea to use script files that don't have extensions.
The following commands should all work (assuming the files exist):
@myResponseFile.rsp
@myTextScript.txt
@"c:\program files\Windows Embedded\A Script.txt"
Hope this helps. :)
- Matt
@ dones not show the commands started before showing information for those commands, an enhancement command of @+ to "echo" the command started before show information for each command will be helpfull
to make information easy to read, @+ can only put one line "+<command>" out before puting message for <command>
how to make comments in a .rsp file like /* comment */ in C , "REM comment" in bat or "# comment" in sh ?
the dump command needs a /p switch like show to page
the /p switch can be enhanced by set line number for a page like "/p40"
when dump mycfg, output message usually goes out of the cmd window. in this situation, the "/p#" switch and especially "log on <file>/log off" may be helpfull.
Hi pdfan - can you please post any new issues as bugs at the msconnect site? By entering it at that web interface on the connect site you're basically filing bugs directly into the product team's bug tracking database.
I'd really appreciate it.
Thank you for the feedback so far!
-andy
It's new years eve, the end of quite an interesting year in the mobile and embedded group. Here's a quick