Update API

[Lee_UnitecElectronics]

Hello,

The company I work at wants to implement updating the runtime images,
of Windows XP Embedded, on CF cards in the field.

The thing is the company would like to do it within their POS system
used at car washes, rather than the user being forced to go to Windows
Explorer and locate and run the separate update EXEs themselves.

My question is there an API to go to a server operated by Microsoft
that would have the latest updates for Windows XP embedded, query the
client machine to see what's currently installed, and to then install
any updates that are missing?

With regular Windows XP, you have the "Microsoft Update" which then
takes you to a Microsoft server via the web where you would click on a
button that presents a list of updates. It sure would be nice to
control this process via an API using programming calls (specifically
in C#) that could be incorporated into our product.

The company's client base is not very computer literate, so shielding
them from even going to the filesystem is preferred.

Thanks.

Lee Linkoff

 

[Kevin Bulgrien]

The thing is the company would like to do it within their POS system

used at car washes, rather than the user being forced to go to Windows
Explorer and locate and run the separate update EXEs themselves.

The Device Update Agent (see also DUAScriptGen) and Image Difference Applier
can be made/are designed to work without operator intervention. Creating the
updates processed by these tools is not necessarily trivial.

My question is there an API to go to a server operated by Microsoft
that would have the latest updates for Windows XP embedded, query the
client machine to see what's currently installed, and to then install
any updates that are missing?

No. Your company (or a hosting service) would have to have a server to host
updates. XPE deployments are generally quite unique and unsuited to
universal updating mechanisms. Only the system designer can really decide if
this update or that is appropriate to the system based on any number of
parameters like "disk" space, security, required design restrictions, write
filters, deployed components, etc. Furthermore, the XPE write filters for
disk and registry mean that the designer also has to manage XPE-specific
processes because those resources prevent normal access to disk and registry
for purposes of extending FLASH device life, reducing Windows self-rot, and
improving security.

With regular Windows XP, you have the "Microsoft Update" which then
takes you to a Microsoft server via the web where you would click on a
button that presents a list of updates. It sure would be nice to
control this process via an API using programming calls (specifically
in C#) that could be incorporated into our product.

Someone has created DUAScriptGen to auto-convert Microsoft updates deployed
on the ECE into DUA scripts. These updates could be hosted on a server and
DUA can be configured to poll it. Setting this up is going to require some
engineering in addition to running the server. Considering also how dumb DUA
is, one should carefully consider the security of the update mechanism
itself... You don't really want someone to be able to hijack/intercept the
update process and be able to deploy their own version of myapplication.exe
on your security sensitive embedded system.

In one product, presently we have it simplified to one application function
to check for updates that scans for a USB stick with a secured archive that
contains the update. Automated processes unpack the archive and apply the
update. The user acknowledges the update should be applied, and other than
tolerating a few reboots, it is a hands off process from there. We have not
gone down the road of setting up a server, but the same mechanism we use to
process USB stick updates can also poll a server on the network.

You can always code your own update agent in C, but you design the API and
supply the server. The built-in APIs (mentioned above) do not do what you
are asking for, nor is it reasonable for them to do so. It sounds like the
engineer that designed the system really needs to do some homework on XP
Embedded. It's not that hard to find out about the tools provided.

The company's client base is not very computer literate, so shielding
them from even going to the filesystem is preferred.

That's not a problem. Tools are available to hide the complexity from the
end-user, though being a reboot happy Windows OS, it probably will not be
completely hidden process.