To: Andy Allred - Applying Service Packs to XPE

  • Thread starter Thread starter Roy Hodgkinson
  • Start date Start date
R

Roy Hodgkinson

Andy,

Its unclear that adding to the existing NG thread is the best way to
provide input as solicited in your 2/13/2004 posting. I tried sending
e-mail to andyall.online.microsoft.com but that is being rejected as
unresolvable by DNS.

What is the best way for this News Group to give you input?

Thanks, Roy
 
Roy,
I'd rather keep the conversation in the NG unless there is something
proprietary you didn't want discussed in public.

The fact that the discussion is public will hopefully fuel other ideas
shared among a lot of the participants in this NG that i respect and trust
their level of knowledge. Especially if it's a subject where someone may
have a greater level of knowledge than myself <grin>

If you insist on sending feedback offline remove "online" from the address.

BTW, just so we're all on the same page, this is just a proposal of mine at
this stage.

thanks
andy
 
Andy,
Why is it that some of the Updates have a file that details the location for
the new components as well as manifest of registry modifications and some of
the updates only have the normal MS EULA. Example: Update 817787 and Update
825119. What gives?

Regards,

Sean Gahan
 
Andy,

Thank you for clarifying your preference and for soliciting the input.

Some Thoughts on Applying SPs to XP Embedded Systems
====================================================

One key challenge seems to be how to identify which Service Pack
binaries, etc. (and their Service Pack dependencies) need to be
applied to each unique XP Embedded Image. As a starting point, let's
assume that the current contents of each XPE Image is adequately
described by its associated *.slx file and that each Service Pack is
componentized into very granular elements allowing definition of
dependencies required for self-consistency -- not easy, but any
solution likely hinges on this being possible. (Separate consideration
will be required for identifying any OS Service Pack binaries required
by Microsoft programs that cannot be defined in the *.slx file – MSDE
and DirectX are examples but may also have their own independent
Service Pack streams.)

How would we generate an updated XP Embedded image to incorporate an
XPE Service Pack today? First, we apply the Service Pack to the
Windows Embedded Studio repository. When we load the current *.slx
file, TD will recognize any repository components that need updating
and display a dialog asking if all updates should be applied. Once the
updates are applied, a dependency check will resolve any new
Service-Pack-specific dependencies – binary co-requisites, registry
updates, etc. TD can now generate a new XP Embedded image and save the
updated *.slx file.

But, what we really want to capture is the delta between the original
*.slx file and the updated one. A "read-only" version of TD ("Upgrade
Designer"?) could be used to identify the Service Pack component
updates and additional dependencies, then generate just the binary and
registry delta between the original *.slx file and the fully updated
XP Embedded image. What we end up with is a self-consistent subset of
the Service Pack customized to the original XP Embedded image. This
approach would be even more valuable if it was "open" so that we could
all create component upgrades – e.g. add that new printer driver – for
delivery to our field units.

The components required to apply the "customized Service Pack" could
be specified as XPE Service Pack dependencies. These dependencies
could be satisfied either by their existence within the XP Embedded
image or be incorporated within the "customized Service Pack".

The method of delivering this "customized Service Pack" to existing XP
Embedded devices depend on the device's hardware and connectivity
characteristics. Although an existing Microsoft-recommended solution
might be offered, that could be just one option to be considered by
the customer.

Roy
 
Hi Roy,

This problem is really tough, and some discussion about it in this NG
probably would help MS to make some better solution in future.
I thought a lot about this problem in the past, but I have always found a
reasons why some approach can't be done (I just hate this).

1.
As you noticed your approach can be used for only certain type of components
(components that only use registry and file entries, without some extra
processing during FBA).
If this could work is would be the best method for creating updates. (we
would easily have minimum manifest for registry and files changes). But in
current concept and implementation of XPe tools we could use this only for
kernel based XPe builds. So update mechanism should be implemented in ntldr
when we press F12, or something like this since this is the only point that
could use update for certain.

2.
Second maybe biter approach (still unusable) would be that we use post FBA
images for comparations.
You have original gold image, and updated gold image all manual
installations and configurations are done, all files extracted and installed
(like MSDE, DirectX9/10, some Setup.exe applications, etc).

Some difference utility could:
Find all files that have changed (updated), this is probably easy and
straight forward, so it could put all new files in some update file.
But registry is bigger problem. Util could analyze changes between offline
registry files, and find out about all registry differences between builds,
but there would be just too many changes.
At the end you would be stuck with enormous amount of registry keys that you
would need to leave or remove manually.
This util could know be aware of meaning for most registry values so it
could decide by itself what must be changed.
But there are many PnP and GUID like entries that can't be compared.

There are certain things that must be satisfied before both approaches can
be even considered:
- MS must find all registry entries that are created dynamically during the
FBA phases and move them to component registry entries. (All non hardware
related parts of FBA should be removed).
- Users must stop using setup based installations during and after the FBA.

There are more other issues with this approaches, and with any other
component based approach. I'm just glad that I don't have to deal with this
problem.

Regards,
Slobodan


Roy Hodgkinson said:
Andy,

Thank you for clarifying your preference and for soliciting the input.

Some Thoughts on Applying SPs to XP Embedded Systems
====================================================

One key challenge seems to be how to identify which Service Pack
binaries, etc. (and their Service Pack dependencies) need to be
applied to each unique XP Embedded Image. As a starting point, let's
assume that the current contents of each XPE Image is adequately
described by its associated *.slx file and that each Service Pack is
componentized into very granular elements allowing definition of
dependencies required for self-consistency -- not easy, but any
solution likely hinges on this being possible. (Separate consideration
will be required for identifying any OS Service Pack binaries required
by Microsoft programs that cannot be defined in the *.slx file - MSDE
and DirectX are examples but may also have their own independent
Service Pack streams.)

How would we generate an updated XP Embedded image to incorporate an
XPE Service Pack today? First, we apply the Service Pack to the
Windows Embedded Studio repository. When we load the current *.slx
file, TD will recognize any repository components that need updating
and display a dialog asking if all updates should be applied. Once the
updates are applied, a dependency check will resolve any new
Service-Pack-specific dependencies - binary co-requisites, registry
updates, etc. TD can now generate a new XP Embedded image and save the
updated *.slx file.

But, what we really want to capture is the delta between the original
*.slx file and the updated one. A "read-only" version of TD ("Upgrade
Designer"?) could be used to identify the Service Pack component
updates and additional dependencies, then generate just the binary and
registry delta between the original *.slx file and the fully updated
XP Embedded image. What we end up with is a self-consistent subset of
the Service Pack customized to the original XP Embedded image. This
approach would be even more valuable if it was "open" so that we could
all create component upgrades - e.g. add that new printer driver - for
delivery to our field units.

The components required to apply the "customized Service Pack" could
be specified as XPE Service Pack dependencies. These dependencies
could be satisfied either by their existence within the XP Embedded
image or be incorporated within the "customized Service Pack".

The method of delivering this "customized Service Pack" to existing XP
Embedded devices depend on the device's hardware and connectivity
characteristics. Although an existing Microsoft-recommended solution
might be offered, that could be just one option to be considered by
the customer.

Roy

"Andy Allred [MS]" <[email protected]> wrote in message
Roy,
I'd rather keep the conversation in the NG unless there is something
proprietary you didn't want discussed in public.

The fact that the discussion is public will hopefully fuel other ideas
shared among a lot of the participants in this NG that i respect and trust
their level of knowledge. Especially if it's a subject where someone may
have a greater level of knowledge than myself <grin>

If you insist on sending feedback offline remove "online" from the address.

BTW, just so we're all on the same page, this is just a proposal of mine at
this stage.

thanks
andy
Click to expand...
Click to expand...
 
Back
Top